86d Console asks for a managed operation. The Control Plane behind it decides whether you are allowed to do it, does it, and keeps the record.
Who owns what
That split is why 86d can promise your data is portable. The Control Plane knows your Store exists, which plan it is on, and whether its deployment is healthy. It does not know what you sell.
Under the planned Command model, each side also owns the audit record for the facts it changes. The Control Plane can coordinate work that crosses both, and the coordination record references the commerce record rather than copying it.
How commerce records relate covers the Order, Payment, Fulfillment, and Shipping boundaries in detail.
Standalone and managed
The same Store Runtime runs both ways:
A standalone Store needs no 86d Account and makes no call to the Control Plane. Managed operation is still being built, so check 86d Cloud plans for the current state of the offer.
When a Store runs on 86d Cloud, it receives a managed hostname derived from the Store name (
example.86d.store, or dev-example.86d.store during development). Conflicts append a numeric suffix. You can still attach your own domain later; the managed hostname stays assigned.
What you see from 86d
Managed capabilities appear as 86d Cloud, 86d Payments, managed hosting, managed email, and managed AI. Upstream suppliers behind those services do not appear in 86d Console, Store Admin, emails, pricing, support, or errors. When you bring your own Connection or host the Store Runtime yourself, the provider you chose may appear because that relationship is yours.One Store, one database
Every Store Runtime is single-tenant: its own deployment, its own PostgreSQL database. Managed infrastructure may sit on shared provider accounts, but each Business and Store stays separately scoped and separately billed. This is a deliberate cost. Multi-tenancy would be cheaper to operate and would make your data harder to leave with. When a managed service genuinely needs an operational detail from a Store, a narrow Store-scoped projection can cross the boundary. The system receiving it does not become the authority for that fact.Inside a Store Runtime
The open-source repository is laid out like this:How Modules talk to each other
Current: declaredrequires and exports contracts plus an in-memory event path. Module storage is compiled Postgres tables under mod_<moduleId>. Framework tables and core.* are owned by Drizzle.
Target: typed synchronous capability calls for immediate decisions, versioned events through a durable transactional outbox for everything afterward, and Postgres role isolation with column-projected published views for reads across Modules. Four framework tables (core.party, core.subject, core.transaction, core.module_config) hold cross-Module invariants; they exist in the schema but are not read by Modules in production yet.
That migration is happening one capability at a time and is not finished. Do not rely on durable cross-Module delivery or compiled table storage in production yet.
Managed identity
A newly provisioned managed runtime receives three values together:86D_STORE_ID, 86D_API_URL, and 86D_WORKLOAD_CREDENTIAL. The runtime trades that opaque credential at a dedicated Control Plane endpoint for short-lived tokens scoped to one Store, one audience, and one set of capabilities.
The credential is rotatable and revocable, rotation allows only a bounded overlap, and revoking it stops new exchanges. It holds no provider secrets and is not a configuration bundle in disguise. Partial managed configuration fails closed: a configured managed runtime does not quietly fall back to a local Template when the Control Plane is unreachable.
Standalone Stores use STORE_ID for local data isolation and never call the Control Plane. Human sign-in to a managed Store Admin uses a separate pair, 86D_ADMIN_OAUTH_CLIENT_ID and 86D_ADMIN_OAUTH_CLIENT_SECRET. No machine credential can authenticate a person. See environment variables and authentication.