Also, just as a side note, after hardcoding this just to get something working, we are getting connection errors on an app connecting over internal DNS on an app within the same org. We also set the DATABASE_URL via the flyctl postgres attach command.
Error: P1001: Can’t reach database server at my-api-pg.internal:5432
Took a closer look at your Dockerfile and: you probably don’t want to migrate at build time. You should run that before running your app.
Sorry, I got confused earlier. You can’t access your postgres database because you’re trying to connect at build time in an environment that probably doesn’t have access to the private network.
Your Dockerfile should only contain the steps to get your app in a runnable state.
Maybe your dist/server.js could run your migrations before starting up? It’s probably best to run them from a different environment (like your own computer which you can connect to your private network via WireGuard). We still have work to do to make our postgres more friendly to use.
Gotcha, yup I agree, I would like to have all that run before the Dockerfile spins up the servers, but was my only option with the internal DNS access to the PG app.
Is the best / only way to manage this process at the moment running these migrations manually via local machine and wireguard? Is there a way to run these on a CI/CD setup?
If you want them to be automatic, I’d probably use an ENTRYPOINT that ran the migrations and then ran your server. I’d run them manually the first time to avoid a slow boot.
A CI can run it if it can connect to WireGuard however, if it runs the migration and the app fails to launch, you might get your database in a weird state unless all your migrations are additive.