Deploy

klaridian deploy takes a server you already generated and emits the files a hosting platform needs to run it. It follows an emit + shell-out model: klaridian writes the platform's native configuration (a portable Dockerfile for --target docker) and you hand them to that platform's own CLI. klaridian never reimplements deploy infrastructure.

Deploy reconfigures nothing about the server itself — every structural decision (spec, transport, port, plugins, auth) was made at generation time. It only makes sense for a streamable-http server: a stdio server has no network endpoint to expose, so deploy refuses one.

Docker (the portable baseline)

klaridian deploy ./my-server --target docker

This writes a Dockerfile and .dockerignore into the project. The Dockerfile is vendor-neutral — it runs on Fly, Render, Railway, Cloud Run, or a self-hosted box. It's an ephemeral build input, not a maintained part of your generated project.

• TypeScript projects get a multi-stage build: npm run build produces a self-contained bundle, and the runtime image carries only that bundle on a slim Node base.
• Python projects get a slim Python image that installs requirements.txt and runs server.py.

Build and run it locally:

docker build -t my-server ./my-server
docker run -p 3000:3000 -e KLARIDIAN_BASE_URL=https://api.example.com my-server

Cloudflare Workers (the edge target)

klaridian deploy ./my-server --target cloudflare

This writes a worker.ts entry and a wrangler.toml manifest. The Worker reuses the same server factory the local server uses — the MCP SDK exposes a web-standard fetch handler, so the generated server runs on Cloudflare's edge runtime unchanged. Validate it with no account needed, then deploy:

cd ./my-server
npx wrangler deploy --dry-run   # compiles the Worker locally, no login
# set KLARIDIAN_BASE_URL in wrangler.toml, then:
npx wrangler deploy

wrangler.toml presets KLARIDIAN_ALLOWED_HOSTS to <name>.workers.dev — add your custom domain if you use one. This target is TypeScript-only: Cloudflare Workers runs JavaScript, so a Python project (or a code-mode server, which spawns a Deno sandbox) is refused — use --target docker for those.

Fly.io (one-command container deploy)

klaridian deploy ./my-server --target fly

This writes the Docker artifacts plus a fly.toml. Fly builds and runs the emitted Dockerfile, so this works for both TypeScript and Python projects. Deploy with Fly's CLI:

cd ./my-server
fly launch --copy-config --no-deploy   # claims a unique app name, updates fly.toml
fly secrets set KLARIDIAN_BASE_URL=https://api.example.com
fly deploy

fly.toml presets KLARIDIAN_ALLOWED_HOSTS to <app>.fly.dev, sets internal_port to the generated port, force_https, and scale-to-zero (min_machines_running = 0) so an idle server costs nothing. Update the host if you attach a custom domain.

Reaching the server once it's deployed

The generated server reads its runtime configuration from the environment (see Transports for the full table). Two matter most in a container:

• KLARIDIAN_BIND_HOST=0.0.0.0 — already set in the emitted Dockerfile, so the server binds all interfaces instead of loopback.
• KLARIDIAN_ALLOWED_HOSTS — set this at deploy time to your public hostname (for example myapp.fly.dev). Without it, requests routed through that hostname are rejected with 403 Invalid Host. The platform injects PORT; the server honors it automatically.

Options