Ship your product into Sovereign Mode.

You bring three artifacts. The pipeline returns a running, attested, contained deployment your buyer’s security team can verify without trusting you or Ember.

WHAT YOU BRING

• A digest-pinned container image. name@sha256:… only — tags are rejected, because a tag can move after review and a digest cannot.
• An env index card. The names of the secrets and settings your image needs. Secret values are never part of the submission — they are read at deploy time and sealed to the attested environment.
• An egress manifest. The exact hostnames your product is allowed to reach (port 443 only). No wildcards, no IP literals. This list becomes measured policy, not configuration.

WHAT THE PIPELINE DOES

From those three artifacts, the release pipeline renders a contained deployment: your image runs inside an attested confidential VM whose only network exit is a policy proxy, and the policy — your egress manifest — is inlined into the deployment measurement itself. The measurement is approved on-chain by the governing smart contract account before anything boots, secrets are sealed to the attested environment, and the silicon↔chain evidence is captured so the claim is checkable later, by anyone.

The consequence vendors care about: a config edit cannot widen your access. Any change to the image or the egress list produces a new measurement, and a new measurement requires a new on-chain approval. That is what makes the sovereignty claim durable instead of contractual.

THE WALKTHROUGH

Onboarding runs through the ember CLI against a provisioning endpoint and vendor token you receive from Ember:

# one-time setup
npm install -g @ember-sovereignty/provisioner
export EMBER_API=<from Ember> EMBER_TOKEN=emv_…

ember init                          # scaffold ember.json — the index card
ember deploy                        # secrets read from your shell env, sealed at deploy
ember status                        # deployment state + attestation evidence
ember egress add api.example.com    # a governed ceremony, not a config edit
ember release name@sha256:…        # ship a new version through the same ceremony
ember verify                        # trustless: attestation quote + chain, checked directly

When the buyer’s institution holds the governing account, ember release splits into propose → approve → commit: you propose the new measured version, the institution reviews the exact diff and approves on-chain, and the pipeline commits the upgrade the moment the approval lands. The chain is the approval bus — no one’s database is trusted.

PROVE IT, DON’T PROMISE IT

ember verify is the honest line, executable: it fetches the live attestation quote, hashes the measured deployment, and checks the approved-measurement list on-chain — directly, trusting neither your infrastructure nor Ember’s records. It is the same check your buyer’s security team runs on the verification page →