genhttp/lambda repository overview

⁠GenHTTP Lambda

Website: GenHTTP Lambda Community⁠

Coding agents such as Claude Code, Codex and Cursor can write a small web app in minutes. Deploying it usually takes far longer: a container, a port, a reverse proxy entry, a database and backups, repeated for every new app. GenHTTP Lambda gives these apps a single home on your own server. Once your agent is connected, every app it builds is online at its own address within seconds, with a database, a version history and rollback. You operate one container.

docker run -d -p 8080:8080 -v lambda-data:/data -e LAMBDA_ADMIN_TOKEN=secure-password genhttp/lambda

Then open http://localhost:8080⁠.

⁠Why GenHTTP Lambda

• A single container. No database server, Redis, message queue or Kubernetes is required. The server, all apps and their data run in one container and are stored in one volume, so a backup is a copy of that volume.
• Hundreds of apps per installation. All apps run in the same process, each at its own address, without a separate container, port, proxy entry or database server. genhttp.dev⁠, which runs the same code, hosts more than a hundred apps this way.
• Deployment is handled by your agent. Any agent that supports MCP can create an app, write and check its code, test a change on a copy, publish it and read its logs, without you having to open a terminal.
• You stay in control. Every app has an editor that shows what changed and why, restores any earlier version in one click, and gives you access to its records, its visitors and its code.

⁠Use cases

GenHTTP Lambda is designed for small apps that often go unhosted because deploying them takes more effort than writing them:

• a chore list for a family, a booking page for a club, a sign-up sheet for a team;
• a dashboard for an API you use, a webhook receiver for your automations, a small API for your scripts;
• an event page, a guestbook, a poll, a multiplayer game.

A request such as "Build a shared task list for the team" produces an app that is online. A follow-up such as "Give every task the day it is due" is tested in a draft before it goes live.

⁠What every app gets

• An address below /lambda/ on your server or at a subdomain of its own, and a custom domain once the app is made premium in the panel.
• Data that is independent of versions: a SQLite database for records, a folder for saved files, and secrets for the API keys and passwords of the services it uses. Secret values are entered in the editor; the agent only ever sees their names.
• Drafts and versions: a change is tested in a draft with a copy of the data and then published, and earlier versions remain available for rollback.
• Git: every app is a repository. Pushing a commit to main saves a version, and pushing a branch starts a draft.
• Analytics and logs: page views, referrers and countries once enabled, and the app's output for each request.
• No lock-in: any app can be downloaded as a standard .NET project and run anywhere else. Nothing ties it to this server.

Under the hood, every app is a small C# program, a [GenHTTP][genhttp] handler, which the server compiles and starts within seconds. Writing one by hand is optional:

return Inline.Create()
             .Get(() => "Hello from my app!");

⁠Running it

docker run -d --name lambda -p 8080:8080 -v lambda-data:/data \
  -e LAMBDA_PUBLIC_URL=https://lambda.example.com \
  -e LAMBDA_ADMIN_TOKEN=a-long-password \
  genhttp/lambda

• One container, one port, one volume. No other services are required: the platform's data and every app's database are SQLite files in /data.
• LAMBDA_PUBLIC_URL is the address at which you and your agents reach the server, and the apps' addresses are derived from it. If it is not set, the server answers at any host name and the addresses use http://localhost:8080.
• LAMBDA_ADMIN_TOKEN is the password for the administration panel at /admin. If it is not set, the panel is disabled.
• Images are published for amd64 and arm64.

The sample in samples/community⁠ provides the same setup with Docker Compose and can optionally include the build agent:

cd samples/community
cp .env.example .env     # set at least LAMBDA_ADMIN_TOKEN
docker compose up -d

⁠Configuration

Further settings, covering limits, logging, TLS and analytics, are described in the reference⁠.

⁠HTTPS

The image serves plain HTTP on port 8080. Place it behind your existing reverse proxy, such as Caddy, nginx or Traefik, with a single entry for the whole server, and set LAMBDA_PUBLIC_URL to the https:// address. The server can also serve TLS itself; the reference describes how.

⁠Data and backups

The installation stores all of its data in the volume at /data: its database, every version of every app, the apps' records and files, their git history, and secrets.key, the key the apps' secrets are encrypted with. Back up the entire volume, including secrets.key. Without that file, the stored secrets cannot be decrypted.

⁠Updating

docker pull genhttp/lambda
docker compose up -d     # or: docker rm -f lambda, then run it again

The database is migrated when the server starts. Apps and their data are left unchanged.

⁠Connecting an agent

The front page explains how to connect each agent. For Claude Code, a single command is sufficient:

claude mcp add --transport http genhttp http://localhost:8080/mcp

Other agents can add a remote MCP server at http://localhost:8080/mcp (the value of LAMBDA_PUBLIC_URL followed by /mcp).

You can then describe what you need, for example "Build a guestbook, with a page where I approve the entries." The agent creates the app, publishes it and returns its address and its editor link. Store the editor link safely: it grants full control over the app and cannot be recovered.

Agents that can make HTTP requests or use git can work that way instead: the REST API is documented at /api/v1/scalar/, and each app's git address is shown in its editor.

⁠Building apps from a description: the build agent (optional)

With the build agent enabled, the front page offers an input box: people describe the app they want, and an agent on your server writes it, publishes it and returns a link for changing it. No coding agent of their own is required. The build agent is optional and is the only part of the setup that runs outside the main container. It requires:

• a Claude subscription, with a token created by claude setup-token;
• Docker on the same machine: for every build, the agent starts a short-lived container that can reach only this server and Anthropic.

In samples/community/.env, set CLAUDE_CODE_OAUTH_TOKEN, a random LAMBDA_AGENT_TOKEN (openssl rand -hex 32), LAMBDA_AGENT_URL=http://agent:8401 and DOCKER_GID (getent group docker | cut -d: -f3), then start it:

docker compose --profile agent up -d

⁠Security and operations

• Apps share the platform's address. Below /lambda/, an app runs on the same origin as the editor and the administration panel, so its pages could read what those store in your browser. The editor does not send its address to apps, and the panel keeps its password for the current tab only, but this setup is intended for apps built by you and your team. To host apps for people you do not know, give the installation a separate domain for them (LAMBDA_HOSTING_URL); each app is then a site of its own.
• Apps run inside the server process. This is what makes hosting hundreds of them inexpensive. Their code is checked for prohibited operations before it runs, but it shares the server's process: this is not a sandbox. Only run code you would be prepared to run yourself.
• Connecting to other servers requires approval. An app's code may connect to other servers, for example to call an API, open a socket or send email, only once you have allowed it in the panel's Connectivity section, where its owner's request is listed together with its purpose. Premium apps may connect without approval. Without this rule, anybody could route their traffic through your server with an app that fetches whatever address it is given. Pages that fetch from other sites in the browser need no approval, and agents are instructed to use that approach wherever possible.
• Unused apps are taken offline. A new app is free: by default, one that is neither visited nor changed for 30 days is taken offline, and removed 90 days after that. Making an app premium in the panel exempts it; how long free apps last can be changed under Limits.