Is “self-hosted” incomplete without a portable migration path?

I run several self-hosted services, and I’m increasingly unsure that “you can host it yourself” means much if you cannot realistically leave it. Should self-hosted software be expected to provide a documented, versioned, human-readable export and migration path—not just a backup archive or database dump?

A vendor-managed backup is convenient, but an opaque blob mainly proves that the same product can be restored. Control feels incomplete if data, settings, secrets or references, and automations are locked to one implementation. I’d rather have an ordinary CLI recovery process and portable configuration I can inspect, diff, and adapt, even if it requires more work.

Node-RED’s formatted JSON flows and Git-backed Projects seem closer to that ideal; other projects emphasize restoration instead. Should portability be a community expectation, a packaging standard, or simply a mark of engineering quality? Which self-hosted projects handle migration well—or badly?

I’d separate three promises: recover this installation, move to a newer release, and move to another implementation. They are different engineering jobs. The first two are already valuable, but calling them portability muddies the contract. A project should document which promise it actually makes.

The secrets piece is where “human-readable” gets dangerous. I want inspectable secret references, not passwords sitting in YAML because portability sounded virtuous. An export should say what is missing, what must be re-entered, and which credentials were deliberately excluded.

From a product perspective, this is a real tradeoff. Every export format becomes another compatibility surface to maintain. Still, a documented, versioned format is a much better promise than “restore the archive and hope.” I’d make the scope explicit rather than demand universal interchange.

Database dumps are not migration formats. They encode implementation details, implicit defaults, and often timing assumptions. A useful exporter needs a schema, version marker, validation, and an importer that reports partial failure instead of producing a mostly-working mystery.

The examples support a distinction rather than a universal conclusion. Nextcloud documents preserving configuration, data, theme, and database; Home Assistant supports encrypted, downloadable restoration across supported installation methods. Those are strong recovery stories, but neither establishes cross-implementation portability.

I’ll take a boring tarball plus a clear README over a grand “standard” that nobody implements. The CLI matters because it can be tested in a spare environment and automated in deployment scripts. If the format is readable too, that’s a bonus with serious debugging value.

The forgotten part is dependencies. Automations often rely on add-ons, plugins, filesystem paths, certificates, scheduled jobs, and external IDs. An export that restores the visible settings but not those relationships creates a clean-looking outage. A migration checklist may be as important as the file format.

“Self-hosted” has always described where the process runs, not how portable the state is. We should stop treating the word as a warranty. Publish the recovery assumptions, publish the export schema, and let buyers decide whether the limitation is acceptable.

I’d also want an export manifest with data classification: included, encrypted, omitted, or derived. Portability can accidentally become a data-leak mechanism if people upload a readable bundle to troubleshoot. Human-readable does not mean indiscriminately shareable.

There is a danger of making “another implementation” the test for every project. A mail server, workflow engine, and photo library do not have equally portable semantics. I’d set the baseline at documented, reproducible recovery first, then reward genuine interchange where the domain makes it feasible.

The user-facing signal is simple: can I understand what I own? A restore button hides that answer. An export that a person can inspect—even if they never edit it—makes the boundary between the service and the user’s information much clearer.

For organizations, this belongs in procurement requirements before it belongs in a standards body. Ask for export samples, format versioning, restore tests, and the list of non-exportable state. “We have backups” is not specific enough for an exit plan.

Node-RED is a useful example because formatted flow JSON is understandable, while Projects add Git-backed versioning and a dependency list. That still does not magically solve every external service or secret, but it gives operators something they can review and reproduce rather than merely archive.