Plenty of sites serve a few thousand people a day and will never serve more. They do not need autoscaling groups. They do need to stay up, stay patched and be restorable, which is a smaller list than it sounds and a longer one than most get right.
The minimum viable setup
- One adequately sized instance, built from a script rather than by hand.
- A reverse proxy terminating TLS, with certificates renewed automatically.
- The application running under a process manager that restarts it on failure.
- A firewall allowing only the ports you serve.
- Automated off-instance backups, with a restore tested at least once.
- Uptime monitoring from outside the server.
- Unattended security updates, with a scheduled reboot window.
That is an afternoon of work and covers the overwhelming majority of what goes wrong with small sites.
Static content should not touch the server
Images, stylesheets and scripts served from object storage behind a CDN reduce load, improve distant performance and survive an origin outage. For largely static sites, this alone changes the reliability picture.
Where small sites actually fail
| Failure | Prevention |
|---|---|
| Disk full from logs | Log rotation and a disk space alert. |
| Certificate expired | Automated renewal plus an independent expiry alert. |
| Domain expired | Auto-renew enabled and the registrar contact current. |
| Database corrupted | Tested restores, not just scheduled backups. |
| Compromised outdated software | Unattended updates and a patch schedule. |
| Nobody noticed it was down | External uptime monitoring with real alerting. |
Knowing when to grow
Add complexity when something specific forces it: sustained saturation, an availability requirement a single host cannot meet, or a team large enough that manual operations become a bottleneck. Traffic alone is rarely the trigger.
Summary
One scripted host, automated TLS, a closed firewall, tested backups, external monitoring and automatic patching. Small sites fail from neglect far more often than from load.
