Managed Hosting vs Self-Managed Servers

Two jobs wearing the same label

“Do you want us to run the servers?” sounds like a trivial question. It can mean any of four things: patching the operating system, watching the dashboards, keeping the backups restorable, or answering the phone when a customer cannot book a flight. Each costs a different amount and each is missed in a different way.

This matters because self-managed setups fail predictably. Not from exotic hardware failures, but from ordinary Tuesday omissions: a certificate that expired on a weekend, a disk that filled at 2am, a backup job that had been failing since a disk change and nobody read the log. The pattern is familiar enough that most infrastructure discussions should start there rather than with pricing.

What self-management genuinely involves

Owning your own servers means owning a role, even if you never hire anyone to fill it. That role covers far more than provisioning.

• Operating system and language runtime patching, on a schedule, across every host.
• Certificate renewal, including the remembering part, not just the issuing part.
• Capacity watching, so a full disk becomes an alert rather than an incident.
• Backup verification, which means restoring something and checking it, at a frequency you would defend.
• Firewall rules, DNS, TLS configuration, mail deliverability.
• Log retention, log shipping, and a plan for what happens when a log volume grows faster than disk.
• A replacement path for when a host provider, hypervisor or region becomes a problem.

Each item on that list is small. Together they are a permanent obligation, and the failure mode is not a single dramatic outage but slow decay: a patch skipped here, a backup unverified there, a log nobody reads. SmartEdge IT Solutions has taken over systems in this condition often enough to know what the handover looks like — usually a long list of undocumented manual steps that somebody was performing from memory.

There is one more category that gets missed: work that is rare but urgent. A failed disk array, an expired certificate on a load balancer, a region declared unhealthy by a provider you have no relationship with. When it happens, you need to have decided in advance who is allowed to take action on production at two in the morning, and under whose authority.

Change control is the other quiet item. Someone has to decide whether a deploy happens, who reviews it, and how a bad release gets rolled back — and in a self-managed setup that decision is usually implicit, made by whoever is most confident at the time. The organisations that self-manage well treat their infrastructure the way they would treat production software: version-controlled, reviewed, deployed through a repeatable process, with a staging copy to test against. The organisations that struggle treat it as a set of servers they log into. Same hardware, very different outcomes.

What a managed provider takes off the table

A good managed agreement removes the first two lists. In exchange for a recurring fee, patching, the certificate lifecycle, monitoring, backup execution and first-line incident response become somebody else’s rota.

The word to interrogate is response. Ask for the specifics:

• What is covered in the first-line response, and what is explicitly out of scope?
• Are you monitoring the customer’s applications, or only the infrastructure beneath them?
• Is there a defined path for second-line escalation, and who pays for it?
• Who holds production access, under whose credentials, and are those credentials rotated?

Those answers separate a real operations contract from a monitoring subscription. A monitoring tool tells you something is wrong. It does not tell you what to do about it, and on a small team the second half is where the evening goes.

There is also a version of this conversation about how much control you give away. Some clients are comfortable with a provider holding root-equivalent access; others are not, particularly where internal policy restricts it. Both positions are defensible. What is not defensible is agreeing to one and discovering the other later, which is why the access model belongs in the statement of work rather than in an email thread.

The cost comparison, done honestly

Self-managed infrastructure is not free, it is amortised. The visible line item is the instance or colocation fee, which is often small. The invisible ones are:

• Someone’s time. If a person with server experience already exists on the payroll, the marginal cost may genuinely be close to zero for a simple setup. If nobody does, the first incident will be expensive regardless of model.
• Tooling and licences for monitoring, backup and log aggregation.
• A testing environment. Without one, patching is an experiment performed on production.
• The occasional rebuild. Hardware ages, and migrations happen whether or not you planned them.

A managed provider replaces a variable, unpleasant cost with a predictable one. For a low-traffic site with a simple stack and an experienced owner, self-management can be the cheaper and more sensible answer. For anything with a database, a payment flow, real users and a person already stretched across other work, the comparison usually lands the other way — not because hosting is expensive, but because attention is the scarce resource.

It helps to think about the total rather than the invoice. A realistic self-managed figure has to include the fraction of one person’s month spent on infrastructure, the occasional half-day lost to an incident that would have been a five-minute fix with someone else holding the pager, and the cost of rebuilding an environment from scratch when the original operator has moved on. Those items are real and they are not speculative; they show up in most organisations’ experience, they just never appear on a hosting invoice.

The reverse framing is worth stating too. A managed arrangement is not free money, and there are two ways it goes wrong. The first is choosing a provider whose scope is written vaguely, so that the boundary between their responsibility and yours is discovered during the incident. The second is the scope creep that happens without anybody deciding it: each new request sounds reasonable, and a year later the arrangement covers considerably more than the original agreement and costs correspondingly more. Both are prevented the same way, by writing the scope down and reviewing it on a schedule.

SmartEdge IT Solutions publishes its monitoring and backup scope separately from administration for exactly this reason. Clients often want one and not the other, and a bundled product would hide the difference.

The argument for control, answered properly

It is a real argument and deserves an honest response rather than a dismissal. Running your own environment means no provider can migrate your platform, change a quota, or decide that your workload is no longer a good fit for a product tier. For a business whose entire product is its own software, that independence has genuine value. The reason it is affordable is that such a business usually has infrastructure people already.

The version of this argument that does not hold up is “we might move cloud providers one day”. Migrating a well-documented, conventionally configured application is a project with a cost and a duration. Migrating one held together by five undocumented custom scripts on a single host is a rebuild. Keep the scripts in version control and the portability argument becomes credible; leave them on a box and it does not.

Hybrid arrangements, and the trap in them

Most mature environments end up mixed. Infrastructure managed, database self-hosted. Platform managed, application code maintained in-house. This works until the boundary is drawn in the wrong place, which specifically means drawing it inside a single failure domain.

The clearest example is a managed platform with a self-managed database underneath it. You now have two escalation paths, two sets of on-call expectations and two parties who each believe the problem belongs to the other. The database will be the slow part of every incident, and it will be the part with the least documentation. If you go hybrid, draw the line so that one incident has one owner, and make sure that owner appears in the contract.

Our cloud infrastructure management page describes how we tend to draw that line, and VPS management covers the single-host case, where the arithmetic is different again because there is no elasticity to manage.

Hybrid is not the same as partial

One more distinction, because the words get used interchangeably. A managed service is a defined service with a contract, a response time and someone accountable. A partial arrangement is a provider doing some tasks opportunistically, often without documentation of which tasks. The second feels cheaper and produces far more incidents, because when the incident arrives nobody can establish whether the provider was responsible for the thing that broke.

Partial is also much harder to hand over. If two organisations are both partly responsible, a future handover conversation becomes an archaeological exercise. At SmartEdge IT Solutions we would rather scope the responsibility fully and let you remove pieces of it than begin with an ambiguous split.

How to decide this week

Four questions, in order, will usually settle it:

1. Does anyone on the team already have the skills to handle a full outage at an inconvenient hour? If not, self-management is a plan to learn during an incident.
2. How many moving parts does the stack have? Under three, self-managed is viable. Above that, the surface area grows faster than your confidence.
3. What would an unplanned week of server work cost you, in salaries you did not get to spend on the roadmap?
4. How much data is worth losing, and how many hours of work would a restore actually cost?

Then write the answer down, including what is out of scope. The fourth question tends to be the one that changes minds, because it turns a technical preference into a business one.

Whatever the answer, the same closing discipline applies to both models. Someone named owns the environment. A decision has been recorded about which parts are monitored, which are backed up, and how quickly either would be noticed if they stopped working. And a plan exists for the day the person responsible leaves, because in a small organisation that day tends to arrive without a warning and without a handover.