Should self-hosted projects ship a resurrection kit?

I recently tested restoring one of my self-hosted services from backup and found the database was recoverable, but the container image, OAuth configuration, and a couple of external integrations were not. The backup was technically valid; the service still wasn’t resurrectable.

That makes me wonder whether projects should be expected to publish a “resurrection kit”: pinned image and dependency versions, exportable configuration, migration notes, and an offline recovery path. Docker can pin images by digest and export them locally, and offline dependency bundles are feasible, but someone has to document and maintain all this. I understand the burden on open-source maintainers, especially volunteer projects.

Still, user control should mean more than owning the server while a registry or authentication provider remains indispensable. Is that a reasonable expectation, or an unrealistic support obligation? Has anyone here successfully revived a service after its upstream disappeared or changed terms?

I’d call it a documented recovery boundary rather than a promise of resurrection. Pinning a digest and exporting the image are straightforward. Reconstructing secrets, provider-side OAuth state, and undocumented integrations is where the real failure surface lives. A kit should state those limits explicitly, not imply that one archive guarantees recovery.

The expectation seems reasonable if “publish” means provide a documented baseline, not indefinitely support every historical version. A maintainer can say which artifacts are exportable, which credentials must be preserved separately, and what cannot be recovered without a third party. That would make the claim of user control much more concrete.

The danger is turning a small project into a release-management department. I’d prioritize a reproducible Compose file, digest-pinned images, a config export, and a tested restore example. “Offline path” can start as a local image tar and dependency bundle, rather than a giant promise to preserve every integration forever.

Please don’t put OAuth client secrets into a convenient export by default. The kit needs a threat model: what is safe to archive, what must be injected during restore, and how secrets are rotated. Recoverability that creates a portable credential dump is not automatically a win.

There’s also a user-expectation issue. People hear “self-hosted” and reasonably infer independence, while the login flow may still depend on someone else’s app registration. I’d rather see a small, honest recovery contract than marketing language about ownership that quietly excludes identity and distribution dependencies.

I’m sympathetic, but “should be expected” needs a scope. A solo maintainer may be able to document the happy path, not preserve every registry credential or provider relationship. Communities, distributions, or downstream operators may be better placed to maintain long-term kits than the original project.

My successful restores have depended less on heroic backup systems than on keeping the boring files: Compose definitions, image archives, secrets inventory, and notes explaining why each setting exists. If the restore instructions fit on one page, I’m more likely to test them. The upstream disappearing is usually when the test becomes urgent.