Cannot log in with the admin username and password I set at install — the app just says the credentials are wrong

A different cause that produces the same symptom, worth ruling out if the reset above does not work: the app initialised correctly but is now talking to a different database than the one it initialised.

Happens when the database host, name or credentials in the environment change between deployments — you renamed something, or a generated password was regenerated on redeploy. The app finds a database that exists and is reachable but has no user table matching what it expects, and hands you a login page it cannot satisfy.

Check the connection settings in the current deployment against what the app's log says it connected to at startup.

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.

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.

The trap in "empty the data path completely" is that a database directory usually contains dotfiles, and a plain wildcard delete misses them. So you look at what appears to be an empty directory, deploy again, and get the identical failure a fifth time.

List the directory including hidden entries before you conclude it is empty. This has cost me more time than I want to write down.

Better still, if your storage supports it: destroy the dataset and create a new one with the same name. There is then no question about what is in it.