1. A way back before any change
Confirm a provider console, rescue mode or a snapshot you can restore. Take a snapshot now. Check: you can describe how you would get into the server if SSH stopped working. Nothing else should start until this is true, because the next two steps can lock you out.
- Console or rescue mode available.
- A snapshot taken today.
- A second SSH session open for the whole of step 2.
2. Access and firewall
Add each administrator's public key, test each from a fresh session, then turn off password and keyboard-interactive login and read the effective settings. Allow SSH in the firewall before enabling it, then the web ports and anything else you listed, and test again. Check: a password attempt is refused, each key works, and only the listed ports are open from outside on IPv4 and IPv6. Remember container-published ports sit outside the host firewall.
- Effective SSH settings read from the daemon, not the file.
- Outside port test recorded.
3. Updates
Enable automatic security updates, run the dry run, and decide on reboots deliberately. Check: the dry run lists the security origin and finishes without error, the timers are enabled and the reboot setting matches your decision.
- Dry run output saved.
- Reboot choice written down.
4. A proper home for the app
Give each long-running process a restart policy and a health check, whether as a Compose project or a systemd unit. Check: after a hard kill the process returns, after a stop it stays stopped, and after a reboot it is running without a login.
- Kill, stop and reboot tests done.
- Startup order for databases handled with health checks.
5. Logs and secrets
Bound container, journal and application logs, and move secrets out of env files into protected files. Check: a synthetic log rotates, the next-day disk figure is inside budget, the app starts from the new secret locations and a search of the delivered files finds no value.
- Rotation tested with a synthetic log.
- Rotation checklist for real secrets in your hands.
6. Certificates and the monthly habit
Make sure certificate renewal passes a dry run, a schedule exists, the web server reloads and an outside alert works. Then decide who patches and reviews the server each month. Check: the served certificate is valid from outside and a monthly window is on the calendar. If several of these steps apply to your server, the baseline project does them in this order for a quoted price; any single step can be bought alone at its published test price, with payment after the agreed checks and your sign-off.
- Dry run, schedule and hook proven.
- A named person owns the monthly review.
Sources and limits
- OpenSSH sshd_config manual Checked 2026-10-11.
- First obtained value wins; Include and Match can override a setting.
- Docker: packet filtering and firewalls Checked 2026-10-11.
- Published container ports are handled before the INPUT rules ufw relies on.
- Certbot user guide Checked 2026-10-11.
- Renewal dry run, schedule and hook behaviour.