The 12 points we check on the server, domain, backups, security and monitoring before taking a web application live, and why each one is there.
An application’s riskiest day is launch day. The code is ready and tested, but one small gap on the server, domain or email side keeps the first customer waiting at the door. Every time we move an application we built onto a server we run, we go through the same list.
Short answer: domain and SSL, email authentication, environment variables, database permissions, backup and restore, firewall, updates, error logs, monitoring, caching, robots and sitemap, and finally a rollback plan. Below is why each one is on the list.
Domain and access
1. Domain, SSL and redirects. The domain’s renewal date and the account it lives in are written down. Either www or the bare domain becomes the main address and the other redirects to it with a 301. HTTP always goes to HTTPS, and automatic certificate renewal is verified.
2. Email authentication. If the app sends password resets, order confirmations or form notifications, SPF, DKIM and DMARC are ready before launch. Otherwise the first user’s password reset lands in spam.
Application and data
3. Environment variables. Debug mode is off, secrets live only in the environment file on the server and never entered the repository. Development keys are never used in production.
4. Database permissions. The app connects with a user that only has rights on its own database, never as a superuser. The database port is not open to the internet, or only over TLS from specific addresses.
5. Backup and a restore test. Scheduled backups go to a location off the server. A restore is tested at least once before launch; an untested backup is not a backup.
Server
6. Firewall. Only the ports that are needed are open: usually 80, 443 and SSH. SSH uses keys, not passwords.
7. Updates. System packages are current and automatic security updates are on. PHP, Node or the database run a version that is still supported.
8. Error logs. Everyone knows where application and web server logs are written, and log rotation is on. The disk never fills up with a forgotten error log.
9. Monitoring. Whether the site responds is checked from the outside on a schedule, with thresholds for disk, memory and services. We should notice a problem before a customer does.
Launch
10. Caching and compression. Static files are served with long-lived caching and text responses are compressed. Images are the right size and in a modern format.
11. Robots, sitemap and share images. The staging site is closed to search engines and production is open. The sitemap is ready, page titles and share images are checked, and the sitemap is submitted to search engines after launch.
12. A rollback plan. How to return to the previous version if something goes wrong is written down before launch, database changes included.
Summary
None of these points is hard; remembering all of them in the rush of launch day is. When the team that writes the application also runs the server, this list is not passed between two teams but closed by one. See our VPS and server management page for details.