A relay station with a lattice tower and a dish on an asteroid ridge. A lone astronaut stands at the edge, looking out at a dark planet and a field of asteroids under a distant sun.

30–50 AU from the noise

Durable agents,
deployed at the edge.

Managed deployment for Glove and Foundry projects. Station services run alongside them, and agent sandboxes run isolated under gVisor.

kuiper deploy --source .

01Deploy

From a directory to a live URL in one command.

Point the CLI at your source. Kuiper packs it, detects the framework, builds an image, places the unit on a node and waits until it is healthy. Push to a linked repository and the same thing happens on its own.

  • DetectsFoundry · Station · Node · Dockerfile
  • Deploys byimage digest, so rollbacks are exact
  • Serves athttps://<name>.kiprsh.app
~/proxima-agent live 
$ kuiper deploy -p proxima -u agent --source . --wait
uploading 212 files (388 KiB) as proxima-agent@9dddc61
build bld_4k2m9q7x1r8c queued
build bld_4k2m9q7x1r8c of proxima/agent @ proxima-agent@9dddc61
unpacked upload 4be0c2d9a1f7: 212 files, 1476 KiB
no Dockerfile found; generating one for a Foundry project (Npm { lockfile: true }, with the docker CLI for Station's container backends)
#9 [build 5/6] RUN npm ci
#14 pushing layers
kuiper.json ok: 1 port(s), request 0.5 vCPU / 1024 MiB
built …/proxima/agent@sha256:5f1c09e27a4b
deploying · placement scheduled · pulling
deploying · placement scheduled · starting
live · placement running · running
live ✓
$ kuiper status -u agent
unit      agent
status    running
hostname  https://proxima.kiprsh.app

02What runs on Kuiper

Built for agents that wait, then work.

Glove Foundry and Station run with no Dockerfile and no kuiper.json in the repository. The builder recognises them and fills in the rest.

  • Foundry agents

    Durable agents that survive restarts, long waits and approvals. Instances persist between turns, and schedules keep firing while nobody is watching.

    foundry.config.ts → port 4141

  • Station services

    Retryable jobs, dependency graphs, supervised processes and schedules. Station’s container sandboxes and browsers work unchanged.

    station.config.ts → port 4400

  • Sandboxes

    Agents start isolated containers on demand through a scoped runtime API. Each runs under gVisor inside the unit’s own limits, and no tenant touches the host’s Docker.

    capabilities.sandbox.maxConcurrent

  • Anything with a Dockerfile

    Bring a Dockerfile, or any Node app with a start script, plus a kuiper.json that names its port. It runs like every other unit.

    Dockerfile + kuiper.json

03Platform

Everything a deployment platform should do, for agents.

  • Git and source deploys

    Connect a repository through the GitHub App and every push builds and deploys. No repository? Upload a directory from the CLI or the dashboard.

    kuiper deploy --source .

  • HTTPS and custom domains

    Every public port gets a hostname with a valid certificate. Add your own domain and TLS is issued for it automatically.

    <name>.kiprsh.app

  • Environment and secrets

    Name variables freely; values are templates. Secrets are encrypted and write-only, and never appear in the API, the dashboard or logs.

    KEY=${{secrets.NAME}}

  • Durable volumes

    A project-owned volume, mounted at /data, that outlives restarts and redeploys. Agent state stays where you left it.

    "volumeGiB": 10

  • Logs and deployments

    Live logs, retained across crashes and redeploys, with secrets redacted. Every deployment is recorded, and a rollback is one command.

    kuiper logs -f

  • Resources per unit

    Reserve CPU and memory for each unit and set a hard ceiling. Requests drive placement; limits are enforced by cgroups.

    request 1 vCPU · limit 2 vCPU

  • Isolation

    Agent sandboxes run under gVisor. Units reach the node only through a scoped runtime API, one Unix socket per unit; no tenant touches the host’s Docker.

    runtime: runsc

  • CLI and dashboard

    The kuiper CLI for macOS and Linux, and a web dashboard for projects, units, logs and settings.

    app.kuiper.sh

04How it works

Three steps, then it keeps running.

  1. 01

    Connect your source

    Link a GitHub repository through the Kuiper GitHub App, or deploy any directory straight from your machine.

    kuiper deploy --source .

  2. 02

    Kuiper builds it and places it

    The builder detects Foundry, Station or Node, or uses your Dockerfile. The scheduler puts the unit on a node with room for its request.

    # framework: Foundry

  3. 03

    It keeps running

    Crashed processes restart, the volume survives redeploys, and HTTPS stays valid. Agents resume where the last turn ended.

    live ✓

05In production

We run our own agents on Kuiper.

One of them is a personal agent on Telegram, built on Foundry. It writes code with parallel Codex sessions in sandboxes, browses the web, and makes images, voice and music. It ships with the same kuiper deploy you would use.

  • Foundry
  • sandbox × 2
  • gVisor
  • volume 20 GiB
  • request 0.5 vCPU / 1024 MiB

06Early access

Request early access.

We are opening Kuiper to a small number of teams at a time. Tell us what you are building and we will be in touch.