Running a Small Independent Hosting Provider
A small hosting company is not a tiny version of AWS, and it shouldn't try to be. What it has going for it is judgment, continuity, real technical depth, and knowing customers as actual people. What works against it: not many hands, too much knowledge in too few heads, thin margins, and the temptation to say yes to everything. This is how I think about running one, beyond just the servers.
Know exactly what you sell
"Web hosting" sounds like one thing, but what you're on the hook for varies a lot. A shared hosting account, a managed VPS, an unmanaged dedicated server, and a colo cabinet each need different tools, different staffing, different contracts, and different support boundaries.
For every product, I like to have answers to these:
| Question | Why it matters |
|---|---|
| What's included? | Sets what customers can normally expect. |
| What's not included? | Keeps an unmanaged product from slowly turning into a managed one. |
| What's the recovery promise? | Ties the product to backups, spare hardware, and who's on call. |
| What's monitored? | Decides whether you find out about a failure first, or the customer does. |
| What can be automated? | Keeps labor costs sane and provisioning consistent. |
Figure out how it runs before you build the catalog
It's tempting to list everything you're technically able to sell. I think it's healthier to start with what you can run consistently, every time, even on a bad week.
Provisioning
How does a paid order turn into a working service? Fraud check, IP assignment, DNS, credentials, welcome email, monitoring, documentation.
Lifecycle
Upgrades, downgrades, suspensions, cancellations, how long you keep data, getting hardware back.
Failure
What happens when a disk, node, switch, circuit, or the whole facility goes away?
How the pieces connect
Customer request
|
v
Billing / fraud review
|
v
Provisioning system -----> Inventory / IPAM
| |
v v
Compute / hosting --------> Monitoring
| |
v v
Backups ------------------> Alerts / ticketing
|
v
Recovery runbook
Every arrow is something that can quietly not happen. If billing spins up a VPS but nothing adds it to monitoring, it's only half provisioned. If an account gets cancelled and nobody knows how long its backups stick around, the lifecycle isn't finished.
Standardize everything you can
This isn't about taking away every choice. It's about cutting down the number of special cases you have to remember in the middle of an incident.
- Offer a short list of supported OS templates.
- Be consistent with hostnames, interface names, VLAN purposes, and storage names.
- Keep firmware, hypervisor, and management controller versions in known groups.
- Use the same monitoring and backup policies everywhere instead of hand-built exceptions.
- When you do make an exception, write down who owns it, why it exists, and when to look at it again.
Config drift is a tax
Two servers that look the same but have different firewall rules, repos, PHP packages, or backup destinations are hidden work. It doesn't matter today. It matters the day you try to fix both with the same runbook.
You don't need a big config-management platform to keep this under control. Even a small provider can keep:
- A known-good server build checklist
- Config snippets in Git
- A standard list of packages and repos
- A post-install script that checks the build
- A regular look for drift
Support is part of the infrastructure
A service can be technically solid and still feel unreliable if communication is bad. Customers judge how you handled it as much as what broke.
Figure out what "down" means
"Email is down" could mean one mailbox can't log in, outgoing mail is stuck, a DNS record is wrong, or the whole mail server is dead. I try to get answers to these first:
- Who's affected?
- Which service or protocol is failing?
- When did it last work?
- What changed?
- Does it happen from another network too?
Communicate in stages
First notice
What's affected, what you don't know yet, and when the next update is coming. Then actually post that update on time.
Updates
Say where you are (investigating, containing, restoring, verifying) without guessing at an ETA you can't back up.
Afterward
What was affected, why, how it was fixed, and what you're changing, in plain language.
Change management, small-team style
You don't need a change advisory board. You need discipline. A short change record fits in a ticket and still covers what matters:
| Field | Example |
|---|---|
| Why | Move customer backup traffic to its own storage VLAN. |
| Scope | Three hypervisor nodes and one backup server. |
| Before starting | Out-of-band access confirmed; switch configs saved. |
| Steps | Create the VLAN, add tagged interfaces, test the path, move one node at a time. |
| How I'll know it worked | Backup job runs, a restore test works, monitoring is happy, no packet loss. |
| Rollback | Put interfaces back on the old VLAN and restore the switch config. |
Be extra careful with changes to routing, remote access, storage, authentication, or backups. Those are exactly the changes that can take away the tools you'd need to undo them.
What if you're not around?
Having redundant infrastructure isn't enough if the company depends on one person. Plan for that person being sick, on vacation, or just asleep.
- Emergency credentials are stored securely, and someone else can get to them.
- Facility contacts, circuit IDs, vendor contracts, and support PINs are written down.
- Another trusted person can find the critical systems and see what's currently broken.
- Billing, domain, certificate, and license renewals don't all go to one inbox.
- You can still reach customers if your main site is down.
- Backups and encryption keys can be restored without the original operator's laptop.
A rhythm that works
| How often | What I look at |
|---|---|
| Daily | Alerts, failed backups, the abuse queue, anything odd with capacity, and tickets that affect customers. |
| Weekly | Patch status, failed jobs, certificates about to expire, disk growth, hardware warnings, open changes. |
| Monthly | Restore tests, capacity forecasts, who has admin access, and whether contacts and runbooks are still right. |
| Quarterly | A bigger recovery test, whether each product is actually making money, why the same tickets keep coming in, and cleaning up old exceptions. |
Why small providers matter
The goal isn't to copy the giants. It's to offer clear ownership, careful operation, and the kind of continuity people rarely get from a faceless platform. That's the whole reason to exist.