Priya R.

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.

You have diagnosed it yourself in the third paragraph and not realised: the credentials in the deployment form only apply to a virgin database.

Here is the mechanism. On first start, the app looks at its database. If the database is empty, it runs its initial setup: creates the schema, creates the administrator account from the values you supplied, marks itself installed. If the database already contains a schema, it skips all of that and goes straight to serving the login page — and your username and password are simply never read.

So the question is where a pre-existing database came from. In practice, three sources:

• A previous failed deployment. The first attempt got far enough to initialise the database and then died. Every attempt since has been talking to that database, with whatever credentials attempt one used, or none if it did not get that far.
• A reused data path. You pointed the new deployment at a dataset that a previous install had used.
• A restored volume. You restored from a backup and the app now holds the account from the backup, not the one in your form.

Going straight to a login page rather than a setup wizard is the tell, and it is conclusive.

Two ways out, and pick based on whether the existing database has anything in it you want.

If it is genuinely a fresh install with nothing to lose: stop the app, empty the data path completely — actually empty, including hidden files and the database directory — and deploy again. This time the setup will run and your credentials will take.

If there is data in there you want to keep: do not wipe it. Almost every app of this kind ships a command-line tool to reset a password or promote a user to administrator, and it can be run inside the running container. Find that command in the app's documentation, run it against the existing account, and log in with the new password.

If you do not even know what the existing administrator is called, most of these tools have a way to list users. Do that first.

To make the clean-slate test unambiguous: create a brand new dataset with a name you have never used, point the app at that, and leave every other setting at its default. No custom port, no custom admin name, nothing.

If it deploys, you have proved the problem is state or configuration, and you can add your customisations back one at a time until it breaks.

If it still fails with a genuinely empty dataset and stock settings, it is environmental — permissions, resources or networking — and that is a different and shorter list to work through.

The reason to do this rather than keep tweaking: right now every attempt changes two variables, the thing you edited and the leftover state from last time. You cannot learn anything from that.

Worth adding both names, not one.

If you reach the app at a public hostname from outside and at an internal name or IP from inside your network, both need to be trusted, or the internal path breaks the moment you get the external one working. People fix the external case, feel pleased, and then find that the backup script hitting it internally has been failing for a week.

A lot of apps take a list rather than a single value for exactly this reason.

One thing to check before you commit: whether the firmware will actually boot from the eMMC once an OS is on it, and whether it stays first in the boot order.

Some of these appliances ship with the eMMC carrying a vendor OS and a firmware boot order tuned for that. Install something else on it and the machine boots to the wrong thing, or to nothing, after a power cut. It is recoverable but it is much nicer to discover it now, with an empty machine, than after you have migrated your data.

Test it properly: install, then pull the power rather than doing a clean shutdown, and confirm it comes back on its own. That is the case that matters, because that is what a power cut looks like.