> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EDI Deployment and Qualification

> Dated rollout, image, migration, capacity, and recovery evidence, with clear boundaries for customer and hosted qualification.

Review exact source, image digests, schema, configuration, and retained results together.
The evidence below was reviewed October 20, 2026 from the source deployment record and
production-completion tracker. It does not establish a service-level commitment.

## Retained deployed baseline

The October 20 rollout record identifies **v0.10.2**, source `b1f7aa9`, with two ready API
replicas and two ready dashboard replicas. Its checks covered health, database/signing,
public rendering, and unauthenticated private-route denial. They submitted no partner
orders and did not establish a real signed-in customer journey or ERP acceptance.

| Component | Recorded immutable image |
| - | - |
| API | `ghcr.io/stateset/edi@sha256:23386fdabf2fa6ef1f89927a74f2c811ee8c19a632f10d251a2ee3086ac04c2d` |
| Dashboard | `ghcr.io/stateset/edi-dashboard@sha256:ddefa75073a1ef70133ecf1a73649d413f62b87f185d2cf405292a6a6c974159` |

These images were locally built/pushed through the maintained fallback. They are not
GitHub OIDC-signed release artifacts. Hosted release CI remained blocked by account
billing/spending limits in the retained record.

The database reached migration **71** after an isolated logical restore and upgrade check.
Rollback used a separately tested compatibility image containing the newer migration
files; the previous unmodified image is not the qualified rollback target. Keep the expanded
schema rather than assuming migrations can be reversed.

## Newer release-assurance source

Commits after that deployed tag add migration-before-rollout enforcement, backup failure
handling, and exact-image release promotion. The maintained deploy helper verifies the
requested release identity and digests; `--verify-only` does not deploy or migrate.

```bash theme={null}
# From the source checkout, with the intended release tag:
deploy/hetzner-deploy.sh --release vX.Y.Z --verify-only
```

A reviewed deployment must use a fresh migration Job with the exact candidate API digest
and required database secret, wait for completion, then roll API before dashboard. Serving
replicas do not migrate by default. `stateset-edi migrate` needs a nonempty `DATABASE_URL`;
a failed migration is not a successful file-mode startup.

The prepared hosted workflow gates publication on CI, builds a candidate once, scans its
immutable digest, runs a sustained capacity profile, signs/verifies that digest, and promotes
the same manifest. Source implementation is not evidence that the hosted workflow ran or
that the deployed fallback images gained signatures.

## Capacity evidence

An isolated five-minute run used the exact digest-pinned deployed API image: two API
containers at two CPUs/512 MiB each, plus PostgreSQL 16 at two CPUs/1 GiB. It accepted
7,500 synthetic orders across two tenants at 25/s, with 1/10/100-line payloads, p95 scheduled
offer latency 18.142 ms, and a 4.758-second backlog drain. Duplicate/billing and tenant-key
checks passed. Durability settings remained enabled.

The host was shared; an earlier development-binary run failed the same offered workload
and is retained. These results do not establish maximum throughput, production capacity,
ERP performance, or a customer SLO. The test used synthetic effects and no partner/ERP
accounts. Later harness safeguards have separate smoke evidence.

## Recovery and secrets

Retained drills cover process loss, logical restoration, and isolated physical PITR with
58 tables and encrypted credential revisions. Recover the matching connection-encryption
key, signing identity, transport credentials, and retained revisions alongside the database.
A green health check cannot establish that encrypted pending work can be resumed.

The optional logical-backup CronJob template validates a private custom-format archive
before atomic publication and keeps seven completed archives. The retained production
inspection found that optional CronJob absent; CloudNativePG base backup/WAL and the
verified pre-upgrade logical snapshot are the production recovery evidence. A template
change does not install a schedule or measure production RPO/RTO.

## Remaining qualification

Actual partner-guide acceptance, ERP create/change/cancel and remote-commit recovery,
independent WorkOS signup/revocation, production failure/load/restore objectives, independent
security review, and staffed support/on-call commitments need their own evidence.
Console response-loss/401/reload recovery in source `3f6b5c0` is locally qualified,
not established as deployed. See [orders and recovery](/stateset-edi/orders-and-recovery).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.