Self-hosting starts with recovery

I like the control that self-hosting offers: choosing how a service runs, where its data lives and when it changes. The harder question comes after installation. If the machine disappeared, what would it take to bring the service back?

That question helps me think about cloud hosting too. A managed service changes who handles parts of the system. It still leaves decisions about data loss, downtime and recovery.

Start with the state

An application image, its configuration, credentials and user data have different recovery needs. The image can often be rebuilt. A database or an uploaded file usually cannot be reconstructed from the application repository.

A short inventory makes those dependencies visible. For each service, it should identify the persistent data, required credentials and other services it depends on. That gives a recovery plan an order: what must return first, and what can wait?

Two limits make the plan concrete. The recovery point objective describes how much recent data loss is acceptable. The recovery time objective describes how quickly service must return. I find those limits more useful than a general promise that everything is backed up.

Finish the restore

A backup job reporting success is encouraging. The evidence I want is a usable application restored from that backup.

For a database-backed service, the exercise starts in an isolated environment with the matching application version. Checking records and trying essential workflows helps reveal missing data, configuration or credentials. Recording the time and any undocumented steps makes the next attempt easier to repeat.

The backup also needs protection from the failures affecting the original. A second copy on the same disk cannot survive that disk failing. Separate storage helps, but shared administrator credentials can still expose both copies to the same mistake.

Plan for shared resources

Containers make services easier to package. They still share the host’s finite memory, CPU and storage.

Resource limits help contain a busy service. Measurements of memory pressure, disk growth and request latency help explain what those limits mean in practice. A container that keeps restarting needs investigation even if the restart policy brings it back each time.

Monitoring has dependencies too. An alerting service on the failed machine may disappear along with the application. I want a way to notice the failure from outside that machine.

Include the maintenance

The monthly server bill covers only part of the cost:

Operating cost = compute + storage + network + backups + maintenance time

Managed cloud services can shift some maintenance to a provider. Self-hosting gives me more responsibility for updates, capacity and recovery. The useful comparison depends on the workload and the time available to operate it.

My preference is to begin with a few services and prove that they can be restored. That makes the next hosting decision easier: I can judge new complexity against a recovery process I understand.