Separate DB Deployment

Use the separate-db deployment path when you want Lombok connected to an external or independently managed PostgreSQL database rather than a database bundled into a single deployment shape.

This page is intentionally conservative. It summarizes what the current docs and inspected repository references clearly support, and frames specific values as coming from the repository’s real release artifacts rather than from invented configuration.

When to choose separate-db

Per the Deployment Overview, separate-db is the better direction when you want:

• production deployment
• managed database infrastructure
• independent database backup and lifecycle management
• stricter separation between the application and database lifecycles

If you instead want the simplest path to a working deployment — for evaluation, demos, or smaller setups — use Standalone Deployment.

What the current sources clearly show

The documented release flow exposes a separate-db release command that requires a version argument. For example:

./dx release separate-db 1.2.1-beta-rc3

The current docs also reference these separate-db-related artifacts in the main Lombok repository:

• docker-compose.demo.yml
• deploy/build-separate-db.sh

The referenced separate-db demo shape includes:

• image ghcr.io/lombokapp/lombok:latest
• port mapping 8090:80
• a separate db service, or an externally managed PostgreSQL instance

Treat those artifacts as the trustworthy baseline because they reflect the runtime assumptions the Lombok repository actually expects.

Safest deployment approach

Start from the repository’s real demo compose file:

• docker-compose.demo.yml

That file is a safer baseline than a short handwritten snippet because it includes the runtime details and service wiring the repository expects for a separate-db-style deployment. Adapt it carefully for your environment instead of replacing it with a minimal example.

[!IMPORTANT] A tiny compose example can be misleading if it omits required runtime details. Use docker-compose.demo.yml as the canonical reference for this deployment shape and change only the values you have validated for your environment.

Build and release flow

If you are building from source, the current documented release flow is:

./dx release separate-db 1.2.1-beta-rc3

If you are deploying a published image instead of building from source, validate the exact tag you intend to use before deployment rather than assuming latest.

After obtaining the image, use the repository’s docker-compose.demo.yml as your starting point.

Database lifecycle

The defining characteristic of this shape is that PostgreSQL is not bundled into a single all-in-one deployment. The referenced demo artifact shows either:

• a separate db service running alongside the application, or
• an externally managed PostgreSQL instance you point Lombok at

This separation is what makes independent backup, restore, and upgrade of the database possible. How you provision and operate that database — managed cloud service, dedicated container, or existing infrastructure — is an operator decision outside the scope of this page.

What to configure

The inspected docs indicate that real Lombok deployment examples include values such as:

• PLATFORM_HOST
• PLATFORM_HTTPS
• PLATFORM_PORT
• INITIAL_USER
• AUTH_JWT_SECRET
• CREATE_DATABASE
• RUN_MIGRATIONS
• database credentials

For a separate-db deployment, pay particular attention to the database credentials and to CREATE_DATABASE / RUN_MIGRATIONS, since their correct values depend on whether the target database already exists and is managed independently.

Treat docker-compose.demo.yml as the source of truth for which values are actually required and how they are wired. A dedicated Environment Variables page is available for operator-facing configuration details, but validate environment changes against the main application repository before treating it as a complete reference.

Operational characteristics

Compared with standalone, separate-db has more moving parts but cleaner separation.

It is a good fit when you want:

• independently managed PostgreSQL infrastructure
• separate backup and recovery for the database
• a more production-oriented operational pattern

It may be a worse fit when you want:

• the fewest possible moving parts
• a single packaged deployment shape
• a quick local or demo baseline

Known limits of this page

This page does not yet document, in verified detail:

• connection settings for an external or managed PostgreSQL instance beyond the variable names above
• backup and recovery procedures
• broader troubleshooting guidance

Those topics belong in separate Self-Hosting pages and should be validated against the main Lombok application repository before they are expanded.

Next steps

After choosing separate-db:

• review the Deployment Overview for the broader deployment context
• compare with Standalone Deployment
• follow the Quickstart for a first run, then adapt toward separate-db
• configure Storage
• plan for environment variables, reverse proxying, upgrades, and troubleshooting as separate operator tasks