Choose a lane

A lane is the infrastructure behind a Runlane runtime:

lane = storage + delivery

Choose one lane for the whole runtime. Individual tasks do not choose their own lane.

Pick a lane

Use this rule:

1. For development or tests, use the Local lane.
2. For production with always-on workers, start with Postgres polling.
3. For Lambda or SQS consumers, use Postgres and SQS.

Local lane

+----------------------------------+
| one process                      |
|                                  |
| app + worker --> in-memory state |
+----------------------------------+

Use createLocalLane() for development, tests, and small examples. The producer and worker must share the same process. State disappears when that process exits.

Postgres polling

producer -- writes run -----------> Postgres
worker   -- polls and claims -----> Postgres
Postgres -- best-effort signal ---> worker

Use postgresPollingLane() when long-running workers can connect to Postgres. Postgres stores the run and decides which worker may claim it. The wake signal reduces idle delay, but workers still read storage for truth.

This is the smallest shipped production setup.

Postgres and SQS

producer
   |
   v
Postgres (run + outbox)
   |
   v
publisher --> SQS --> worker
                      |
                      v
                   Postgres

Use postgresSqsLane() when SQS should wake Lambda functions or long-running consumers. Postgres still owns run state. An SQS message only tells the worker which run to check.

Duplicate or stale SQS messages do not create a second run. The worker re-reads Postgres before core decides what to do.

Production requirements

Both production lanes need:

• Postgres migrations before the new app starts;
• a maintenance process for schedules, retries, waits, expired leases, cancellations, and delivery recovery;
• producers and workers configured with the same environment, queues, and task catalog.

Continue with deploy using Postgres polling or deploy using Postgres and SQS.