Hey HN, We're Gus and Carlos from Runtime (https://runtm.com). We're building infra that lets your whole team (including non-engineers) ship with Claude Code, Codex, and other agents without engineering having to handhold every session.
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!
Checked license it said copyrighted which makes this unsuable for me.
my question is what advantage does this have over real FOSS agentic sandboxes
I wrote a simpler version of this for Claude Code as open source if that's useful to you: https://github.com/smithy-ai/smithy-ai
It's doing context management in the same way, but adds a learning loop based on code reviews. Currently works with Gitlab, Forgejo and Gitea but happy to accept a PR for Github support or co-write it.
We're using a split license: apache-2.0 for the CLI/SDK/sandbox, MIT for templates, AGPLv3 for server components. Not copyrighted.
But beyond that, we are managing a higher level abstraction than sandboxes.
Hi, this looks really powerful, in that it seems to have many use cases.
One question I had:
Does every sandbox change end (when ready for production) in a pull request? If marketing sends me a pull request and I hate the code, what's the flow like for me to fix it?
The sandbox’s lifecycle is independent of the PR so that the same user or someone else in your team, like an engineer can come back to the same session and keep building until the result is ready to merge. So you can choose to iterate on the first drafts on the same sandbox. Curious, what flow you envision in your case?
Thanks! Lots of use cases. For the workflow you mentioned, the idea is marketing sends you a PR with the live preview. You can see the UI changes and if you need to change anything, you can open the session, which will let you modify, backtrack, or continue their work inside the same sandbox they used.
I have a suggestion - an assistant which can help to set up all these agents, perhaps based on templates. You already covered various use cases, but it's not clear if it's something concrete.
I think a lot of people who might be interested in this product might be interested in an easy set-up process. Even if it doesn't really save time for an experienced ops person, a lot of people would rather talk to a bot than fill a form.
Good point. We launched our cli recently exactly for this. It comes with skills, so you can use your own local setup (Claude Code, Cursor, Codex), to build up templates, spin up sessions, and set things up. You can scope what agents can and can't do. I wouldn't recommend using an agent to set up guardrails. There should be some human oversight for this.
This is amazing, what was the inspiration?
thanks! we used to build a lot of internal software / scripts for conferences or one-off data crunching. We saw LLMs getting better and how the world would go from building software for localhost to needing it to deploy. I then wrote an essay about my thoughts as software goes to zero back in January. https://www.gustrigos.com/essays/on-abundant-ephemeral-softw...
I wonder how this would be looked upon by the ever changing rules of claude code.
If someone from Anthropic sees this, would love to know if I can use my max plan here.
all of our customers are using Anthropic APIs for programmatic use. Codex and other providers let you use Oauth. But inside of a sandbox, you can technically use max plan since it is the same as using Claude locally.
Really cool! We're working on something similar over at https://norisessions.com/
A few questions
- you mention proxying keys. One issue that we run into is that there are a bunch of tools that are really useful but require keys to be on disk (e.g. aws cli -- yes yes you can do IAM permissions but still). How do you guys think about those? (Especially since your setup onboarding is 'just install from npm or mise')
- poking around on the github, saw that you guys were at one point on fly.io. Did you guys end up switching off them? What motivated that if so?
- the CLI integration is cool! Is that actually teleporting remote sessions down to a local machine? Or is it more a window into the remote sandboxes?
would love to share notes! If you want to get in touch separately feel free at amol at noriagentic dot com.
Nori looks really cool, will set up sometime to exchange notes. But with regards to your questions: - Proxying keys: We allow users to setup keys in the sandbox and use CLIs for some cases but we also support an egress gateway that intercepts and injects keys on the way out, which supports the major api integrations we offer. - We still allow fly.io for deployments (so after a sandbox has a final app, you can deploy it and move out of the ephemeral sandbox). We never used them for sandboxing, but we will integrate into https://sprites.dev/ soon. - For the CLI, we allow you to SSH into the remote sandox since a lot of workload add too much stress to local machines
Curious about what sandbox provider you use to power Nori and how you are handling the secrets/keys issue?