Hosting Guide

What Self-Managed Hosting Actually Means

Self-managed hosting means owning the operations layer — not just the server. Understanding what that ownership includes in practice prevents the most common failure mode: provisioning a server and then not managing it.

Overview

When someone provisions a cloud VPS for the first time, they typically think about the setup: install a web server, configure PHP, deploy the application. The mental model ends at launch. Self-managed hosting doesn't end at launch — it continues every week, every month, indefinitely, until the server is decommissioned.

How to think about it

Self-managed hosting means owning the complete operational lifecycle of a server. At launch: OS installation, security hardening, web server configuration, PHP or runtime setup, database installation, firewall rules, SSL certificate installation, and backup configuration. After launch: OS and software security patches (typically monthly or faster for critical vulnerabilities), certificate renewal, monitoring and alerting, backup verification, log rotation, and storage management.

Incident response is also user-owned. When the server goes down at 2am, there is no support team to call that can fix it at the infrastructure layer. The user is the infrastructure team. The response timeline is the user's response timeline.

The ongoing maintenance burden is the component most often underestimated. A server that is set up correctly and then not maintained for 6 months has accumulated months of unpatched vulnerabilities. The risk compounds silently until it materializes as an incident.

How it works

Security patching: the OS and all installed software packages need regular updates. Critical security patches should be applied within days of release. Routine updates should be batched and applied at least monthly. For a production server, this means a scheduled maintenance window every 4-6 weeks minimum.

Monitoring: knowing when the server is down or degraded requires monitoring. At minimum: uptime monitoring (external ping test that alerts when the server stops responding) and disk space monitoring (full disks stop servers silently). More comprehensive monitoring includes CPU, memory, database performance, and application error rates.

Backup verification: having backups is not the same as having working backups. Backups need to be tested — a restore exercise that confirms the backup is complete and the restore procedure works. This should be done at least quarterly. Discovering a backup is incomplete during a recovery situation is one of the most costly infrastructure failures.

Where it breaks

Launch and neglect: the server is configured correctly at launch and then receives no ongoing attention. Six months later, it's running an OS version with a known critical vulnerability. A year later, it's compromised. This is the most common self-managed hosting failure mode.

Invisible disk fill: a server running out of disk space silently fails. Web servers stop serving requests. Databases stop accepting writes. Applications generate errors with no obvious cause. Without disk space monitoring, this is only discovered when something breaks.

Backup blindness: the backup job runs without error but produces incomplete or corrupted backups. The user believes they have recovery capability. An incident requires restore. The backup doesn't work. This is the failure that the quarterly restore exercise prevents.

In context

Managed shared hosting handles all server operations. The user doesn't think about OS patches, monitoring infrastructure, or backup verification — these are platform responsibilities.

Managed cloud (Cloudways-style) handles server operations but leaves application operations to the user. OS patches, server software updates, and infrastructure monitoring are platform responsibilities. WordPress updates, plugin management, and application-level backups remain with the user.

Self-managed VPS owns everything. The platform provides compute; the user owns the full operational stack. The capability ceiling is the highest. The operational floor — the minimum ongoing work required to keep the server secure and functional — is also the highest.