> For the complete documentation index, see [llms.txt](/llms.txt).
> A full single-fetch corpus is available at [llms-full.txt](/llms-full.txt).
---
title: Serverless endpoints
description: Build, deploy, connect, and operate AGNT5 workflows on provider-managed HTTP runtimes without a persistent worker process.
last_verified: 2026-09-29
---

A **serverless endpoint** is an HTTPS deployment that serves an AGNT5 manifest and accepts signed invoke requests. AGNT5 routes workflow, function, tool, and agent runs to the endpoint while the provider owns the HTTP runtime, scaling, and deployment lifecycle.

AGNT5 owns the serverless protocol and durable execution contract. Your provider's CLI owns local emulation, authentication, deployment, and provider rollback.

## Start here


  - [Deploy to Cloudflare Workers](/docs/integrations/cloudflare-workers) — Create a new Worker, validate it locally, deploy it, sync it with AGNT5, and run the workflow.
  - [Compare serverless support](/docs/run/serverless-support-matrix) — Choose a tested runtime, provider scaffold, or framework compatibility path.
  - [Operate serverless endpoints](/docs/run/operate-serverless-endpoints) — Validate, sync, verify, activate, disable, rotate secrets, and roll back an endpoint.
  - [Serverless CLI reference](/docs/cli/serverless) — Look up every agnt5 serverless command, flag, alias, and side effect.


## Follow the deployment lifecycle

1. Add the AGNT5 protocol handler with **`agnt5 serverless init`**.
2. Develop locally with the provider CLI, such as **`wrangler dev`** or **`vercel dev`**.
3. Deploy with the provider CLI, such as **`wrangler deploy`** or **`vercel deploy`**.
4. Validate the deployed manifest with **`agnt5 serverless validate`**.
5. Import the immutable provider version with **`agnt5 serverless sync --activate=false`**.
6. Gate promotion with **`agnt5 serverless status --verify`**.
7. Activate the verified deployment and run its components through AGNT5.

The AGNT5 CLI does not wrap provider development or deployment commands. Provider bindings, preview environments, build behavior, and rollback remain visible in the provider-native tool.

## Understand the endpoint contract

Every serverless endpoint exposes two routes:

| Route | Purpose |
| --- | --- |
| `GET /.well-known/agnt5` | Returns the `workerless.v1` manifest and component declarations. |
| `POST /agnt5/invoke` | Receives signed AGNT5 invoke requests and returns a result or durable suspension. |

The endpoint and AGNT5 deployment share an HMAC signing secret. Generate the secret in a file that is private to your user:

```bash
( umask 077 && openssl rand -base64 32 > .agnt5-serverless-secret )
```

Set `AGNT5_SERVERLESS_SIGNING_SECRET` in the provider from this file, then pass the same value to **`agnt5 serverless sync`** through `--signing-secret-env` or an existing AGNT5 secret reference.

## Require signed invokes

AGNT5 requires a non-empty signing secret before activating or dispatching to a serverless deployment. This includes runs pinned to a deployment ID. `sync --activate=false` can import the manifest before you configure signing, but it does not enable unsigned dispatch.

Configure the same secret in the provider's SDK handler. The `AGNT5_SERVERLESS_SIGNING_SECRET` variable has no effect unless your handler reads it or a resolver returns it. A misspelled variable can leave the endpoint without a secret even when AGNT5 has one stored. Manifest validation checks discovery, not invoke authentication.


> Python 0.14.3, TypeScript 0.10.11, and Go v0.10.5 accept unsigned invokes when no signing secret is configured or its resolver returns empty. They emit no signing warning at startup. Anyone who can reach such an endpoint can invoke its exposed components directly, even if AGNT5 refuses activation or dispatch. Configure and validate the provider-side secret before exposing the endpoint.


The SDK signing-hardening update is currently unreleased. With that update, an omitted, empty, or whitespace-only secret returns HTTP `503` with `WORKERLESS_SIGNING_SECRET_REQUIRED` before executing user code. A configured secret requires valid signature headers; missing or invalid signatures return HTTP `401`. The manifest remains available without a signing secret so you can validate and register the endpoint.

For local development, that update adds an explicit opt-in:

| SDK | Handler option | Default |
| --- | --- | --- |
| Python | `serve(allow_unsigned=True)` | `False` |
| TypeScript | `serve({ allowUnsigned: true })` | `false` |
| Go | `serverless.New(serverless.Options{AllowUnsigned: true})` | `false` |

The opt-in permits unsigned invokes only when no secret resolves and logs a warning when the handler is created. It does not bypass verification of a configured secret or relax AGNT5's activation and dispatch requirements. Missing static secrets warn when the handler is created; a request-time resolver that returns empty warns on its first failed invoke. Keep the opt-in off on reachable deployments.

## Choose a host

| Host | SDK entrypoint | Public guide |
| --- | --- | --- |
| Cloudflare Workers | `@agnt5/sdk/serverless` | [Deploy to Cloudflare Workers](/docs/integrations/cloudflare-workers.md) |
| Vercel or Next.js | `@agnt5/sdk/serverless` or `agnt5.serverless` | [Deploy to Vercel](/docs/integrations/vercel-serverless.md) |
| Cloud Run | `agnt5.serverless` or Go `serverless` | [Deploy to Cloud Run](/docs/integrations/cloud-run-serverless.md) |
| AWS Lambda Web Adapter | `agnt5.serverless` | [Deploy to AWS Lambda](/docs/integrations/aws-lambda-serverless.md) |
| Generic Node.js | `@agnt5/sdk/serverless/node` | [Add AGNT5 to Node.js](/docs/integrations/node-serverless.md) |
| Python ASGI or WSGI | `agnt5.serverless` | [Integrate Python web frameworks](/docs/integrations/python-web-frameworks.md) |
| Go `net/http` | `github.com/agnt5dev/sdk-go/serverless` | [Build a serverless endpoint in Go](/docs/integrations/go-serverless.md) |
| Deno or Hono | `@agnt5/sdk/serverless` | Use the host adapter that preserves the original `Request`. |

Cloudflare Workers, Vercel, Cloud Run, and AWS Lambda have provider-specific lifecycle guidance. Generic Node.js, Python, and Go services use the `http` provider label during sync.

## Know the beta limits

Serverless endpoints support signed dispatch, immutable manifest sync, encrypted signing-secret references, component route ownership, durable step checkpoints, timeout suspension, retries, concurrency, throttling, rate limits, debounce, priority, singleton keys, and idempotency metadata.

Batch declarations are rejected during the serverless beta because aggregate batching enforcement is not available. Keep batch policies on persistent workers.

Workflow state is not durable on serverless endpoints. The Python and TypeScript serverless contexts back `ctx.get()`, `ctx.set()`, and `ctx.delete()` with a per-invocation map that is never checkpointed, so it is lost across every suspension, and the Go `serverless` package has no state API. When you move a workflow from a persistent worker to a serverless endpoint, keep cross-suspension state in `ctx.step()` results.

Serverless dispatch must be enabled for your AGNT5 workspace. If endpoint validation succeeds but sync reports that serverless execution is unavailable, contact your AGNT5 workspace operator.

## Next steps

- [Deploy to Cloudflare Workers](/docs/integrations/cloudflare-workers.md): complete the first public end-to-end serverless path.
- [Serverless support matrix](/docs/run/serverless-support-matrix.md): compare test evidence and remaining gaps.
- [Deploy to Cloud Run](/docs/integrations/cloud-run-serverless.md): run Python or Go on an immutable Cloud Run revision.
- [Operate serverless endpoints](/docs/run/operate-serverless-endpoints.md): promote and recover immutable provider deployments safely.
- [Serverless CLI reference](/docs/cli/serverless.md): inspect all serverless commands and flags.