> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nelkap.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vercel

> Deploy your workflows on Vercel: keep runs going after the response, give long steps the time they need, and test them on preview deployments.

Vercel runs your routes as functions that stop shortly after they answer. Since `handle` answers Nelkap before the workflow runs, three settings make sure your runs get the time they need.

## Keep the work going after the response

Pass Vercel's `waitUntil` to `handle`, so the function keeps running until the workflow's call ends. In Next.js, use [`after`](https://nextjs.org/docs/app/api-reference/functions/after):

```ts app/api/nelkap/route.ts theme={"theme":{"light":"light-plus","dark":"dark-plus"}}
import { after } from 'next/server';

import { nelkap } from '@/lib/nelkap';

export async function POST(request: Request) {
  return nelkap.handle(request, {
    waitUntil: (promise) => after(() => promise),
  });
}
```

In other frameworks, use [`waitUntil`](https://vercel.com/docs/functions/functions-api-reference/vercel-functions-package#waituntil) from `@vercel/functions`. Each [framework page](https://docs.nelkap.com/frameworks/overview.md) shows the exact route.

## Give long steps the time they need

A function on Vercel runs for a limited time, set by your plan and by the route's `maxDuration`. When a call reaches that limit, the steps already saved are kept, and Nelkap calls your app again about five minutes later to go on from there. So a long run is fine: it simply takes several calls.

A single step, though, must finish within one call. If a step can take longer than the default, raise the route's limit, in seconds, within what your plan allows:

```ts app/api/nelkap/route.ts theme={"theme":{"light":"light-plus","dark":"dark-plus"}}
export const maxDuration = 300;
```

See [Vercel's function durations](https://vercel.com/docs/functions/configuring-functions/duration) for the limits of each plan.

## Set your environment variables

Add `NELKAP_API_KEY` and `NELKAP_SECRET` to your Vercel project's environment variables, for each environment that runs workflows. Vercel applies them to the next deployment, so deploy again after adding them.

## Production

Set your production project's endpoint to your production domain, like `https://your-app.com/api/nelkap`. A custom domain stays the same from one deployment to the next, so the endpoint never needs to change.

## Preview deployments

Every preview deployment gets its own URL, but a Nelkap project has a single endpoint. To run workflows on previews, give them a project of their own, like a staging project:

1. Create a staging project in your workspace.
2. Set its endpoint to the URL of the branch you deploy for testing, like `https://your-app-git-staging-your-team.vercel.app/api/nelkap`. That URL always points to the branch's latest deployment.
3. Add the staging project's API key and secret to your Vercel project's Preview environment.

See [Staging and production](https://docs.nelkap.com/deploy/environments.md) for how to keep the two apart.

### Deployment Protection

When [Deployment Protection](https://vercel.com/docs/deployment-protection) covers your previews, Vercel turns Nelkap's calls away too, since they come without a sign-in. To let them through, create a secret under [Protection Bypass for Automation](https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation) in your Vercel project, and add it to the end of your staging endpoint, as `?x-vercel-protection-bypass=your-bypass-secret`.

Nelkap calls the URL exactly as you set it, so the secret travels with every call.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.