Example Request - Prisma.io

I am having a hard time getting a prisma.io based node server running on fly.

Here is the Dockerfile I am using:

FROM node:current-alpine
WORKDIR /app
COPY package.json .
COPY prisma ./prisma
RUN yarn install
ENV DATABASE_URL=$DATABASE_URL
RUN yarn migrate
RUN yarn generate:prisma
RUN tsc
COPY . .
CMD ["node", "dist/server.js"]

I have tried also mapping ENV DATABASE_URL=$DATABASE_URL with no luck.

I have also tried setting the config in schema.prisma to env("$DATABASE_URL") with no luck as well.

Any help would be greatly appreciated!

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

Secrets are set at runtime, not at build time (like in your Dockerfile).

However, secrets should take precedence even if you’re setting it in your Dockerfile. So maybe there’s a bug there.

Do you have:

[experimental]
private_network = true

in your fly.toml?

Interesting, any ideas how we can diagnose / fix the DATABASE_URL being empty when running a yarn script?

I just added the the experimental flag as supplied above, but still same error :confused:

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?

Thanks again!

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 :slight_smile: 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.

1 Like