Independent technical referenceSystem / content / protocol / route

Operations / hosting

Self-hosting a .NET blog

Entry abstractSelf-hosting is ownership of a system boundary, not simply possession of a server.

A self-hosted blog is an application plus the services that make it reachable and recoverable. The process model, front-end server, TLS termination, persistent storage, backups, logs and upgrade plan form one system. A fast application without a tested restore is not an operable publication.

Map the request path

Modern ASP.NET Core applications commonly run on Kestrel and may sit behind IIS, Nginx, Apache or another reverse proxy. The ASP.NET documentation organizes guidance for servers, hosting, deployment, security, HTTPS, containers and proxy scenarios. The architecture should make each responsibility explicit.

reader → DNS → TLS/proxy → application → content + media

The proxy may normalize the host, enforce HTTPS, limit request size and serve static assets. The application renders entries, feeds and administrative routes. Storage holds content and media. When these responsibilities overlap without a plan, redirects loop, client addresses are misread or private administration paths become public.

Persistent data must be named

List every stateful location: entry files or database, media, keys, configuration, comment data, search indexes and queued jobs. Then classify each as authoritative, derived or secret. Derived indexes can be rebuilt. Authoritative content must be backed up. Secrets require a separate recovery process and should not be copied into a public content export.

Backups need a restore exercise

A backup is evidence only after a restore has succeeded in an isolated environment. File-oriented systems need a consistent copy so that an entry and its referenced media agree. Database systems need a database-aware backup and a matching media set. Record recovery order, expected checks and the point in time the restore represents.

Containers move the boundary

A container can package the application runtime and make deployments repeatable, but persistent content should not be confused with the container filesystem. Mounts, volumes or external services need their own backup and permission plan. Replacing an application image should not erase posts; restoring content should not require reconstructing an old build environment.

Observe the publication

Useful signals include request failures, response time, storage capacity, feed generation errors, background-job failures and certificate expiry. Logs should identify a failing route without recording sensitive request bodies or credentials. A health check should test the dependencies that determine whether public pages can be served, while deeper diagnostics remain private.

Upgrade in reversible steps

Separate content backup from application deployment. Read release notes from the actual project source, test the new version against a restored copy, and record any data transformation. Keep a rollback path until public pages, feeds, editor workflows and old URLs have been checked. This reference does not provide installation or release instructions for any named engine.

Design for the unattended hours

A personal publication may have no operator watching dashboards overnight. Prefer bounded queues, automatic process restarts, expiring log retention and alerts tied to reader-visible failures. Document which alerts require immediate action and which can wait. Simplicity here is not a lack of features; it is an operating model matched to the people who actually maintain the site.

Schedule a periodic recovery review after framework, storage, proxy or DNS changes; each can invalidate an assumption in an older runbook.

The operating contract

Write down the canonical host, redirect behavior, storage locations, backup schedule, restore procedure and ownership of certificates and DNS. Those notes turn an individual server into an understandable service. When the time comes to change platforms, the migration guide begins from that inventory.