Go live with a project

This page is for the team taking a revenexx project to production: the developers who built it and whoever signs off the launch. It lists what has to be settled first, in one place, with a link from each item to the page that covers it. Most of it is decided once per project, and several items need a person in Cockpit rather than a line of code.

It has two parts. Your checklist is work your team does. What the platform already does covers what you don't configure but a security review will ask about. This page owns that second table; Operate & go live and the security questionnaire guide link here rather than repeat it.

Your checklist

Access

• One key per job, named for where it runs. order-sync-prod, not main. A leaked or rotated key then affects one job, not all of them. See API keys.
• Only the scopes that job uses. A key that reads orders doesn't need write access to customers. A missing scope shows up as 403, so it fails loudly rather than silently. See Scopes.
• Separate keys for your staging and production tenants. A key identifies one tenant, so a key you tested with on a staging tenant cannot call production.
• Keys on servers only, loaded from a secret manager. Never in a browser, a mobile app or git. See API keys.
• A rotation plan with a date on it. Keys don't expire on their own. Rotate on a schedule and whenever someone with access leaves: create the new key, deploy it, revoke the old one. See Rotate and revoke.
• Someone who knows how to revoke a leaked key. Revocation in Cockpit takes effect within seconds. See Rotate and revoke.

Domains

• One DNS record per domain, in the zone of whoever owns the domain, which is often your customer. A CNAME for a domain that serves a storefront, an A record for one that redirects. Copy the value from the domain's DNS & TLS view in Cockpit rather than from a document. See Domains.
• A person, not a script, to add them. Adding and verifying a domain is a Cockpit action with no public API (as of 2026-09), so plan it as a step someone does by hand. See Domains.
• A decision for the apex. example.com can't take a CNAME. Use your DNS provider's apex flattening, or serve www.example.com and make the apex a redirect to it. See Apex domains.
• A check for existing CAA records. If your zone already has any, they must permit Let's Encrypt, or the certificate fails after the domain verifies. See CAA records.
• Nothing in front of the domain that blocks or redirects /.well-known/acme-challenge/ on port 80. Certificate renewal runs through it, and a blocked challenge fails silently until the certificate expires. See Certificates for your domains.

Caching you control

• A cache block only on App capabilities that are safe to cache. No block means never cached, which is the right default for writes and for anything a caller acts on at once, such as stock or a balance. See Caching.
• The default cache scope, principal, unless the data is the same for every caller. principal keeps one entry per caller. tenant shares one entry across the tenant and is only for tenant-wide reference data such as markets or currencies. See scope is the one to get right.
• Two calls to each cached route, expecting X-Cache: MISS then HIT. A second MISS means something in the request varies that you didn't intend. See What a caller sees.
• The tenant in every cache key your Theme writes. A branding or catalog cache keyed without it serves one customer's data to another. See Partition every cache by tenant.
• Changed assets under a new URL. The edge holds an entry for an hour and has no purge API (as of 2026-09). A new path, or a new set of transform parameters, is fetched fresh. See The edge cache.
• Your own proxy, if you run one, honours private, no-store and Vary. Ignoring them is how a permission-filtered response reaches the wrong user. See Caching in the client.

Limits and capacity

• A request budget per tenant, written down before launch. The tenant's API limit is shared by every key, the storefront server and every script, and a 429 is a limit to handle, not a setting to change. Batch loops, page to the end and give every client a limiter and a capped backoff. See Size a launch.

Deploy safety for Themes and Sites

• Every Theme deployment checked on its preview before it is activated. View source for real server-rendered HTML, and confirm live data and branding on first paint. See What to check on a preview.
• A domain protected before a customer's unreleased storefront is on it. Preview hostnames already require a signed-in tenant member; a domain you point at the site is public. Basic auth or an IP allowlist, set once per domain in Cockpit. Use the exclude list for public paths such as a health check; setting an include list makes everything else public. See Protecting a domain.
• A rollback you have tried, before you need it. Activating an earlier ready deployment switches what the site's production domains serve, without a rebuild or a DNS change. A domain pinned to a Git branch keeps serving that branch. On a Git-connected site, push a revert commit as well, or the next push rebuilds the bad one. See Instant rollbacks.
• A plan for configuration regressions. A rollback doesn't restore environment variables, build settings or domains, because those belong to the site, not the deployment. Change the configuration back, then create a new deployment. See What rollback does not change.
• A version bump for every Theme manifest change. A published Theme version is immutable, and a new block reaches editors only through a new version. See Publishing a theme.

Deploy safety for Apps

• Every App release deployed to a staging tenant first, verified there, then deployed to production and verified again. Name the tenant on each deploy with --tenant (CLI 0.5.0 or later), so a saved default can't send it to the wrong one. See Deploying.
• A new App version on every build, and a new capability for every breaking change. The old route keeps serving until every caller has moved, and a tenant can stay on an older version of your App. See Versioning.
• POST /defaults in the App's deploy script. Installing doesn't reliably seed anything. Write /defaults to be idempotent so the call is safe to repeat. See Call /defaults explicitly.

Observability

• Request logs turned on for a server-rendered storefront. The site's Logging setting controls them, and its Activity tab lists them, filterable to failures. Static sites produce none. See Logs.
• One log line per App invocation, with the request ID, the tenant and the outcome. It turns "slow at 14:20" into a lookup. Never log a sensitive setting or personal data: whoever operates the tenant can read these logs. See Operating an App.
• Tracing configured if you want to see where the time goes. Point the App's OTEL_* variables at your own collector, then redeploy. Without them, nothing is traced. See Tracing.
• Your own X-Request-ID on every call, logged with the response. A request the gateway refuses doesn't echo one back, so the ID you sent is the one you can quote. See Request IDs.
• A store you control for logs you must keep. Log retention on the platform isn't published (as of 2026-09), so decide now where audit and compliance logs go. See Retention.
• A named person watching the first hour. There is no App alerting to configure (as of 2026-09), so someone has to look. Watch the storefront's failures in Activity and the App's Deployments, Anatomy and Usage screens, and look for 429 responses in your own clients. See After each release.

Support

• An answer ready for the customer's security review. A questionnaire arrives before most launches. Map each area to a page or a contract clause and send what only revenexx can settle as one list. See Answer a customer's security questionnaire.
• Advance notice to support.revenexx.com before a launch that will draw unusual traffic. The edge's DDoS filtering has no published capacity (as of 2026-09), so a launch or public campaign that revenexx knows about can be watched rather than discovered. See What it does not cover.
• status.revenexx.com bookmarked by whoever is on call. An incident listed there is already being worked on and needs no support request.
• The escalation path written down. Requests go to support.revenexx.com, with the request ID, the tenant slug, the endpoint and method, the time in UTC, and the actual response. See Get help.
• Your customer told which response times apply. They depend on the plan and the priority of the request, and are set in the terms (§ 21 and Annex 4). Better they hear it from you now than during an incident. See What to expect back.

What the platform already does

Your team configures none of this. It's here because a security review will ask, and the answer depends on which host a request goes to. Storefront domains you point at the edge are served by the points of presence. api.revenexx.com is answered by the origin in Germany, with no point of presence in front of it.

api.revenexx.com has no firewall, DDoS filtering or compression in front of it. Every request must carry a credential, and the per-tenant rate limit applies to those requests. A 429 is a limit your code handles, not a setting anyone changes, and the SDKs don't retry for you: honour Retry-After and back off. See Handling it.

Where to go next

• Size a launch: size the request budget, batch calls and warmup before launch.
• Answer a customer's security questionnaire: the security review that usually comes with a launch.
• Operating an App: what to watch after launch day, and what to hand over when you escalate.
• Debug a failed request: from a failed call to its cause.
• Publishing a theme: registering, installing and activating a Theme, with deploy and rollback links.