SigmaEra for IT & Platform
Whatever gets bought, you are the one running it at 2am.
SigmaEra ships as a Helm umbrella chart against your own Postgres, object store, secrets manager, and identity provider — the same data plane that runs our SaaS, with no outbound calls at startup and no vendor SDK in the data path.
Somebody has to run this. That somebody is you.
The arc an IT or platform lead walks with SigmaEra: what you inherit, what you actually deploy, and what happens the first time it misbehaves at an inconvenient hour.
- 1The handover
You did not choose it, and you own it now
A decision was made above you. What arrives on your plate is an operational commitment with a renewal date, and the questions you care about were not on the evaluation scorecard.
What you have to answer
- What does this actually consist of — how many services, what dependencies?
- What do we run, and what does the vendor run?
- What happens to us if the vendor has a bad week?
The layer that answers it
One deployment, documented
A Helm umbrella chart over a defined service inventory, with bring-your-own or bundled Postgres, event bus, object storage, secrets manager, and telemetry collector. The service inventory and its trust boundaries are published rather than discovered.
What changes for you
You inherit a documented system with a known shape instead of reverse-engineering an estate from a sales deck.
- 2Integration
Plugging it into what you already run
You have an identity provider, a secrets manager, and opinions about both. The last thing you want is a product that brings its own and asks you to maintain a second copy of everything.
What you have to answer
- Does it federate with our IdP, or invent its own user store?
- Where do signing keys live, and who rotates them?
- Can it use our Vault, our Postgres, our object store?
The layer that answers it
Standards, not substitutes
OIDC for identity, Vault for secrets, S3-compatible object storage, SMTP for mail, OpenTelemetry for traces, PostgreSQL and NATS JetStream underneath. A must-follow rule forbids cloud-vendor-locked primitives in the data plane, and CI rejects forbidden SDK imports.
What changes for you
It joins the estate you already operate rather than adding a parallel one with its own upgrade path and its own on-call rota.
- 3The hard requirement
It has to run where the internet does not
Some environments have no egress, and a product that quietly phones home at startup is a product you cannot deploy there — regardless of what the datasheet says about on-premises support.
What you have to answer
- Does it start with no outbound DNS at all?
- How does licensing work without a callback?
- Is telemetry mandatory, and does anything degrade without it?
The layer that answers it
Air-gapped operation
Offline image and chart bundles, no outbound calls at startup, licence validation against an embedded public key, and telemetry that is opt-out with no loss of function. An air-gap startup test asserts services reach readiness with no external DNS resolution.
What changes for you
On-premises means the same code path rather than a stripped fork — and "air-gapped" is something CI proves rather than something sales asserts.
- 4Day 2, 02:14
Something is wrong and you are the one awake
A probe is green but users say it is broken. You need to know which component is actually failing and whether it is yours or theirs, quickly, without reading source code.
What you have to answer
- Is liveness telling me the truth, or just that the process is alive?
- Can I tell a dependency failure from an application failure?
- Are auth failures instrumented enough to diagnose?
The layer that answers it
Honest operational surface
Health and readiness probes on every service, with documented per-service functional probes because readiness alone does not prove useful work is happening. Prometheus metrics across the fleet with a Grafana and Alertmanager stack, and explicit logging of authentication rejections.
What changes for you
You debug against a documented operational model, and the product tells you where it hurts rather than making you infer it.
- 5The restore
Proving you can actually recover
Backups that have never been restored are a hypothesis. At some point you will have to prove the recovery path, ideally before you need it.
What you have to answer
- Is there a real restore runbook, or just a backup script?
- What surprises does a restore introduce?
- Do purge obligations survive a rollback?
The layer that answers it
Backup and DR as artifacts
Backup scripts and a restore runbook exist as first-class operational artifacts, with two documented consequences called out explicitly: a restore resets credentials seeded at that point in time, and restoring into a shared environment can reintroduce previously purged rows, so outstanding purge obligations must be re-run.
What changes for you
The recovery path is documented including its side effects — which is the part every other vendor leaves for you to discover during the incident.
Control register
Every layer above is documented there in full, including the threat model and the control-status register.
Beneath the controls, the platform itself.
The five capabilities every SigmaEra deployment runs, read through the lens of this role.
Five stages · Protect → Emerge- 01
Protect
Your Vault, your Postgres, your identity provider. Signing keys rotate on a 90-day schedule and no key material is baked into an image.
- 02
Orchestrate
One deployment instead of a per-team tool sprawl — a Helm umbrella chart with bring-your-own or bundled datastores, and health and readiness probes on every service.
- 03
Automate
Retention, purge SLAs, and tombstone reaping run as declared background work rather than as tickets that land on your queue.
- 04
Compound
Metrics, alerting, and DR runbooks are first-class artifacts, so the operational picture gets clearer as the deployment ages rather than murkier.
- 05
Emerge
Auth failures are explicitly instrumented, so credential stuffing is distinguishable from a misconfigured client instead of blending into login noise.
The Compound Effect
Intelligence that builds on itself.
- 100%
- of AI interactions governed — every call through one policy enforcement point, with a full audit trail. Source: Platform security white paper — Governance & AI policy
- 48h
- to full AI governance — from shadow AI discovery to unified control plane.
- 8
- must-follow platform standards, each with a named enforcement gate in CI — control coverage mapped to SOC 2, GDPR and HIPAA expectations. Source: Platform security white paper — Standards alignment
Stop leaking data. Start compounding intelligence.
See What You Would Actually Operate
- Runs air-gapped inside your own boundary
- Full audit trail on every interaction
- 100 agents, one control plane