Build cloud agents that work your way.

Bring the agent you already use.

Helmr runs your agent as ordinary code on a computer you define. No new inference API, no rewrite into a framework’s abstractions.

• Claude Code
• Codex
• OpenCode
• Pi
• Cursor
• AI SDK

Know exactly what your agent runs on.

The computer is defined in code: image, tools, resources, secrets and a prepare step. Nothing is configured behind a console, so what’s in the file is exactly what your agent gets — reviewable, versioned and the same for every session.

1import { template, image } from "@helmr/sdk"2 3export const workspace = template({4  id: "app",5  image: image("app")6    .from("node:24-bookworm")7    .run(["sh", "-c", "apt-get update && apt-get install -y ripgrep"]),8  resources: { cpu: 2, memory: "4GiB" },9 10  prepareSecrets: [{11    secret: "REGISTRY_TOKEN",12    env: { name: "REGISTRY_TOKEN", mode: "raw" },13  }],14  secrets: [{15    secret: "ANTHROPIC_API_KEY",16    env: {17      name: "ANTHROPIC_API_KEY",18      mode: "protected",19      allowedOrigins: ["https://api.anthropic.com"],20    },21  }],22 23  async prepare(build) {24    await build.exec(["git", "clone", "https://github.com/acme/app", "/app"])25    await build.exec(["npm", "ci"], { cwd: "/app" })26  },27})

Write agent work like a local script.

Start the coding agent you already use in init, then hand it each turn. Run it on a schedule or from a Slack thread. No workflow engine, and no rewriting your agent for someone else’s API.

1import { agent, triggers } from "@helmr/sdk"2import { createAgentSession, SessionManager } from "@earendil-works/pi-coding-agent"3import { workspace } from "./computer"4 5export const coder = agent({6  id: "coder",7  template: workspace,8 9  async init({ session }) {10    const { session: pi } = await createAgentSession({11      cwd: "/app",12      sessionManager: SessionManager.continueRecent(13        "/app",14        `/var/lib/helmr/pi/${session.id}`,15      ),16    })17    return pi18  },19 20  async turn(turn, { initResult: pi }) {21    turn.onCancel(() => pi.abort())22    await pi.prompt(turn.input.map(part => part.text).join(""))23    await turn.respond(pi.getLastAssistantText() ?? "")24    return { piSession: pi.sessionManager.getSessionId() }25  },26 27  triggers: [28    triggers.cron("weekday-deps", "0 9 * * 1-5", {29      timezone: "Asia/Tokyo",30      input: [{ type: "text", text: "Update dependencies." }],31    }),32  ],33})

Part of your team. Right in Slack.

Agents join your Slack like colleagues, whatever they run on. Mention one to give it work; it asks teammates for context, hands parts of the job to other agents, and reports back in the thread.

Durability you never think about.

There’s no checkpoint API, no state to serialize, no storage to manage. Memory, processes and files are saved outside the VM as your agent works, so it picks up where it left off, even on another machine, without repeating work or running init again.

Keep protected keys outside the agent.

Bind a secret as protected and the VM only ever holds a placeholder. Helmr swaps in the real value at the network boundary, only for origins you allow, and fails the request once the secret is revoked.

GET /repos/acme/app/pulls/482
Host: api.github.com
Authorization: Bearer hlmr_p_3f9c…e21a

GET /repos/acme/app/pulls/482
Host: api.github.com
Authorization: Bearer ghp_••••••••••••

POST /collect
Host: telemetry.example
Authorization: Bearer hlmr_p_3f9c…e21a

Scale on your own terms.

Helmr works out how many workers the queued work needs. Your scaler decides how to get them: which instances, which accounts, how fast and how far. Capacity grows with your organization under the policies you already run.

• Capacity you control

  Set the fleet’s minimum and maximum size, and bound optional preparation on each worker.

• Drain before removal

  A host leaves only after its work is saved or finished. If a host is lost, sessions resume elsewhere.

• Limits per environment

  Cap resident computers, CPU, memory, storage and admission rate, so one workload cannot take the fleet.

Run it on your own network.

Helmr runs in your AWS account with no public endpoint. Your team reaches the Console, CLI and API over your company network, Slack connects outbound, and Helmr’s own traffic leaves only through a proxy you control. Agents stay off your internal network.

Your teamcompany network

your AWS account · no public endpoint

• Console, CLI, APIinternal load balancer
• Control planesessions and audit
• Workersagents in microVMs

egress proxy · Helmr’s own traffic

• GitHubsign-in and repositories
• Slackoutbound connection

Enterprise-grade security, built in.

Control who and which agent can do what, down to a single agent. Every decision Helmr enforces is on record: who acted, what was checked, and what was refused, without your prompts or output ever entering the log.

• PeopleConsole, CLI, Slack
• Agentssessions and commands
• API keysCI and scripts
• Helmr itselfretention, recovery

one recordwho · what · why

• ✓Role granted to Ops teamAiko · allowed by Access Administrator
• ✓Command started on a computeragent demo-reporter · its own session
• ✕Read session contentSato · refused, no role gives it here
• ✓Deployment promotedkey ci-deploy · Deployer in Production

Open source. Infrastructure you control.

Early, open, Apache 2.0. Read the source before you trust it with your repositories, then run it where your work already lives.