Skip to main content
Every record carries an environment, and the value is sealed inside the signed bytes. That is what makes the two modes safe to run side by side: a dev record can never be presented as production evidence, because the word dev is inside what the signature covers. This page is the move from one to the other.

​
The two environments

dev and production are the only accepted values. Anything else is refused before an envelope is built.
  • dev is for building the integration. Records are permanently marked dev, and no counterparty can be handed them as production evidence.
  • production writes to a permanent public record. A record cannot be withdrawn once it is written.

​
Set it explicitly

Neither SDK has a default. environment is required in both, from @sanning/anchor and sanning-anchor 0.15.0, so a service cannot inherit the wrong one by omission. In TypeScript, an anchorer built with no signer and no subject in dev generates an identity for you and says so, loudly, on the way past.
production writes to a permanent public record. Records cannot be withdrawn, and a locator you pass is published verbatim along with them. Make the switch a deliberate edit rather than a value read from an environment variable you have not looked at.

​
What production means

Three things change, and each one is a refusal rather than a warning you might miss:
  • Production refuses an auto-generated identity. In TypeScript, building an anchorer for production without an explicit signer and subject raises ProductionConfigError at construction, so a dev-mode identity cannot reach it by accident. Python cannot reach that state at all: signer and subject are required arguments.
  • The environment is inside the signature. Nothing downstream can relabel a dev record as a production one. The value travels with the evidence.
  • Retention stops being optional. The plane refuses a production envelope that names no log store (400 no-log-store). A production record whose locator is neither the payloadRef you pass on the call nor the answer from your log store’s locatorFor raises ProductionConfigError before it is signed, so nothing is sent and the chain does not move. Building the anchorer does not throw for this. See the log store.

​
Move an agent to production

  1. Create the production key in the console. Every key can anchor, which is what a production runtime needs. API keys and scopes covers what that covers.
  2. Generate a signing seed for this agent and put it in your secret store. Load the same seed on every boot.
  3. Configure a log store that outlives the process, in object storage you control. Keep what you anchored has the shape.
  4. Change environment to production, and deploy.
  5. Build a pack for a short window and verify it yourself before anyone asks. The Quickstart ends with the two commands an auditor runs.
Give the dev version of an agent its own agent_id, such as claims-triage-dev. Two reasons: an identity is its signing key, so a second key under one name is read as a rotation, and a pack carries one environment.

​
A pack carries one environment

The bundle command refuses to assemble a window that mixes dev and production evidence for one agent. Mixing them in one deliverable would hand the reader the job of noticing, and that is the reader whose whole task is deciding what the evidence supports. Separate agent names keep the two apart without anyone having to think about it.

Keep what you anchored

The store production expects, and the bucket it belongs in.

API keys and scopes

The key production needs, and the two things a key can do.