Building without a DB connection

Sometimes your CI build can compile code, generate files, and publish artifacts long before the runtime can talk to the production database. That is normal. What matters is knowing which Dyrected steps are build-time safe and which ones only make sense once the app actually boots.

The key distinction is simple:

build-time tooling can often run without a database
serving the self-hosted Dyrected API still requires the runtime to reach its database

What works without a DB connection

Generating types from a local config file

This path does not need a live database:

npx dyrected generate:types

When you generate from dyrected.config.ts, the CLI reads your local schema definition and writes dyrected-types.ts. That is a code-generation step, not a database step.

Cloud schema sync in builds where credentials are absent

This is also safe to leave in CI:

npx dyrected sync:schema --skip-on-error

The current CLI already treats missing Cloud credentials as a skip condition rather than a hard failure. That is why init can wire dyrected:sync-schema into postbuild for Cloud projects without breaking self-hosted or preview builds that do not have the Cloud variables present.

Next.js code builds

In a self-hosted Next.js app, dyrectedNextHandler does not initialize the Dyrected server during next build. It initializes lazily when the mounted route is first requested. So a successful build only proves the code compiled. It does not prove the runtime can reach the database.

What still needs the DB

As soon as the self-hosted Dyrected app actually initializes, the runtime boundary starts to matter.

For SQL adapters, createDyrectedApp() calls the adapter's sync() during initialization. That means the serving environment needs real database connectivity at that point.

In practice, that means:

the bundle can exist before the database is reachable
the deployed API cannot serve correctly until the database is reachable
a green build is not the same thing as a healthy rollout

The safe deployment pattern

If your platform separates build from runtime, treat them separately:

build the app and artifacts
provide runtime env vars and network access
start the server
verify the Dyrected route can initialize against the real database

That keeps you from overloading the build stage with checks it cannot prove anyway.

Common cases

Cloud-backed frontend

If your app only talks to Dyrected Cloud, there is no self-hosted database connection for the app build to worry about. Your build mostly needs the right public URL and any schema-sync workflow you chose.

Self-hosted on serverless or managed app hosts

These platforms commonly build in one environment and boot in another. That is fine, but the runtime environment still needs:

a reachable DATABASE_URL
any storage provider credentials required for uploads
a stable DYRECTED_JWT_SECRET

Static generation with live preview or content fetches

If your own application code fetches live Dyrected content during build, that is an app-level choice. Dyrected does not require it, but your page code might. When those fetches are not essential to the build artifact, prefer runtime reads or revalidation instead of making the entire build depend on backend availability.