Skip to content
Lombok Docs

Deployment Overview

This page is the starting point for self-hosting Lombok.

It gives a conservative, source-aligned overview of the deployment shapes that the Lombok repository clearly exposes today. It is intentionally careful: earlier draft docs mixed in speculative details that do not map cleanly to the current inspected sources.

What this page covers

Section titled “What this page covers”

Use this page to:

  • understand the currently documented deployment variants
  • choose between standalone and separate-db
  • understand which repository artifacts are the safest baseline
  • identify which follow-up pages you should read next

If you only want a fast first run, see the Quickstart.

What the codebase clearly supports

Section titled “What the codebase clearly supports”

From the inspected documentation and referenced repository artifacts, Lombok currently exposes two primary release variants:

  • Standalone
  • Separate DB

The current release flow is described through dx commands that require a version argument. For example:

Terminal window
./dx release standalone 1.2.1-beta-rc3
./dx release separate-db 1.2.1-beta-rc3

The repository also references concrete deployment artifacts such as:

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

Those artifacts are more trustworthy than an invented minimal example because they reflect real runtime assumptions from the Lombok repository.

Choosing a deployment shape

Section titled “Choosing a deployment shape”

Standalone

Section titled “Standalone”

Choose standalone when you want the simplest path to a working Lombok deployment.

This is the best fit for:

  • evaluation
  • demos
  • smaller deployments
  • environments where operational simplicity matters more than external service separation

The currently referenced standalone demo artifact shows:

  • image lombok-standalone:latest
  • host port mapping 8080:8080
  • additional capability and seccomp settings for the worker sandbox

Read next: Standalone Deployment

Separate DB

Section titled “Separate DB”

Choose separate-db when you want Lombok connected to an external or independently managed PostgreSQL database.

This is the better direction for:

  • production deployment
  • managed database infrastructure
  • independent database backup and lifecycle management

The currently referenced separate-db style artifact shows:

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

A dedicated Separate DB Deployment page is now available for this deployment shape.

Use the repo demo files as the baseline

Section titled “Use the repo demo files as the baseline”

The safest current guidance is:

  • use docker-compose.standalone.demo.yml as the baseline for standalone
  • use docker-compose.demo.yml as the baseline for separate-db style deployment

These files are safer starting points than a short hand-written snippet because they include real environment variables and runtime assumptions.

Minimal examples are risky

Section titled “Minimal examples are risky”

A tiny compose example may look easier to copy, but it can be misleading if it omits required runtime details.

The inspected docs reference deployment examples that include values such as:

  • PLATFORM_HOST
  • PLATFORM_HTTPS
  • PLATFORM_PORT
  • INITIAL_USER
  • AUTH_JWT_SECRET
  • CREATE_DATABASE
  • RUN_MIGRATIONS
  • database credentials
  • worker-related security settings in the standalone case

Because of that, Lombok deployment guidance should start from the repository’s real demo artifacts instead of a “minimal” example that may be incomplete.

Operator mental model

Section titled “Operator mental model”

When deploying Lombok, think in terms of these operational concerns:

  • deployment shape — standalone vs separate-db
  • host and URL strategy — how users reach the platform
  • PostgreSQL lifecycle — bundled, separate container, or external management
  • object storage configuration — connect Lombok to S3-compatible storage
  • upgrade path — how release artifacts are built and rolled forward
  • logs and debugging — how you inspect failures once deployed

This page introduces those areas. Deeper task pages should cover each one separately rather than mixing them into a single installation guide.

What not to assume from current docs

Section titled “What not to assume from current docs”

Do not use this page as evidence that Lombok currently recommends or requires:

  • SQLite as the primary deployment database
  • Redis as a required queue backend
  • a specific multi-service worker topology unless validated from current release artifacts
Section titled “Related pages”

Planned follow-up pages

Section titled “Planned follow-up pages”

This overview is intended to sit above more specific Self-Hosting pages, including:

  • backups and recovery
  • troubleshooting