The Case for Owning Your Publishing Stack

Every managed publishing platform makes the same implicit offer: we will handle the infrastructure if you accept our constraints. The constraints are rarely listed in the marketing copy. They accumulate over time — in pricing changes, in deprecated features, in API modifications that break integrations, in terms of service updates that redefine what you are permitted to publish.

Owning your stack does not mean building everything from scratch. It means understanding the components, controlling the configuration, and retaining the ability to move. A static site generator that compiles Markdown to HTML, a Git repository you control, and a hosting platform that serves files — this is a stack you own in a meaningful sense. The content is yours in a format that predates the web. The build process is a script you can read. The host is interchangeable.

The alternative is a managed system where the content is stored in a proprietary format, the build process is opaque, and migration requires exporting through an interface the platform controls. This is not ownership. It is tenancy with the appearance of control.

The practical argument against ownership is maintenance. Someone has to keep the stack running. For a managed platform, that someone is the vendor. The cost is dependency. For a self-owned stack, that someone is you. The cost is time and competence.

The calculation depends on what you are publishing and why. For ephemeral content on borrowed infrastructure, managed platforms are rational. For a publishing operation with a long time horizon, the maintenance cost of ownership is almost always lower than the accumulated cost of dependency — in money, in constraint, and in the friction of working within someone else's system.

The files are the archive. Everything else is logistics.