Runtime Boundaries

Lombok is easiest to reason about when you understand its real runtime boundaries.

These boundaries matter for:

system design
debugging
security and isolation
docs structure

This page focuses on the concrete mechanisms that separate responsibilities in the Lombok architecture.

API ↔ Browser

The main web UI talks to Lombok through the backend.

This boundary includes:

authenticated HTTP/API calls
realtime Socket.io communication
browser sessions backed by platform auth

The browser is a client of the backend, not the system of record.

API ↔ PostgreSQL

The backend stores platform/application state in PostgreSQL through Drizzle ORM.

This includes things like:

users
folders
task records
app/platform configuration
metadata and platform state

This is distinct from object storage.

API ↔ S3-compatible object storage

Lombok uses S3-compatible storage for object data.

This boundary separates:

platform/application state in PostgreSQL
file/object data in object storage

That distinction is central to Lombok’s storage model.

API ↔ Worker runtime

One of the most important boundaries in Lombok is between the API/control plane and the worker runtime.

At a high level:

the API decides what work should run
the worker runtime executes the underlying worker logic

This boundary exists so app/runtime work is not treated as ordinary inline API logic.

Worker runtime ↔ sandboxed worker execution

The worker system includes a more specific execution boundary:

the core worker runtime coordinates work
worker execution happens inside a sandboxed worker environment

The reviewed codebase and Senior Dev analysis specifically flagged the nsjail-sandboxed worker daemon model as an important part of Lombok’s real execution boundary.

That makes this a key trust and isolation seam in the architecture.

API ↔ task dispatch transport

Another important boundary is the task dispatch layer.

The reviewed architecture indicates that Lombok uses:

a DB-backed task table
Socket.io room-based dispatch between the API and worker-side execution model
no assumed external Redis/BullMQ/RabbitMQ queue in the architecture docs mental model

This is one of Lombok’s more distinctive architectural traits and should be understood as part of its runtime design.

Lombok UI ↔ embedded app UI

Lombok has both:

the main platform UI
embedded app UIs

This is a real runtime and trust boundary, not just a visual distinction.

The reviewed architecture highlighted:

iframe-based embedding
postMessage-style communication
app-scoped/browser-side token and integration behavior

That means embedded app UIs should be understood as a separate presentation/runtime boundary inside the overall product.

Auth boundary

Authentication is another cross-cutting boundary.

The reviewed architecture highlighted JWT-backed auth flows across major communication paths, including backend/API and app-related runtime interactions.

Manifest ↔ execution boundary

An app manifest describes:

triggers
tasks
workers
UI
settings
contributions

But declaration is not execution.

Lombok resolves those declarations into actual runtime behavior through the API, task system, and worker runtime.

Why these boundaries matter

A lot of architectural confusion disappears once these boundaries are clear.

For example:

storage docs become clearer when PostgreSQL and object storage are kept distinct
app docs improve when manifest declaration and worker execution are separated
security/isolation discussions become clearer when iframe boundaries and sandboxed workers are explicit

Simplified boundary map

Browser UI
   ↓
NestJS API
 ├─ PostgreSQL (Drizzle)
 ├─ S3-compatible object storage
 └─ task dispatch / worker runtime
         ↓
   sandboxed worker execution

Embedded app UI
   ↕ iframe / messaging boundary
Main platform UI

Next steps

Continue with: