Should I be able to reach my internal Fly Postgres cluster from my build container?

[uncvrd]

Hi! I have a containerized NextJS app that I am trying to build using the Fly Builder container that is autoprovisioned for my account. One of the final steps in the build process is to run database migrations. However, my Fly Postgres application refuses to connect to the internal IPV6 address that was provisioned when I ran fly postgres attach.

I’m wondering if the build container isn’t apart of the same internal network as my Postgres deployment because I see the following:

#24 1.792 @foundrydev/database:db:migrate:deploy: > prisma migrate deploy
#24 1.792 @foundrydev/database:db:migrate:deploy:
#24 3.668 @foundrydev/database:db:migrate:deploy: Environment variables loaded from .env
#24 3.670 @foundrydev/database:db:migrate:deploy: Prisma schema loaded from prisma/schema.prisma
#24 3.697 @foundrydev/database:db:migrate:deploy: Datasource "db": PostgreSQL database "encore_staging_web", schema "public" at "[fdaa:0:3735:0:1::2]:5432"
#24 3.933 @foundrydev/database:db:migrate:deploy:
#24 3.936 @foundrydev/database:db:migrate:deploy: Error: P1001: Can't reach database server at `[fdaa:0:3735:0:1::2]`:`5432`
#24 3.936 @foundrydev/database:db:migrate:deploy:
#24 3.936 @foundrydev/database:db:migrate:deploy: Please make sure your database server is running at `[fdaa:0:3735:0:1::2]`:`5432`.
#24 3.967 @foundrydev/database:db:migrate:deploy:  ELIFECYCLE  Command failed with exit code 1.

I ran the fly postgres attach command and pasted the connection string generated from this output to the connection string Prisma is requiring.

I am using the --remote only flag on my fly deploy command to build this image remotely so this should be in the internal network right?

fly deploy --detach --dockerfile apps/web/Dockerfile --config ./apps/web/fly.staging.toml --remote-only --build-arg ENV=staging

I deployed a couple different applications that use these attached connection strings and it connects with no issues to the internal IPV6 address at runtime so I’m guessing there is some sort of technicality with build containers that I just don’t understand at the moment. Am I on the right track? Happy to provide more context if needed. Thanks!

[rubys]

Should I be able to reach my internal Fly Postgres cluster from my build container?

No, but deploy.release_command is probably what you are looking for.

If this section is present, a VM will be used to run your docker image, your docker ENTRYPOINT, and the release_command. This will be done after the build completes and before your image is deployed.

[uncvrd]

Ok thanks for clarifying - the release_command would suffice for the migrations step but NextJS, when building, also requires connection to the database to statically generate pages that are loaded from the database so I guess I’ll have to go the route of exposing my database externally, correct? External Connections · Fly Docs

[rubys]

I guess I’ll have to go the route of exposing my database externally

Personally, not a fan of doing that. I’d recommend making your startup command a script that does this final step then runs the server. Yes it will be run on every instance that you deploy, but again, not a fan of exposing databases to the internet.

[uncvrd]

Me neither - I just don’t think I can disable the static site generation step of the build process for NextJS apps though (which requires a DB connection during the build process)

[rubys]

I’m not suggesting disabling that step. Just running in on the deploy machine. Without having seen your package.json, this probably can be accomplished merely by adjusting the scripts section.

Something along the lines of renaming start to server. And then adding a new start script that looks something like npm:generate npm:server (or whatever the name of the step is that does generation).

[uncvrd]

Oh I see! Thanks for the alternative - would definitely be rough on scaling instances though as the build step (that we would be delaying until the deploy machine runs since this build step requires a DB connection) takes several minutes to execute anyways, appreciate the insight!