Managed hosting and website maintenance

A hosting decision should start from the thing being hosted: how much traffic, what kind of data, which integrations, how much downtime the business can genuinely absorb, and what the budget is. A five-page company site and an application your staff use all day do not need the same architecture, and pretending otherwise is how a small business ends up paying for a Kubernetes cluster to serve a contact form.

So we pick the simplest platform that meets the real requirements, and add services only where one of them removes a specific risk. Where data has to stay in Europe, that narrows the list, and we say so up front rather than after the migration. Where several environments are needed, production is kept separate from the place where things get tried out.

The domain and the main accounts are registered in your name wherever the provider allows it. That single detail is the difference between changing supplier and negotiating with one.

A deployment that depends on somebody remembering the right order is a deployment that will eventually go wrong on a Friday. Code and configuration move through the same defined process every time, secrets live outside the repository, and the differences between environments are written down where someone can find them.

Database migrations, cache changes and anything else that leaves a trace get more care than application code, because rolling the code back does not undo them. How much ceremony a release needs follows how much it would cost to get wrong: a content update can simply go out, while an application people depend on all day may want a window, a staged rollout and a rehearsed way back. The goal is that ordinary changes stop being events.

An uptime check that pings the homepage tells you the homepage is up. It does not tell you the contact form has been failing silently for a week, that the nightly job stopped running in March, that a certificate expires on Sunday, or that the disk will be full by Thursday. What is worth watching depends on the system, and working that out is part of the job.

Alerts go to somebody who can do something about them, with enough context to tell a real incident from noise. That matters more than it sounds: a channel full of alerts nobody acts on trains everyone to ignore the one that counts. Logs are kept long enough to be useful and short enough to be responsible, with sensitive fields left out wherever they can be.

Most of the sites that get compromised were never targeted. They were running a plugin with a known vulnerability that was patched eleven months earlier. Updates to the application, the runtime and everything underneath happen on a rhythm, tested in proportion to their risk. Nothing gets applied blindly, and nothing waits for an incident to force the issue.

Access follows the same logic. Accounts are limited to what the person needs, protected with strong authentication where the provider supports it, and removed when somebody leaves. Certificates, security headers and the other unglamorous controls are simply maintained. None of it is clever. That is the job.

A backup nobody has restored is a belief, not a plan. We define what is backed up, how often, how long copies are kept and where they live, including somewhere a mistake on the main platform cannot reach. Then restores get tested, at an interval that matches what the data is worth.

Two numbers drive the design, and they are worth agreeing out loud: how much data you could afford to lose, and how long you could be down. Most businesses have never been asked, and the answers surprise people. Once they exist, they decide the backup frequency, the architecture and the recovery procedure, instead of everyone hoping the question never comes up.

When something breaks, what helps is one person who can look at the application, the deployment and the infrastructure in the same afternoon, instead of a client relaying messages between a host, a developer and an agency who each suspect the other two. The first job is getting the service back safely. The cause comes after, along with whatever stops it happening again.

You get told what happened in plain language, including when the diagnosis takes longer than the fix did. Providers, architecture, access and the recovery procedure are documented, and that documentation is yours. If another team takes over one day, they can: anything provider-specific is named rather than discovered. Hosting should be something you keep because it is useful, not because leaving is difficult.

Managed hosting is not an unlimited development retainer. Keeping the platform healthy, applying updates, watching the monitors and responding when something breaks is the service. New features, redesigns and integrations are project work, quoted separately. We would rather draw that line clearly at the start than have it come up during a conversation about an invoice.

It is also not a promise that nothing will ever go down. Providers have outages, certificate authorities have bad days, and a dependency you did not choose can ship a bad release. What can be promised is that somebody is watching, that the recovery path has been tested, and that you will hear about it from us before you hear about it from a customer.