runtm is an open-source runtime + control plane for agent-written software.
It works with any AI IDE / CLI (Cursor, Claude Code, etc.), and is built around a simple belief:
If code is cheap, deployment shouldn’t be sacred.
As agents generate more software, the bottleneck stops being writing code and becomes safely turning intent into something live, observable, and disposable, without humans babysitting infra.
runtm keeps the agent loop tight:
generate → deploy → observe → adjust → repeat
Agents can redeploy repeatedly, using real production feedback, until the objective is achieved.
Validation before deploy, so failures surface before you ship a broken container.
Guardrails:
Agents can propose capabilities; humans approve them.
An agent writes a runtm.requests.yaml like:
I need a database
I need STRIPE_KEY
A human runs runtm approve.
Secrets live in .env.local, which is auto-added to .*ignore.
The agent cannot read them. Secrets are injected only at deploy time.
Infra (today):
Deploys to Fly.io Machines (Firecracker, auto-stop for cost control).
Zero-config persistence via SQLite on a volume, or BYO Postgres.
Provider layer is swappable (Cloud Run / AWS next).
Observability:
Logs, traces, and metrics via OTLP.
We treat time from code to live URL as a first-class metric.
gustrigos•1mo ago
runtm is an open-source runtime + control plane for agent-written software. It works with any AI IDE / CLI (Cursor, Claude Code, etc.), and is built around a simple belief:
If code is cheap, deployment shouldn’t be sacred.
As agents generate more software, the bottleneck stops being writing code and becomes safely turning intent into something live, observable, and disposable, without humans babysitting infra.
runtm keeps the agent loop tight:
generate → deploy → observe → adjust → repeat
Agents can redeploy repeatedly, using real production feedback, until the objective is achieved.
Quick taste:
What it is:A small set of lifecycle primitives: init, run, validate, deploy, destroy.
Opinionated templates with a stable deployment contract so agents don’t guess what prod looks like:
Validation before deploy, so failures surface before you ship a broken container.Guardrails:
Agents can propose capabilities; humans approve them.
An agent writes a runtm.requests.yaml like:
A human runs runtm approve.Secrets live in .env.local, which is auto-added to .*ignore. The agent cannot read them. Secrets are injected only at deploy time.
Infra (today):
Deploys to Fly.io Machines (Firecracker, auto-stop for cost control). Zero-config persistence via SQLite on a volume, or BYO Postgres. Provider layer is swappable (Cloud Run / AWS next).
Observability:
Logs, traces, and metrics via OTLP. We treat time from code to live URL as a first-class metric.
Links:
Repo: https://github.com/runtm-ai/runtm Site: https://runtm.com Quickstart: https://github.com/runtm-ai/runtm#quickstart
Question:
What is the single capability you would never allow an autonomous agent to approve on its own?
Curious where people draw the line.