"Before you go live: a launch checklist"

A site that works on your laptop and a site that is ready for customers differ in a handful of boring things: encrypted traffic, a backup you have actually restored, a way of finding out when something breaks, a firewall that is not wide open and a plan for when a deployment goes wrong. This checklist walks through each, in the order that costs least to fix, and points at the screen where you verify it.

Do not try to do everything on launch day. Run through the list a week before, fix what is red, and tick it again the day before.

Before you begin#

• A site that deploys. You have done Deploy your first site in ten minutes at least once, and your real domain is ready to point at the server.
• The right plan. Database backups and server monitoring are included from the Pro plan; teams and roles need Business. The free Hobby plan has neither (see Plans and limits compared).
• Permission. Some items need an Owner or Admin: connecting notification channels, requiring two-factor and changing the firewall.

1. HTTPS on your own domain#

Visitors and search engines expect HTTPS. A certificate is issued once the domain resolves to your server.

1. Certificate in use. It shows the names it covers, the issuer, the expiry date and whether renewal is automatic. Check that every name you serve is covered, including www.
2. Force HTTPS. Redirects every HTTP request to HTTPS. Turn it on once the site works over HTTPS, as the card says.

Steps and troubleshooting are in Get a free Let's Encrypt certificate. Port 80 must stay open so renewals work.

2. DNS and the domain#

On the site's Domains tab, each hostname shows Points here when its DNS record reaches your server. Create an A record (and AAAA for IPv6) at your DNS provider for the bare domain and for www. Lower the record's TTL a day before a move so a mistake corrects quickly. See Add a domain, a free subdomain and DNS records. If the old site is still live elsewhere, switch DNS only when the new one has been tested on its free srvy.sh name.

3. Environment and secrets#

Open the site's Environment tab. Check APP_ENV=production, APP_DEBUG=false, a real APP_URL with https://, and that no development keys or test mail credentials remain. Never commit .env to Git; SrvYard keeps it as a shared file outside the releases (Edit environment variables). After changing it, deploy again so the application picks it up.

4. Backups, and a restore you have tried#

A backup you have never restored is a hope, not a backup.

1. New configuration. Creates a scheduled backup of your databases to your own storage. Add the storage provider first (Add an S3-compatible storage provider).
2. Recent backups. Each run shows its status, duration and size. A run that is Finished with a plausible size is what you want; a sudden drop in size is a warning.

Then restore one into a scratch database and open it (Restore a database or files). Also consider file backups for uploaded files and provider snapshots for the whole machine.

5. Know when something breaks#

Decide who hears about problems, and how, before the first one.

1. Deployment failed emails. Extra addresses told about failed deployments, next to the owners and admins.
2. Add channel. Sends events to Slack, Discord, Telegram or email: deployments, servers, certificates, backups, monitors and more.
3. A channel. Shows its events, severity filters, whether the last message was Sent or Failed, and a Test button. Press Test on every channel now: a channel that fails silently is worse than none.

Then add a heartbeat for each scheduled task that matters, so you hear when it stops.

1. Add heartbeat. Creates a URL your task pings when it finishes.
2. Missed. The status when no ping arrived in time. SrvYard notifies you, so a nightly job that quietly stopped does not go unnoticed. See Heartbeats and uptime checks and Alert thresholds and silencing.

6. Lock down access#

1. Require two-factor authentication. Members without it can only open their security settings until they turn it on. Switch it on before the team grows.

Also: give each person the lowest role that lets them work (Roles and permissions), remove keys of people who left from each server (Add SSH keys to a server and to your account), and review the firewall: only SSH, HTTP and HTTPS should be open to everyone, and databases should be limited to the servers that need them (Open and close ports with the firewall).

7. Deploys, rollbacks and capacity#

• A deploy script you trust. Run it on staging first (Write and test a deploy script).
• Zero downtime. If the site was created with it, deployments switch over only when the build has finished, and you can go back to a previous release (Zero-downtime releases and rollbacks).
• Queue workers and the scheduler. Confirm the daemon is Running and the Laravel scheduler job is Active (Keep long-running processes alive with daemons).
• Headroom. Look at the server's Usage card and the Monitoring tab at a normal time of day. If memory or disk is already above about 70 percent, resize or add a server before the launch, not during it.
• Your plan. Check Usage that you are not at the limit of servers, sites or deployments.

8. Launch day#

On the day, change one thing at a time and verify after each. Point DNS, wait for Points here, check HTTPS, deploy the final commit with Deploy now, read the deployment log to its last line, and visit the site in a private window. Keep the previous release available for a rollback and keep the support chat or your own channel open for the first hour. Afterwards, look at the Monitoring tab again and at the activity log for anything unexpected, and send the team a short note saying what changed and where to look if something is wrong. Write down who is on call, what the alert channels are, and how to roll back, so that the person on duty at two in the morning does not need to ask.

The checklist#

1. HTTPS works on every name and HTTP redirects.
2. DNS points at the server and shows Points here.
3. Environment is production, debug is off, secrets are real.
4. A backup runs on a schedule and you restored one.
5. Notification channels tested, heartbeats added for scheduled work.
6. Two-factor required, roles minimal, firewall tidy.
7. Deploy script tested, rollback understood, queue and scheduler running.
8. Server has headroom and your plan has room.

Troubleshooting#

• The padlock shows a warning. The certificate does not cover the name you typed, or the page loads insecure resources. Check the names on the SSL tab and look for http:// links in your pages.
• The site works by IP address or free name but not on my domain. DNS has not propagated or points elsewhere. Check Points here and your provider's records.
• A channel shows Failed. The webhook or token was revoked. Edit the channel and test again.
• A backup run is missing. The schedule time is in the server's timezone; check Next run on the configuration.
• Everything is fine in staging but not in production. Compare the environment files and PHP versions of the two sites.
• I am not sure who gets alerts. Owners and admins always receive deployment failures; every other recipient is one you added.

Related#

• Get a free Let's Encrypt certificate: the HTTPS step in full.
• Schedule database backups: set up the backup.
• Notification channels: email, Slack, Discord, webhooks: the alert channels.
• Hardening checklist: firewall, SSH, updates: the security half of going live.