workflow/docs/deploying.mdx

Workflow SDK - Build durable, resilient, and observable workflows

---
title: Deploying
description: Deploy workflows locally, on Vercel, or anywhere using pluggable World adapters.
type: overview
summary: Learn how to deploy workflows to different environments using World adapters.
related:
  - /worlds/local
  - /worlds/postgres
  - /worlds/vercel
  - /worlds/building-a-world
---

The same workflow code can run locally during development, on Vercel with zero configuration, or on any infrastructure using **Worlds**, which are pluggable adapters that handle storage, queuing, and communication.

## Local development

During local development, workflows use the **Local World** without configuration. The Local World stores workflow data in a `.workflow-data/` directory and processes steps synchronously for development and testing.

```bash
# Run your dev server to use workflows locally
npm run dev
```

You can inspect local workflow data using the CLI:

```bash
npx workflow inspect runs
```

<Callout>
  Learn more about the [Local World](/worlds/local) configuration and internals.
</Callout>

## Deploying to Vercel

Deploy workflows to production on Vercel without configuration. Workflows deployed to Vercel use the **Vercel World**.

The Vercel World provides:

- **Durable storage**: Workflow state persists across function invocations
- **Managed queuing**: The queue processes steps reliably with automatic retries
- **Automatic scaling**: Workflows scale with your application
- **Built-in observability**: View workflow runs in the Vercel dashboard
- **Multi-region**: The region that creates each run also hosts its workflow data, queue, and streams, keeping them close to your users

Deploy your application:

```bash
vercel deploy
```

<FluidComputeCallout />

<Callout type="warn">
  **Enable access to System Environment Variables before deploying.** Workflow
  recognizes a Vercel deployment by `VERCEL_DEPLOYMENT_ID`, which Vercel exposes
  to your build and your functions only when the **Enable access to System
  Environment Variables** checkbox is selected under **Settings**, then
  **Environment Variables**, in your project. With it cleared, the deployment
  falls back to the Local World and every run fails on the read-only
  filesystem. See
  [System environment variables](/worlds/vercel#system-environment-variables).
</Callout>

<Callout>
  Learn more about the [Vercel World](/worlds/vercel) and its capabilities, including [multi-region](/worlds/vercel#multi-region).
</Callout>

## Self-hosting & other providers

For self-hosting or deploying to other cloud providers, you can use community-maintained Worlds or build your own.

<Cards>
  <Card title="Explore Worlds" href="/worlds">
    Browse official and community World implementations with compatibility status and performance benchmarks.
  </Card>
  <Card title="Build Your Own" href="/worlds/building-a-world">
    Learn how to implement a custom World for your infrastructure.
  </Card>
</Cards>

### Using a third-party World

To use a different World implementation, set the `WORKFLOW_TARGET_WORLD` environment variable:

```bash
export WORKFLOW_TARGET_WORLD=@workflow/world-postgres
# Plus any world-specific configuration
export DATABASE_URL=postgres://...
```

Each World may have its own configuration requirements. Refer to that World's documentation for details.

## Observability

The [Observability tools](/docs/observability) work with any World backend. By default, they connect to your local environment, but you can configure them to inspect remote deployments:

```bash
# Inspect local workflows
npx workflow inspect runs

# Inspect remote workflows
npx workflow inspect runs --backend @workflow/world-postgres
```

Learn more about [Observability](/docs/observability) tools.