NextJS and Prisma static build with fly volume sqlite database

Questions / Help Build debugging
1

I have a NextJS app that uses Prisma ORM to connect to a SQLite DB located in a mounted volume. This works great except for deployments, where I have to run next build in the docker-entrypoint.js file after deployment, which causes health checks to always fail. I tried to define my own health check but it doesn’t seem to do anything.

As far as I know, there’s no place in the configs I can call next build where the volume will be available, but is there a workaround that can help prevent the health check problems?

My fly.toml:

app = "test-app"
primary_region = "ams"

[env]
  DATABASE_URL = "file:./data/tracking-api.db"

[[mounts]]
  source = "data_volume"
  destination = "/app/data"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

[checks]
  [checks.healthz]
    grace_period = "60s"
    interval = "10s"
    method = "get"
    path = "/api/healthz"
    port = 3000
    timeout = "5s"
    type = "http"

My entrypoint:

#!/usr/bin/env node

const { spawn } = require("node:child_process");

(async () => {
    // If running the web server then build app and migrate database
    if (process.argv.slice(2).join(" ") === "yarn run start") {
        await exec("npx prisma migrate deploy");
        await exec("yarn run build");
        await exec("yarn install --production=true");
    }

    // launch application
    await exec(process.argv.slice(2).join(" "));
})();

function exec(command) {
    const child = spawn(command, { shell: true, stdio: "inherit" });
    return new Promise((resolve, reject) => {
        child.on("exit", (code) => {
            if (code === 0) {
                resolve();
            } else {
                reject();
            }
        });
    });
}

Thanks!

2

Correct.

I’m actually seeing something similar in my rails application, but I haven’t investigated further. The details are quite different, but the pattern is the same: extra steps needed at deployment result in health checks performed during startup failing but the machine otherwise starting and no health checks being run thereafter.

I’ll try to build a smaller test case and get somebody to look into it.

1 Like
3

I’ve solved the issue with the following checks config, and deploying with fly deploy --wait-timeout 300

...
[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

  [[http_service.checks]]
    interval = "30s"
    timeout = "5s"
    grace_period = "2m0s"
    method = "get"
    path = "/api/healthz"

[checks]
  [checks.healthz]
    port = 3000
    type = "http"
    interval = "10s"
    timeout = "5s"
    grace_period = "2m0s"
    method = "get"
    path = "/api/healthz"