Our hosting company already manages the server. Is this the same thing?

No. A hosting provider keeps the machine powered, networked and reachable, and their responsibility usually stops at the operating system. Nobody there is watching your disk fill with log files, your certificate approach its expiry, your application process die at four in the morning, or your backup job quietly stop running. Those are the things that actually take sites offline, and they sit in the gap between the provider and your developer.

What does the monthly fee include, and what is extra?

The retainer covers keeping the system alive and safe — patching, certificates, firewall and access management, monitoring and alert response, backup verification, and a monthly report. New features, redesigns and significant architectural changes are separate work, quoted separately. We write that boundary down at the start, because a retainer that quietly absorbs development work stops being a retainer and starts being a source of resentment on both sides.

Do you need root access, and what if we would rather not hand it over?

Yes, for anything meaningful. Patching, firewall rules, service management and certificate renewal all require administrative access. What we can do is make that access auditable — individual keys rather than a shared password, no direct root login, and a record of what was changed and when. If access genuinely cannot be granted, we can advise and write instructions, but we would not take on availability commitments for a system we cannot touch.

What is the response time if something breaks at 2am?

That depends on which arrangement you choose, and it is the single biggest factor in where you sit in the price range. Business-hours cover is one person's calendar. Genuine overnight and weekend cover is a rota, and it is priced as one. We would rather agree a realistic window you can rely on than a heroic one that gets missed once and destroys the relationship.

Can you work on our existing provider, or do we have to move?

We work with what you have in almost every case. Migration is a separate decision with its own reasons — cost, region, or a platform that no longer fits — and it is not a precondition. If your current setup has a genuine ceiling we will show you the measurement behind that view rather than simply recommending a move.

What happens if we stop the retainer?

You keep everything, and it is documented well enough to be useful to whoever comes next. Credentials return to you, the runbook and monitoring configuration are yours, and any infrastructure we described in code goes with them. The failure we most often clean up is a business locked out of its own server because one person held the only key, and we are not willing to become that person.

Cloud, DevOps & Infrastructure

Managed hosting and server administration

Patching, certificates, firewalls, monitoring and verified backups on a monthly arrangement — so the boring failures that take sites down get caught before your customers find them.

From: $100–$1,500/mo
Typical time: ongoing
Usually bought by: SMEs

What this actually solves

The outage that costs a business the most money is almost never interesting. It is a disk that filled with two years of log files that nobody ever rotated, so the database could no longer write and the application stopped. It is a certificate that expired on a Saturday, so every visitor got a full-page security warning. It is a process that died and had nothing configured to restart it. Each of those is a fix measured in minutes, and each can cost days because nobody was watching and nobody knew where to look.

Underneath that sits a second problem, which is quieter and worse. The person who built the system is often not the person who is still around. There is a business somewhere that cannot log into its own server because the developer moved on and the credentials went with them — and it does not find out until the morning nothing loads. Ownership of the machine, the domain registrar, the DNS and the cloud account is a genuine operational risk, and it is usually invisible right up until it is the entire problem.

This service exists to make the boring failures somebody's actual job. The honest framing is that you are not buying visible output. In a good month nothing happens: no call, no downtime, and a bill the same size as last month's. The best evidence this work is succeeding is an absence of events, which is exactly why it needs a written report each month — so what is being paid for is legible rather than assumed.

How the work runs

Take ownership properly. Every credential inventoried and moved into a vault you also control — cloud account, server root, registrar, DNS, certificates, and any third-party service the application depends on. We also establish who else holds keys, and remove the ones that belong to people who left. Three to five days.
Fix what is already broken and close the obvious doors. A firewall that exposes only what needs exposing, because a database port open to the internet is the single most common serious finding. Key-based SSH instead of passwords. Log rotation configured. Automatic certificate renewal verified end to end rather than assumed. Unattended security updates enabled for the low-risk packages. Three to seven days.
Monitor the things that actually cause outages. Disk usage with a threshold that leaves time to act, memory and process restarts, certificate expiry counted in days remaining, an external check that loads a real page from outside your network, and backup freshness. Alerts are tuned deliberately, because a pager that fires on everything is one nobody answers by the third day. Two to four days.
Write the runbook and agree the response terms. A short document, one section per likely symptom, with the exact commands written out — what to check when the site returns a gateway error, when it is intermittently slow, when mail stops, when the certificate warning appears. Alongside it, in writing, what you can expect from us and when. Two to three days.
Then run the monthly rhythm. A patch window on an agreed date for the changes that need a person present, a periodic restore drill so backups are proven rather than trusted, a review of capacity and spend, and a short report covering what happened, what was patched, and what we are watching. Ongoing.

What moves the price

The range is $100–$1,500/mo, ongoing, and three things set where you sit inside it.

How many machines there are and how much of it holds state. One VPS running an application and its database is at the bottom of the range. An estate with separate application servers, a managed database, background workers, a queue and a caching layer is more surface, more monitoring and more that can go wrong independently.

What response cover you need. This is the largest single factor. Business-hours cover is one arrangement; being answerable at three in the morning on a bank holiday is a completely different one, because it requires a rota rather than a person, and it is priced accordingly. Deciding this honestly is more useful than buying the strongest option by reflex.

The condition of the system on day one. A server that has not been patched in two years, has no rotation on its logs, and was configured by hand with no record of what was done, is a remediation project before it is a retainer. We will separate those two things in the quote so that the ongoing fee reflects steady-state work rather than carrying the cost of the initial clean-up forever.

What usually goes wrong

Patches install themselves and nothing ever restarts, so the server is not actually patched. Unattended upgrades produce a reassuring record — packages fetched, packages installed, no errors — and that record is not evidence. A kernel or a shared library replaced on disk is still the old version in memory until the process, or the machine, restarts. A server with a long uninterrupted uptime and a clean update history can be running the exact code the update was published to remove, and publication is precisely what tells an attacker where to look. The patch window exists for this: the restart is the part of patching that needs an agreed date and somebody present, not the download.

The certificate renews and the expired one carries on being served. Automatic renewal is the step everyone sets up and almost nobody finishes. The renewal runs on schedule, writes a valid new certificate to disk and exits successfully — but the web server read its certificate into memory when it last started, and it keeps handing the old one to every visitor until something reloads it. So the renewal log says success on the same morning every browser says the certificate is invalid. The only check worth having is made from outside the machine: what certificate is a fresh connection actually being given today.

Logs grow until the disk is full and everything stops. It is the most preventable outage there is and one of the most common. Applications write logs, nothing deletes them, the volume reaches capacity, and the database can no longer write — which surfaces as a total failure rather than as anything resembling a storage problem. Rotation with a retention limit, plus an alert at a threshold that leaves room to react, removes the whole category.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Our hosting company already manages the server. Is this the same thing?: No. A hosting provider keeps the machine powered, networked and reachable, and their responsibility usually stops at the operating system. Nobody there is watching your disk fill with log files, your certificate approach its expiry, your application process die at four in the morning, or your backup job quietly stop running. Those are the things that actually take sites offline, and they sit in the gap between the provider and your developer.
What does the monthly fee include, and what is extra?: The retainer covers keeping the system alive and safe — patching, certificates, firewall and access management, monitoring and alert response, backup verification, and a monthly report. New features, redesigns and significant architectural changes are separate work, quoted separately. We write that boundary down at the start, because a retainer that quietly absorbs development work stops being a retainer and starts being a source of resentment on both sides.
Do you need root access, and what if we would rather not hand it over?: Yes, for anything meaningful. Patching, firewall rules, service management and certificate renewal all require administrative access. What we can do is make that access auditable — individual keys rather than a shared password, no direct root login, and a record of what was changed and when. If access genuinely cannot be granted, we can advise and write instructions, but we would not take on availability commitments for a system we cannot touch.
What is the response time if something breaks at 2am?: That depends on which arrangement you choose, and it is the single biggest factor in where you sit in the price range. Business-hours cover is one person's calendar. Genuine overnight and weekend cover is a rota, and it is priced as one. We would rather agree a realistic window you can rely on than a heroic one that gets missed once and destroys the relationship.
Can you work on our existing provider, or do we have to move?: We work with what you have in almost every case. Migration is a separate decision with its own reasons — cost, region, or a platform that no longer fits — and it is not a precondition. If your current setup has a genuine ceiling we will show you the measurement behind that view rather than simply recommending a move.
What happens if we stop the retainer?: You keep everything, and it is documented well enough to be useful to whoever comes next. Credentials return to you, the runbook and monitoring configuration are yours, and any infrastructure we described in code goes with them. The failure we most often clean up is a business locked out of its own server because one person held the only key, and we are not willing to become that person.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Managed hosting & server admin All Cloud, DevOps & Infrastructure services