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:
uv tool install runtm
runtm login
runtm init backend-service
# prompt agent to write code
runtm deploy
# URL generated at https://<app>.runtm.com
runtm logs
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:
name: my-api
template: backend-service
runtime: python
env_schema:
- name: DATABASE_URL
secret: true
required: true
Guardrails:
Agents can propose capabilities; humans approve them.
An agent writes a runtm.requests.yaml like:
I need a database
I need STRIPE_KEY
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.