Where an application runs is usually decided once, early, and then lived with for years. The decision is often made on price per month alone, which is the least informative number on offer, because the real cost of hosting is the price plus the work it creates plus what it costs when it fails.
This article goes through the common options, what each makes you responsible for, how to release changes without taking the site down, and the few things you should own whichever option you choose.
Who is responsible for what
The useful question is not "how much per month" but "who does what":
- Security updates for the operating system and the database
- Backups, and testing that they restore
- Monitoring: knowing the site is down before a customer tells you
- TLS certificates, and their renewal
- Scaling when traffic grows
- What happens at three in the morning when something fails
On your own server, all of these are yours or your developer’s. On a managed platform, several of them are the provider’s. The monthly price should be compared together with that list, not without it.
Containers and portability
Packaging the application as a container image, with Docker for example, has become the ordinary way to make it portable. The image contains the application and everything it needs, built once and run the same way everywhere: on a developer’s laptop, on a test server and in production.
That has a practical benefit for the owner of the system: moving it to another server or another provider becomes a matter of running the same image somewhere else, rather than rebuilding an installation by hand.
Releasing without downtime
A release should not be an event that takes the site down. The pattern that avoids it:
- Build the new version once, as an image or a package, and test that exact build.
- Start the new version alongside the old one.
- Check it is healthy: it starts, it can reach the database, a health endpoint answers.
- Switch traffic to the new version.
- Keep the old version ready for a quick switch back, for a while.
The same idea appears under different names, rolling, blue-green, but the principle is the same: never replace the running version until its replacement has proven it works.
Changing the database safely
The database is the part that makes zero-downtime releases hard, because the old and the new version of the application share it during the switch. A change to the database has to work with both.
The safe way is to split a breaking change into steps. To rename a column, for example:
release 1 add the new column, write to both, read the old one
copy existing values into the new column
release 2 read the new column
release 3 stop writing the old column
release 4 remove the old columnIt is slower than a single rename, and it means no release ever needs the site to be down, and any single release can be rolled back.
Backups
A common rule of thumb: three copies of the data, on two different kinds of storage, one of them somewhere else. In practice for a business application:
- automatic database backups at least daily, kept for weeks
- uploaded files backed up too, which is often forgotten
- at least one copy with a different provider or in a different place from the server
- a restore tested regularly, with the time it takes written down
The backup that matters is the one that restores. What I check before taking over an existing application describes a restore drill step by step.
Monitoring
You should know the site is down before your customers tell you. The minimum:
- an uptime check from outside, every minute or so, that alerts someone
- error tracking in the application, so failures are seen with their details
- alerts on disk space, memory and certificate expiry, the three things that quietly run out
A realistic setup
For a typical business application, a sensible setup that one person can look after looks roughly like this:
internet
→ DNS and a CDN in front (static files cached close to visitors)
→ one server, or two for redundancy
reverse proxy (TLS)
the application, in containers
the database, or a managed database next to it
→ object storage for uploaded files
→ backups: database dumps and files, copied to another provider
→ monitoring: uptime checks, error tracking, disk and certificate alertsIt is not glamorous, and it handles a great deal of traffic. Most business systems never outgrow it; the ones that do usually know well in advance.
Environments and configuration
An application usually runs in at least three places: on the developer’s machine, on a test or staging server, and in production. The code should be the same in all three. What differs is configuration: database addresses, keys, e-mail settings, feature switches.
Keep that configuration outside the code, in environment variables or a secrets store per environment, and make sure test environments cannot accidentally send e-mails to real customers or charge real cards. A staging server that uses the production payment keys is an accident waiting to happen.
A deployment pipeline
A deployment pipeline turns "someone runs the right commands" into something that happens the same way every time:
on every change to the main branch:
1. run the tests
2. build the image, tag it with the commit
3. deploy that image to staging
4. run a quick check against staging
on a release:
5. deploy the same image to production
6. check health, switch traffic
7. keep the previous image ready for rollbackThe important word is "same". The image that was tested on staging is the image that goes to production, byte for byte, not a fresh build that might differ.
Rolling back
Every release plan needs a way back, and it should be tried before it is needed. With container images, rolling back the application is usually a matter of deploying the previous image. The database is harder: if the release changed the database in a way the old version cannot read, the old version cannot simply be restored. That is why database changes are split into compatible steps, as above, so that the previous release still works with the database as it is now.
Scaling, when it is actually needed
Most applications can grow a long way on one well-sized server, and a bigger server is the simplest scaling there is. Before adding servers, check where the time actually goes. Very often it is a few slow database queries, missing caching, or large images, all of which are cheaper to fix than to scale around.
When more than one server is genuinely needed, the application has to be ready for it: no files stored on the local disk, sessions that work across servers, and scheduled jobs that run once rather than once per server.
If the server disappears
A disaster recovery plan answers one question: if the server disappeared today, how would the business be running again, and by when? Write down the steps: where the backups are, how to create a new server, how to deploy the application, how to restore the data and point the domain at the new place. Then try it once, on a quiet day. The first attempt always finds a step that was missing from the document.
How hard would it be to leave?
Some dependence on a provider is unavoidable and fine. The question is how hard it would be to leave. A quick check:
- Can the data be exported in a standard format, today, without the provider’s help?
- Does the application run in containers, or is it tied to one provider’s special services?
- Are the domain, the backups and the code in your accounts?
If the answers are yes, you can move when you need to. If not, that is worth knowing before the day you want to.
What hosting really costs
Comparing hosting on the monthly price alone hides most of the cost. A fairer comparison adds up, for each option:
- the monthly price of the servers, database and storage
- the price of backups, bandwidth and anything billed by use
- the hours per month someone spends on updates, monitoring and small problems, at what those hours cost
- the likely cost of an outage: how often, for how long, and what an hour of downtime costs the business
On that basis, a cheaper server can be the more expensive option if nobody is looking after it, and an expensive managed platform can be cheap if it replaces hours of work. There is no general answer, but there is always an answer for a specific business once the list is written down.
Keeping the server up to date
On your own server, keeping the operating system and the database up to date is a standing job, not a one-off. A sensible rhythm:
- security updates for the operating system applied automatically, or at least weekly
- the database kept on a version its makers still support, with major upgrades planned and tested on a copy first
- the application’s own dependencies checked for known vulnerabilities on every build
- a reboot schedule, because some updates only take effect after one
None of this is difficult, and all of it is easy to forget for a year. The servers that get compromised are rarely the ones with unusual software; they are the ones nobody updated.
Logs you can find
When something goes wrong, the first question is always "what happened?", and the answer is in the logs, if they were kept. The application, the web server and the database all write logs. Keep them in one place, searchable, for long enough to look back at an incident, and make sure they rotate so they never fill the disk, which is itself one of the most common causes of an outage.
[ ] Domain, DNS, hosting account and repository in the business’s name
[ ] Configuration and secrets outside the code, per environment
[ ] One image built, tested and deployed to every environment
[ ] Health check before traffic switches to a new release
[ ] Previous release ready for rollback
[ ] Database changes split into compatible steps
[ ] Daily backups, files included, one copy elsewhere
[ ] Restore tested, time written down
[ ] Uptime checks, error tracking, disk and certificate alerts
[ ] Security updates on a schedule
[ ] A written plan for a lost server, tried onceWherever the application runs, these should be in your name and under your control:
- the domain, and access to its DNS
- the hosting or cloud account, with your developer invited rather than owning it
- the code repository
- the backups, or at least one copy of them
- the list of every other service the system uses, with the accounts
With those, you can change your hosting, your developer or both. Without them, you depend on someone else’s goodwill to do either.
Not sure where your application should run?
Tell me what it does and how many people use it.