Go-live checklist

Going live on managed.dev is a self-service operation — you don’t file a ticket and wait. This checklist walks the whole launch in order: plan the cutover, prepare the production environment, run pre-launch verification, move DNS and TLS, then clean up. Work top to bottom and the cutover is a formality.

Already migrating from another host?

If you’re moving an existing site, the migration team brings it up on a branch environment for you first — start with migrate a site, then come back here for the launch itself.

Phase 1 — Plan

1. Pick the launch window. DNS cutover is zero-downtime, but a quiet window keeps support load low if something needs attention.
2. Lower your domain’s DNS TTL at least 24 hours ahead at your current registrar/DNS provider — drop it to 300 seconds so the cutover propagates fast. You’ll raise it again afterward.
3. Decide the production environment. The default branch (main) maps to production via branch routes; confirm that’s what you want live.
4. List the moving parts: the apex (example.com) and www, any subdomains, redirects, and third-party services that hard-code the domain (payment webhooks, OAuth callbacks, transactional mail).

Phase 2 — Prepare the environment

Get production into a known-good state before you point any traffic at it.

1. Deploy the launch commit to production with a push to your default branch.

   Deploy to production

   git push managed main

2. Open a shell on the production environment over the SSH gateway so the rest of the checklist is copy-paste.

   Connect over the SSH gateway

   ssh acme-store@ssh.managed.dev

3. Confirm the runtime and site profile are what you expect (bedrock, vanilla, or static), and that the database and uploads came across intact.

Phase 3 — Pre-launch checks

Run these against the production environment before DNS moves. Many of them use WP-CLI, which is available on every plan.

1. Search-replace the site URL. If content still references a staging or old host URL, rewrite it. Always run --dry-run first and read the count.

   Rewrite URLs in the database

   wp search-replace 'https://old-host.example' 'https://example.com' --dry-run
   wp search-replace 'https://old-host.example' 'https://example.com' --all-tables --report-changed-only

2. Verify home and siteurl. They should be your final production domain.

   Check core URLs

   wp option get home
   wp option get siteurl

3. Verify plugins and themes. Confirm the expected set is active and at the versions you tested. The dashboard’s plugin & theme inventory shows the same data across every environment.

   List active plugins and the active theme

   wp plugin list --status=active --fields=name,version,update
   wp theme list --status=active --fields=name,version

4. Warm the caches. The page and object cache ship tuned; prime them by flushing and then crawling the top pages so the first real visitor isn’t the one paying for a cold cache.

   Flush and warm

   wp cache flush
   wp rewrite flush

5. Check insights. Open performance insights and the traces view for the production environment and confirm there are no 5xx spikes or errors on the launch build before you send real traffic to it.

   The Insights tab for the production environment in app.managed.dev, showing the p95 latency line flat and the traces list with no error-status rows on the latest deploy.

Tip

Run the same search-replace and plugin checks on a preview environment first if you want a rehearsal that can’t touch production.

Phase 4 — Cut over DNS + TLS

1. Add your domain to the site so managed.dev knows to serve it — see custom domains. TLS is issued and renewed automatically; the certificate is prepared ahead of the cutover so there’s no gap.

2. Update your DNS records at your provider to the values managed.dev shows for the domain (apex and www). Because TTL is already low, propagation is quick.

3. Watch traffic shift over. Old and new hosts both serve correctly during propagation, so there’s no downtime window to manage.

   The Domains panel in the dashboard for example.com, showing the DNS records to set, a “verified” badge once they resolve, and the TLS certificate marked active.

Don't decommission the old host yet

Leave your previous host running until propagation completes and you’ve confirmed the new site is serving on the real domain with valid TLS. Only then tear it down.

Phase 5 — Post-launch cleanup

1. Take a snapshot. Capture a clean point-in-time snapshot of the freshly-live site so you have an instant rollback point.
2. Raise DNS TTL back to a normal value (e.g. 3600+) now that the cutover is done.
3. Reconnect third parties. Update payment webhooks, OAuth callback URLs, and any external service that pointed at the old domain.
4. Confirm mail. managed.dev delivers transactional mail (password resets, notifications); send a test reset to confirm it’s flowing — see transactional email.
5. Watch the first hours. Keep an eye on requests and security blocks so you catch any post-launch surprise early.

Next steps

Custom domainsAdd and verify the domain you're launching on.

Automatic TLSHow certificates are issued and renewed for your domain.

WP-CLIThe command reference behind every check on this page.

Snapshots & backupsCapture a rollback point right after you go live.