From the other side of the control panel
Hosting and Infrastructure
I got into web hosting before I had any business being responsible for a server. That curiosity eventually became years of running real infrastructure, and this section is where I write down the parts that vendor documentation usually leaves out.
A customer sees a website, a mailbox, a control panel, or a virtual machine. I tend to see the stack behind it: power, switches, routing, storage, hypervisors, operating systems, backups, monitoring, abuse reports, licensing, spare capacity, support expectations, and the unfortunate possibility that several of those things will become your problem at the same time.
If you are new here
You do not have to read this section front to back. If you are curious about the business and operational side, start with running a small hosting provider. If you are trying to understand what changes between shared hosting, VPS, dedicated servers, and colocation, read hosting service models. The platform and reliability articles make more sense after that.
Running the thing
The parts of hosting that show up after the install guide ends.
- Running a Small Independent Hosting Provider How I think about the whole operation, not just the servers.
- Hosting Service Models What you actually take responsibility for as you move up the stack.
- Capacity Planning and Growth Why “we still have some free space” is not a capacity plan.
- Lessons from Long-Term Hosting Operations Things I believe much more strongly now than when I started.
The systems underneath it
Platforms I have had to understand well enough to trust in production.
- cPanel and WHM More than clicking through WHM and hoping the defaults are sensible.
- Proxmox VE and Backup Server Virtualization, storage, backups, and the decisions around them.
- Reverse Proxies and TLS Where traffic really terminates and which system should be trusted.
- Data-Center and Remote Management The physical layer becomes very real when the server is not near you.
When normal stops being normal
Recovery, monitoring, migrations, and the work you hope feels boring when it matters.
- Backup and Disaster Recovery A backup is only comforting after you have proved you can restore it.
- Server Migrations Moving production without turning the cutover into an adventure.
- Monitoring with LibreNMS Graphs are nice. Useful signals at 2:00 a.m. are nicer.
- Abuse and Incident Response The technical and human work when something has already gone wrong.
- Operator Checklists The boring little lists that keep unusual days from getting worse.
A few opinions I earned the expensive way
Recoverable beats impressive. I would rather operate a simpler system I know how to rebuild than a clever cluster nobody wants to touch during an outage.
Small providers have to understand boundaries, but not hide behind them. A customer problem can start in an application and end at a switch port. “That is another team” is not much help when the other team is also you.
Documentation is part of the system. If recovery depends on one person remembering a strange command, an undocumented password location, or why a setting was changed three years ago, the design is unfinished.
The articles here are not meant to replace vendor documentation. They are the notes I would want sitting next to it: what I check first, where I have seen things fail, and why a seemingly small operational detail can matter later.