The third-party app catalogue my self-hosted apps came from fails to sync and the project is dead — how do I get my apps off it without losing the data?

Your data is fine, and the reason it is fine is the single most useful thing to understand here: the catalogue owns the app definition, not the storage.

What a catalogue entry actually is: a template that says which image to run, which ports to publish, which environment variables to set, and which host paths to mount inside the container. When you filled in the deployment form you were filling in that template. The result was a running container plus one or more directories on your pool.

The container is disposable. It is a process built from an image that anybody can pull. The directories are not disposable, and they are sitting on your pool exactly where you told the form to put them, completely untouched by whether the catalogue can be reached.

So the migration is: find out, for each app, which paths it writes to, and then reproduce the container yourself pointing at those same paths.

Step one — inventory, before you change anything. For each deployed app, open its configuration and write down four things:

• the exact image and tag it is running
• every host path that is mounted into the container, and where it lands inside
• every environment variable, including the ones that look like noise
• every published port

Do not trust your memory for the environment variables. Half of them will be database credentials, and an app whose database password changes underneath it fails in confusing ways.

Step two — take a snapshot of every dataset involved. Not a backup, a snapshot, right now, before you touch anything. It costs almost nothing and it turns every subsequent step into something you can undo.

Step three — stop one app and rebuild it by hand. Pick the least important one. Stop it, write a plain compose file from the four things you wrote down, start it, confirm it comes up with all its data. You will learn more from doing this once than from any amount of planning.

Step four — repeat, hardest last.

The one that will genuinely bite you is anything with a bundled database. If an app came with its own database container, the database's data directory is also just a path on your pool, but it is version-sensitive: a database engine will refuse to start against a data directory written by a newer version of itself. So when you rebuild that one, pin the database image to the same version the catalogue was running, get it up, and only then think about upgrading.

The lesson to carry forward, which is worth more than the migration itself: never let something else decide where your data lives. Create the datasets yourself, with names you chose, and point apps at them. Then any layer above can be thrown away and rebuilt on a wet afternoon.

Adding one practical thing to the inventory step, because doing it by hand through a UI for a dozen apps is miserable and error-prone.

Whichever container runtime is underneath, it can tell you the full configuration of a running container — image, mounts, environment, ports — in one command, as structured output. Dump that for every running container into a file now, while the catalogue is still limping along, and commit it to a git repo somewhere off the box.

That file is your migration plan. It is also the thing you will wish you had if the box dies mid-migration, and it costs you thirty seconds.

After that, writing the compose files is transcription rather than archaeology.

One caveat on the dumps: environment variables will include secrets in clear text, so that repo is private or it is on a USB stick in a drawer, not on a public host.