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?
cvolante 1 days ago [-]
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?
gustrigos 1 days ago [-]
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.
1 days ago [-]
18 hours ago [-]
mritchie712 1 days ago [-]
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.
gustrigos 1 days ago [-]
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.
adi4213 3 hours ago [-]
Can you provide some info on how to use the max plan / ChatGPT pro subscription via OAuth? I was about to subscribe but wasn't entirely sure how to configure that
vorsken 23 hours ago [-]
Interesting approach to sandboxing. One thing I've been thinking about in this space: even with sandboxed execution, the generated code still needs to pass security policy checks before it merges.
Static analysis catches a different class of issues than runtime sandboxing — they seem complementary rather than competing.
cvolante 22 hours ago [-]
I agree, I do see static analysis and runtime sandbox as complementary tools. Do you see static analysis tools performed by the agent itself inside the sandbox or via CI tools in the pull request itself (like github actions or buildkite)?
murat124 8 hours ago [-]
you don't need AI to find out that the hard-capped concurrent request limit of 10 was the root cause. but you do need an AI to find it for you so you can joke about giving it a raise.
cadr 8 hours ago [-]
Very cool.
Just fyi, the GitHub links to some of the docs (like self-hosting) give 404, as do some of the internal links in the docs.
gustrigos 2 hours ago [-]
Thanks for letting us know! Got a PR for the fix.
killerstorm 1 days ago [-]
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.
gustrigos 1 days ago [-]
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.
1 days ago [-]
manuel_angel 16 hours ago [-]
Congrats, amazing product!!
How are guardrails set in a sandbox? Once I create my setup, is there a way to customize it per team?
For example: I want to setup a different setup for my marketing vs my data team.
gustrigos 2 hours ago [-]
Thanks. Yes, we you can set up guardrails for specific teams by creating templates that only certain teams have access too. We are adding a profile feature that will let you have more control of this, but it is something that we have high on our priorities to build!
yakkomajuri 23 hours ago [-]
Congrats on the launch!
Tiny bit of feedback on the demo video: the beginning makes me dizzy and I'm not sure what's going on (was watching on my phone).
gustrigos 22 hours ago [-]
Thanks! The demo is not the best we have. Probably did a lot of zooming in and zooming out.
agcat 1 days ago [-]
This is amazing, what was the inspiration?
gustrigos 1 days ago [-]
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...
Curosinono 12 hours ago [-]
Your Video is stressing me out.
Srlsy.
Its too fast, its too jumpy
gustrigos 2 hours ago [-]
I know... we need to improve the demo!
discardable_dan 19 hours ago [-]
Tonka seems better equipped and free…
gustrigos 2 hours ago [-]
the truck toy company?
zuzululu 1 days ago [-]
Checked license it said copyrighted which makes this unsuable for me.
my question is what advantage does this have over real FOSS agentic sandboxes
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.
gustrigos 1 days ago [-]
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.
- 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.
cvolante 1 days ago [-]
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?
theahura 1 days ago [-]
we're on fly, going to add modal support soon. I dont think our users care all that much, but we care for dev ergonomics.
keys are tricky. We don't have a great answer. I mean the proxy inject works well enough for mcp, but there is just such a long tail of tools that do something like 'read a key from disk and encrypt it before sending it out' which makes proxy management just a pain
immanuwell 12 hours ago [-]
[flagged]
Rendered at 19:56:04 GMT+0000 (Coordinated Universal Time) with Vercel.
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?
If someone from Anthropic sees this, would love to know if I can use my max plan here.
Just fyi, the GitHub links to some of the docs (like self-hosting) give 404, as do some of the internal links in the docs.
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.
For example: I want to setup a different setup for my marketing vs my data team.
Tiny bit of feedback on the demo video: the beginning makes me dizzy and I'm not sure what's going on (was watching on my phone).
Srlsy.
Its too fast, its too jumpy
my question is what advantage does this have over real FOSS agentic sandboxes
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.
But beyond that, we are managing a higher level abstraction than sandboxes.
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.
Curious about what sandbox provider you use to power Nori and how you are handling the secrets/keys issue?
keys are tricky. We don't have a great answer. I mean the proxy inject works well enough for mcp, but there is just such a long tail of tools that do something like 'read a key from disk and encrypt it before sending it out' which makes proxy management just a pain