Operate & go live
What you do after the code works — take an App, Theme or integration to production, keep it healthy, and find out what went wrong when a call fails.
The other guide paths end at a working deployment. This one starts there.
Going live is a different job from building: you are settling access, domains, rollbacks and escalation rather than writing features, and most of it is done once per project by someone who will not touch the code again. The reference pages below already describe each piece. The guides in this bucket stitch them into the order you actually need them.
Before you go live
You need these decided, not just deployed.
- Production keys. Separate keys per environment, scoped to what the caller genuinely needs, and a plan for rotating them. See API keys.
- A domain. One CNAME in your own zone. See Domains.
- A rollback you have tried. Not the first time under pressure. See Instant rollbacks.
- Somewhere to look. Know where your logs are before you need them, not after. See Logs.
- An escalation path. Who you contact, and what they need from you. See Get help.
What the platform already handles
A security review will ask about these. None of them is a task on your side.
| Concern | What happens | Reference |
|---|---|---|
| TLS | Certificates issued and renewed automatically | TLS |
| Web application firewall | Managed, on for every tenant | WAF |
| DDoS filtering | On by default, nothing to enable | DDoS |
| Compression | Text responses compressed at the edge | Compression |
| Rate limits | Per tenant at the gateway — a 429 is a limit to handle, not a setting to change | Rate limits |
Operating what you shipped
- Apps — Operate an App in production puts the pieces in order; Operating, Verifying live and Versioning are the reference behind it.
- Themes and Sites — Deployments, Previews and Logs.
- Anything calling the gateway — Errors, Idempotency and API versioning.