But beyond that, we are managing a higher level abstraction than sandboxes.

After Mentum (YC S21) was acquired, I personally shipped 4 full-stack products in 3 months using coding agents. When I tried to roll the same workflow out to the rest of the team, it fell apart: Most PRs were unmergeable slop - Every repo required an engineer doing one-off local setup. - Skills and context lived in one person's head. - There was no safe way for a PM to touch a real codebase without risking a bad deploy or a secrets leak.

Carlos comes from building agentic reconciliation systems at Modern Treasury and had a similar experience when letting his support team use devin.

We ended up building internal background agent infra but it quickly became a nightmare to mantain and develop. We built Runtime so you don't have to do this kind of thing.

Runtime work like as follows. Engineering defines the context once: system instructions, skills, and scoped integrations installable via CLI, mise, npm, or any package manager. Then Runtime snapshots your full running environment including multi-service Docker Compose setups, Kafka, Redis, seeded DBs, so it comes up in milliseconds with every server already running.

We orchestrate across sandbox providers like E2B, Daytona, EC2 or self-hosted K8s depending on your setup. Secrets are injected through our managed proxy so they never touch the agent directly, and guardrails run at the infrastructure level: command allow/deny lists, network egress controls, and RBAC scoped per human and per agent. Every session also gets a shareable preview URL, so internal builds go from sandbox to the rest of the team without needing production access.

Runtime works with whichever agent your team already uses: Claude Code, Codex, Cursor, Copilot, Gemini, Devin. You can trigger sandboxes from our web app, CLI, Slack, Linear, GitHub, or API.

One of our customers built an on-call inspector that wires PagerDuty, Sentry, and their repo so when an alert fires, the agent finds the cause and opens a PR with a unit test before anyone gets paged. Another runs a finance agent in a private Slack channel pulling from Stripe, NetSuite, and Snowflake to run reconciliations in minutes with source rows attached.

A fintech unicorn and several YC scaleups are live on Runtime, including a few teams who had built similar infrastructure internally and handed it to us to take over.

The core is open source at https://github.com/runtm-ai/runtm. Hosted version is live at https://app.runtm.com, free tier included. We're charging a flat platform fee plus compute, no token markup.

Check our demo: https://www.youtube.com/watch?v=wLwj__aEEh4

We'd love to hear how you're thinking about the infra for letting more people across your org use coding agents without creating chaos!

Comments URL: https://news.ycombinator.com/item?id=48225040

Points: 103

# Comments: 30

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://.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.

Comments URL: https://news.ycombinator.com/item?id=46470702

Points: 4

# Comments: 1