Skip to content

Standalone Deployment

Use the standalone deployment path when you want the simplest route to running Lombok.

This page is intentionally conservative. It summarizes what the current docs and inspected repository references clearly support without inventing missing deployment details.

Standalone is the best fit for:

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

If you want an independently managed PostgreSQL lifecycle, use the Separate DB Deployment path instead.

The documented release flow exposes a standalone release command. For example:

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

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

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

The referenced standalone demo shape includes:

  • image lombok-standalone:latest
  • port mapping 8080:8080
  • a deployment shape that bundles PostgreSQL for the standalone flow
  • additional capability and seccomp settings for the worker environment

Start from the repository’s real standalone demo artifact:

  • docker-compose.standalone.demo.yml

That file is a safer baseline than a short handwritten snippet because it includes the runtime assumptions the repository actually expects.

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

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

After building the release artifact, use the repository’s standalone demo compose file as your starting point and adapt it carefully for your environment.

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

Treat the demo compose file as the source of truth for which values are actually required.

A dedicated Environment Variables page is available for operator-facing configuration details, but validate any deployment-specific changes against the main application repository before treating it as a complete reference.

Compared with a separate-db setup, standalone keeps more of the system packaged into one deployment shape.

That makes it a good default when you want:

  • fewer moving parts
  • a simpler first deployment
  • a local or demo-friendly baseline

It may be a worse fit when you need:

  • independently managed PostgreSQL infrastructure
  • stricter separation between app and database lifecycle
  • more production-specific operational patterns

This page does not yet document, in verified detail:

  • reverse proxy setup and TLS termination beyond the high-level contract in Reverse Proxy & Domains
  • domain configuration beyond the documented wildcard/subdomain model
  • 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.

After choosing standalone:

  • review the Deployment Overview for the broader deployment context
  • follow the Quickstart
  • configure Storage
  • plan for environment variables, reverse proxying, upgrades, and troubleshooting as separate operator tasks