It needs some changes. will post soon!

Cool! good PR 👍

@RealOrangeOne What is the your current requirement?

First some thoughts from my side -

migrations can always be run on startup,

Migrations are more or less used for "Settingup" / "preparing" the db and isn't normally required to run on every startup.

I'm hoping at some point we can get to a point where the setup container isn't necessary

setup container is not (read "should not be") required for a production system. I would like to emphasize that the docker-compose as mentioned in the docs, is only meant as a mere starting point.

who don't set the credential variables in their compose files don't keep creating admin users every time the application starts.

Current migrations does not create admin/default user every time. Once it is created on the first run, the init_admin will skip creating another time (as it should) check plausible_release.ex#L32 so separating it might not work as you intended.

Instead, I would like to see a separate command for resetting admin password, this would resolve #230 what do you guys think?

Migrations are more or less used for "Settingup" / "preparing" the db

My understanding of migrations is that they configure the DB schema. Should said schema need to change, migrations would need re-running (although they'd only run things required to get from the current state to the new state).

setup container is not (read "should not be") required for a production system. I would like to emphasize that the docker-compose as mentioned in the docs, is only meant as a mere starting point.

I totally agree, in my setup I avoided the need for a setup container entirely, and it's worked out great, and IMO much easier to comprehend what's going on. Hoping to contribute said process back at some point.

Current migrations does not create admin/default user every time.

This is the crux of the issue i'm trying to resolve. If you don't setup $ADMIN_USER_NAME etc, the migrations will create you a new admin user every time. For my use case, I don't want these set in the environment, as it's more things to sync up should I ever change email / password. Also means the docker-compose.yml file stays lighter, which is nice.

To avoid the DB schema becoming out of sync (whether forgetfulness or auto update), it'd be handy to run entrypoint.sh db migrate as part of the container startup, as the migrations would always be run. I've tested running them multiple times and it seems to work fine. Unfortunately this creates an admin user every time the container restarts, which is annoying. This fix prevents that, at the cost of an additional step at install time.

Instead, I would like to see a separate command for resetting admin password, this would resolve #230 what do you guys think?

This feels like a separate requirement, but yes I think that'd solve #230.

I'm hoping at some point we can get to a point where the setup container isn't necessary, which is how i've setup plausible myself, but that'll come as a later PR.

Do you have a branch somewhere showing your WIP? I'm having issues (#243) with the self-hosted setup and am curious if your revised methodology has solved them?

@StudioLE I don't, although I can say I never hit #243.

@tckb Are you recommending changes to this PR?

I'm in favour of merging it. For the cloud setup for example we don't want any admin user at all. I would like to be able to run migrations separately without creating an admin user.

Lets go with it for now. We can figure out any issues later.

Take this comment with a grain of salt because I have very little idea of what I'm doing haha

This change seems to have caused an error for me here's a screenshot of the error that brought me here.

I reverted this change locally and have things up and running. I'm not sure what the issue with the change is specifically, though.

Thanks a bunch for making this this self-hosted option available.