Current versionv0.4.0

Background tasks. Your infrastructure.

Runlane lets you run long-running TypeScript tasks with retries, queues, durable steps, and a history you can inspect. Write once, start locally, and deploy on your infrastructure.

Run your first task Choose your setup

• Cron & interval scheduling
• Retries & backoff
• Durable steps
• Queues & concurrency
• Waits & signals
• Human approvals
• Child tasks
• Deduplication
• Timeouts
• Cancellation
• Observability
• Typed inputs & outputs

Write the task. Runlane handles the run.

Runlane is a task engine for TypeScript. Define inputs, outputs, and the work to do. Runlane keeps track of each run, its attempts, and what happened along the way.

import { task } from '@runlane/core'
import * as z from 'zod'

export const greet = task({
  id: 'greet',
  schema: z.object({ name: z.string() }),
  output: z.string(),
  run: ({ name }) => `Hello, ${name}!`,
})

Install the runtime, the local lane, and Zod:

npm install @runlane/core @runlane/lane-local zod

The quickstart walks through registering a task, triggering it, and reading the result. The local lane stores runs in memory; use a Postgres lane when they need to survive process exits.

Put your background work in motion

Your tasks bring the libraries, APIs, and business logic. Runlane coordinates when they run, retry, or wait.

Explore all recipes for streaming, semantic search, browser automation, Python, media processing, marketing, schedules, concurrency, and retries.

Every attempt has a history

Trigger a task to store a run. A worker claims it, executes your TypeScript, and records the result. Read the status, output, and event history through the runtime.

Retries, waits, and recovery start a new attempt from the beginning of the handler. Use durable steps to reuse completed work and provider idempotency to protect external actions from duplicate submissions.

YOUR APP              RUNLANE LANE                         YOUR WORKER
                      ┌────────────────────────┐
task() + trigger() ────▶ │ storage: run + events  │
                      │ delivery: poll / wakeup│ ────▶ claim + run TypeScript
                      └───────────▲────────────┘            │
                                 └── result / retry / wait ──┘

queued ──▶ running ──▶ retrying ──▶ running ──▶ succeeded

YOUR APP
task() + trigger()
       │
       ▼
┌─────── RUNLANE LANE ───────┐
│ storage: run + events          │
│ delivery: poll / wakeup        │
└───────────────┬──────────────┘
               ▼
YOUR WORKER
claim + run TypeScript
               │
               └── result / retry / wait

queued ──▶ running ──▶ retrying
                 └──▶ running ──▶ succeeded

Start local. Keep control in production.

A lane combines storage with one delivery mode. In production, Postgres stores run state; workers poll for work or wake through SQS. You operate the workers, database, queues, and external services.

Move from local to AWS, add Runlane to your app, or learn to observe and recover runs.

More adapters are coming

We're planning more lanes so you can choose where task state lives and how workers receive work. These combinations are planned and are not available to install yet.

Redis Streams will first pair with Postgres and MySQL. Using Redis for task state will require a supported single-slot setup and documented durability requirements.

We're also exploring Cloudflare Queues with Durable Objects or D1 for storage, including scheduled maintenance and the platform's execution limits.

Further transport candidates include NATS JetStream, RabbitMQ, Google Cloud Pub/Sub, Azure Service Bus, and HTTP delivery, starting with Postgres storage. Priorities will follow demand.