Own the Source, Rent the Infrastructure

A website can run on a server you administer and still be difficult to move. Its only copy of the content may live in a database on that machine. Its configuration may depend on remembered shell commands. Its backups may have never been restored.

Conversely, a site served by an ordinary hosting provider can have a clear exit path if its source, content and build process are under the owner’s control. The important distinction is between owning the decisions needed to reproduce the product and operating every machine that serves it.

Control does not require owning every machine in the stack. For this website, that led toward a private GitHub repository, Astro source, portable static output and HostingPerTe as the intended production destination. The provider serves the result; it does not define the content model.

Identify what must survive a provider change

The essential assets are more than the visible HTML. Article source, approved images, metadata rules, redirects, build configuration and the knowledge needed to reproduce the output all contribute to the site’s continuity.

Keeping articles in source-controlled MDX means the body and frontmatter can be read without logging into a hosting control panel. The content remains tied to its revision history and the components used to render it. That is a practical form of ownership even though GitHub itself is an external service.

The repository should not be the only recovery copy. Local clones and independent backups can preserve the source if account access is interrupted. Credentials need their own secure recovery arrangement; copying them into the repository would create a different problem.

The useful question is specific: if the current host became unavailable, which information would be missing from a fresh checkout? Any answer that depends on an undocumented setting or a single machine deserves attention.

Static output creates a useful boundary

Astro’s deployment documentation describes building a site for deployment and the distinction between static and server-rendered targets. This project uses static output, so production does not need an application process to render an article request.

That narrows the provider contract. The host must serve files correctly, support the required routing and security behavior, and provide an appropriate transfer path. It does not need to understand the article collection or run the development toolchain.

Pagefind’s generated search assets travel with the build. Search therefore remains part of the portable output rather than requiring an account at a separate hosted search service. Browser behavior and host headers still need verification after a move.

This is a good match for the current product. It would be a poor abstraction if the core requirement became personalized server-side computation or frequently changing private state. Portability should be evaluated against the real application, not treated as a reason to deny necessary capabilities.

The exit path is short, but not empty

The basic recovery model looks simple:

provider unavailable
        ↓
recover source or known-good artifact
        ↓
build and verify if needed
        ↓
deploy to a suitable host
        ↓
verify URLs, headers and search
        ↓
change routing deliberately

Each line contains work. A new host may use a different document root or configuration format. Apache-specific rules will need an equivalent if the destination uses another server. HTTPS, canonical redirects, caching and missing-page behavior should be checked instead of assumed.

A successful upload is also different from a successful migration. The public domain may still point elsewhere, and caches may continue serving older content. The recovery procedure should distinguish destination verification from changing how visitors reach it.

For this site, HostingPerTe is the prepared target. Configuration in the repository and local tests do not establish that the account or public domain has completed activation. That boundary remains explicit until the real destination has been verified.

Keep domain control distinct from hosting

A domain name, DNS service and web-hosting account can be related commercially while representing different responsibilities. The ability to change where a domain points is part of the migration path, so access to that control deserves its own recovery plan.

Document who manages the records and what services depend on them. A website move should not accidentally change email routing or another service because the team treats the entire DNS zone as disposable hosting configuration.

This is not a proposal to move every service to a different provider. Separation is useful when it makes responsibilities clear. Adding accounts without understanding them can create more recovery complexity rather than less.

Portability is the ability to replace a dependency with a known amount of work.

It does not require the amount to be zero. A written list of the necessary adjustments is more useful than a general claim that the site is provider-independent.

Back up the source and understand the gaps

GitHub’s backup guidance describes ways to preserve repository data and notes additional considerations for associated data. A Git copy is valuable, but a repository backup is not automatically a complete backup of every setting and service involved in delivery.

For this project, the recovery inventory should distinguish source history, generated artifacts, repository configuration and credentials. Workflow files live in Git; secret values do not. Provider account access, domain control and any required transfer settings also need to remain recoverable through appropriate secure channels.

A known-good static artifact can be useful when rebuilding is temporarily impossible. It preserves what was actually served, including the publication state at that build time. Source remains necessary for future changes, so an artifact should complement it rather than replace it.

Test recovery in a limited environment. A backup that can be listed is not yet evidence that it can produce a working site. Rebuilding, serving locally and checking important URLs provides more meaningful confidence.

Write down a realistic recovery exercise before it becomes urgent. Start from an independent source copy, use the documented runtime, build into a new directory and serve that output without relying on the normal development server. Check an article, a missing URL, an image and a search query. Record any manual step that was absent from the guide.

That exercise has a bounded claim: it demonstrates that the available source and instructions can recreate a working local artifact. It does not verify a replacement provider, but it removes one important uncertainty before hosting migration begins. Repeat it when the build or recovery model changes, rather than assuming that a successful exercise remains valid indefinitely.

Dependency cost still exists in a static project

Static hosting removes a production application runtime, but development dependencies remain. Astro, plugins, fonts, test tools and the search builder need updates and compatibility checks. A private repository still depends on account access and the service used for collaboration.

The advantage is that these responsibilities are concentrated around changes and builds. A reader opening an already generated article does not require the build toolchain to execute again on the server.

That separation can support a simpler recovery strategy. If an update breaks the build, a previously verified artifact may remain serviceable while the toolchain issue is resolved. If the host fails, source and artifacts can support a move without recovering live application state.

The static-hosting decision explains why this fit the site after the visitor counter was removed. It was a product-specific choice, not a general claim that databases or persistent services are undesirable.

Operate a server when operation serves the goal

Self-hosting can be justified by requirements for custom software, specific operating controls or an explicit learning objective. In those cases, administering the environment may be part of the value. The decision should include updates, monitoring, backups and recovery rather than stop at the first successful deployment.

For this publication, operating a VPS would add responsibilities without improving the current reader experience enough to justify them. Renting suitable infrastructure keeps attention on the source, content and delivery process that distinguish the site.

There is no permanent ideological commitment in that choice. If the product changes, the architecture can be reconsidered. Owning the source and understanding the build make that reconsideration easier because the current provider is not the only place where the product exists.

The strongest ownership is a recovery path you can actually follow.

Keep the source readable, the build documented and the output replaceable. Then choose infrastructure for the work it needs to do today, with a credible plan for leaving when that choice stops fitting.

Sources

1. Astro documentation: Deploy your site — checked 2026-10-11
2. GitHub Docs: Backing up a repository — checked 2026-10-11