Tobias

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.

Concrete on the persistence point, because "mount a config file" trips people up in a specific way.

If you mount a single file over a path that the image expects to generate, and your file is missing something the app writes at first run, you can end up with an app that starts but behaves oddly. Safer pattern with most images: mount a directory that the app treats as its config directory, let the app populate it on first run, and then edit the file that appears there on the host.

That way the file is the app's own file, in its own format, and you are editing it from outside rather than fighting the image over ownership of it.

And whatever you end up with, put it in version control. Config that only exists on the box is config you will reconstruct from memory at the worst possible time.

Once you are in, immediately change the password to something you generated properly and store it in your password manager rather than in the deployment form.

Credentials in a deploy form tend to end up in exported configuration, in the orchestrator's own database and in your shell history. Treat the one you set at install as a bootstrap value, not a permanent one.

Sideways suggestion that will save you an evening: get it running from a plain compose file first, on the same box, with a throwaway data path.

Not as the final setup — as a diagnostic. It takes ten minutes, it removes the entire orchestration layer from the picture, and it tells you whether the app or the platform is the problem. If it comes straight up from compose, you know the image is fine and your host is fine, and you are debugging the deployment form. If it fails from compose too, the log is right there in your terminal with nothing in the way.

Half the time people discover the compose version is what they wanted all along and never go back.