Skip to main content
In development. Managed operation through 86d.app is still being built. This page describes the contract a managed Workflow is written against. See maturity levels.
Provisioning a Store touches several systems that cannot share one database transaction. If a browser tab could cancel that halfway through, you would end up with a domain pointing at a database that no longer exists. So 86d does not let a request own the outcome. A managed operation writes a durable Workflow before the request that started it returns. The request then tries to advance it, because that is faster when it works. Whether it works or not, the Workflow finishes on its own. Close the tab. Lose your connection. The Store still gets built. Managed provisioning, domain, and workload-identity facts for those Workflows persist through Control Plane Drizzle/PostgreSQL. The Control Plane stores provider resource identities, opaque secret references, health, and operation history. It never stores a raw managed database URL. The managed *.86d.store front door publishes the DNS records 86d Cloud needs for that hostname (routing plus ownership verification), then serves HTTPS only after the hostname responds healthy. Compensation and development teardown remove those owned DNS records before detaching the hostname or destroying the Managed Deployment. store.provision is the only activation entry that starts Cloud benefits. Identity create leaves the Store unprovisioned. Successful Launch provision starts the 30-day trial, grants Promotional Credit, and creates the entitlement together after health; failure does not consume Launch. Console surfaces create, progress, and detail states for that Workflow, and activation notifications enqueue through the Control Plane outbox with a Store-scoped dedupe key.

​
What a Workflow reports

Every Workflow reports one of six states, and it reports the truth rather than the optimistic reading: A Workflow never reports completed because one external call returned 200. Half of a provisioning run succeeding is not success, and reporting it as such is how merchants end up paying for infrastructure that was never wired up.

​
Reading a state as an agent

If you are an agent acting on a managed Store, three rules:
  1. Creating a Workflow is not completing one. A 202 means it was accepted. Read the terminal state before you tell anyone the Store exists.
  2. A successful provider call is not a completed Workflow. Multi-step operations fail on step four regularly.
  3. needs_attention is not a retryable error. Retrying it does nothing. Surface the reason to a person.

​
When one needs attention

needs_attention means something outside 86d’s control has to change: a provider declined, a Connection was revoked, a domain is not verifying, a payment method was rejected. The Workflow holds its position rather than failing outright, so resolving the underlying thing lets it continue rather than starting over. The reason is shown in plain language in 86d Console. It names what to do next, not an internal error code.

​
Why retries are safe

Every step in a managed Workflow is idempotent, and each one records the provider result it observed. That is what makes ambiguity survivable: when a call times out and 86d cannot tell whether it landed, the retry reconciles against what actually happened rather than doing it a second time. The properties this holds to:
  • one operation, one provider effect, however many times it is attempted
  • a retry cannot move state backward
  • two concurrent attempts cannot both settle
  • a step whose lease expires reconciles against the recorded provider result rather than guessing
  • a terminal Workflow releases its lease and reports honestly
This is why you can safely retry a provisioning request that appears to have hung, and why an interrupted deploy does not leave you paying for two databases.