Skip to content
Lombok Docs

Quickstart

This quickstart gets Lombok running with the standalone deployment that best matches the current Lombok codebase and release flow.

Lombok is a self-hosted storage and compute platform built around:

  • a NestJS API
  • a React web UI
  • PostgreSQL for application data
  • S3-compatible storage for object data
  • a core worker runtime for background execution

If you want a contributor setup instead of a deployment setup, see Local Development with dx.

Before you begin

Section titled “Before you begin”

You should have:

  • Docker and Docker Compose installed
  • a machine where you can run containers
  • a hostname or local URL you can use for Lombok
Section titled “Recommended approach”

The Lombok repository currently exposes two release/build flows:

  • standalone
  • separate-db

For a first run, prefer standalone.

That is the clearest beginner path because it is the release variant intended to package Lombok for simpler deployment.

Fast path

Section titled “Fast path”

1. Build or obtain the standalone image

Section titled “1. Build or obtain the standalone image”

If you are building from source, generate the standalone release image from the main Lombok repository.

The dx command requires a version argument. For example:

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

That produces the standalone image used by the repository’s standalone demo flow:

  • lombok-standalone:latest

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

2. Use the standalone demo artifact as your working baseline

Section titled “2. Use the standalone demo artifact as your working baseline”

The best source-aligned starting point is the repository’s standalone demo compose file:

  • docker-compose.standalone.demo.yml

That file shows important runtime details that matter for standalone deployment, including:

  • image name
  • port mapping
  • environment variables
  • required Linux capabilities for the worker sandbox

A simplified but source-aligned shape looks like this:

docker-compose.yml
services:
  app:
    image: lombok-standalone:latest
    pull_policy: never
    environment:
      PLATFORM_HOST: lombokdemo.localhost
      PLATFORM_HTTPS: false
      PLATFORM_PORT: 8090
      INITIAL_USER: demo
      AUTH_JWT_SECRET: replace-with-a-random-string
      AUTH_EMAIL_VERIFICATION_JWT_SECRET: replace-with-a-random-string
      DB_PASSWORD: example-password
      DB_NAME: lombok_demo
      DB_USER: lombok_demo
      CREATE_DATABASE: true
      RUN_MIGRATIONS: true
    ports:
      - '8080:8080'
    cap_drop:
      - ALL
    cap_add:
      - SETUID
      - SETGID
      - SYS_ADMIN
      - SYS_CHROOT
      - SETPCAP
      - CHOWN
      - DAC_OVERRIDE
      - DAC_READ_SEARCH
      - FOWNER
    security_opt:
      - seccomp=unconfined
    userns_mode: host

[!IMPORTANT] Treat the repository’s docker-compose.standalone.demo.yml as the canonical example for this deployment shape. If you adapt it, keep the worker-related security settings unless you have validated an alternative configuration.

3. Start Lombok

Section titled “3. Start Lombok”
Terminal window
docker compose up -d

Then inspect logs:

Terminal window
docker compose logs -f app

4. Open Lombok

Section titled “4. Open Lombok”

With the standalone demo-style mapping shown above, open Lombok at:

http://localhost:8080

If you change the port mapping, use the host port you configured instead.

From there, complete first-time setup and sign in with the initial user flow configured by your deployment.

5. Configure storage

Section titled “5. Configure storage”

Lombok uses S3-compatible storage backends for object storage.

After first login, the next meaningful step is to configure a storage backend so you can start using folders and object workflows.

Then continue with:

What this quickstart intentionally avoids

Section titled “What this quickstart intentionally avoids”

This page intentionally does not document:

  • SQLite-based deployment
  • Redis-backed queue setup
  • speculative multi-service topologies not verified against the current codebase
  • separate-db deployment details mixed into the standalone path

Those details either do not match the current codebase or belong in deeper deployment documentation.

Next steps

Section titled “Next steps”

After the quickstart:

Need more than a quickstart?

Section titled “Need more than a quickstart?”

For deployment variants and broader operations guidance, start with Deployment Overview.