Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

161–170 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#161

For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand. This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.

stop-on-idle + wake-on-HTTP https://github.com/tastyeffectco/sandboxd/

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#162
post #75
post #50

Earlier quoted context omitted.

Def! My personal belief is that the future of an "app" is a combo: 1. micro VM 2. agent on the VM 3. software bundled into the VM So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/ ), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

Microsandbox claims to start faster than docker, and it is isolated from the host, and to work with OCI. Why would I still want to use docker? The only reason I can imagine is that I actually want to be able to dynamically share resources between containers instead of dividing up VMs a priori. Ah, the significant compute overhead: https://josecastillolema.github.io/podman-wasm-libkrun/ . Much more cpu and ram usage a…

> dynamically share resources

This has been a big pain point me with various VM solutions I’ve tried. Having to allocate say 8GB to a sandbox, and a) having that RAM eaten up when I’m not using it and b) only having 8GB when I am using kinda sucks.

Yes, I could stop the sandboxes when I’m not using them, but that also kinda sucks.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#163
post #50

Earlier quoted context omitted.

Setting up your own is not that hard and if you bought some compute before the Altman squeeze, very cheap.

Def! My personal belief is that the future of an "app" is a combo: 1. micro VM 2. agent on the VM 3. software bundled into the VM So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/ ), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

I am building this.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#164
post #50

Earlier quoted context omitted.

Def! My personal belief is that the future of an "app" is a combo: 1. micro VM 2. agent on the VM 3. software bundled into the VM So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/ ), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

You basically described exe.dev

exe.dev is great, but the VMs are not really "apps". They are durable computers / VMs.

An example of a "sandboxed agent app", would be: give the app all your past emails. An agent scans them and finds sales emails you need to follow up on. It shows you the suggested follow ups in a UI, and you approve/reject them. Then, it mass sends the approved emails and emits an update to your CRM with the changes.

The sandbox is deleted when the app runs. It's ephemeral for the lifecycle of the app. And you can re-run the same app repeatedly with new inputs, but it gets the same clean starting slate.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#165
post #154

Earlier quoted context omitted.

Lots of people want limits. They might make sense for something like Sprites, where the end-users are often (but not always) individual developers. They're terrible for hosting fixed-function applications. The real gotcha is having limits, because that's the host effectively taking your app down for you. I know talk is cheap, but I've been in the room for every one of these discussions over the last 6 years at Fly.io…

Why is it that you claim limits are unworkable? If you can track or enforce it (others have been for years) then couldn't you make it an optional field or checkbox?

Every limit is a commanded outage. We can refund an unexpectedly high bill. We can't refund downtime.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#166

For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand. This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.

I'm a relatively basic claude code user, basically just running a few instances in different terminal tabs and monitoring them pretty closely, but I could definitely see value in being able to dump a bunch of code and tools into a workspace where there's no credentials present and just set an agent some goals to research or try a bunch of things in a mostly unsupervised manner.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#167
post #51

We have this page which compares a whole bunch of sandbox providers in different categories https://engine.build/lab/agent-sandboxes Will add MicroVMs there today (and any others that are missing if you let me know!)

Would love to see sandboxd added — it's the self-hosted open-source option with Docker hardening, built-in coding agents (Claude Code, OpenCode), and live preview URLs. https://github.com/tastyeffectco/sandboxd

I'll add it! I like your website by the way, something satisfying about the design.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#168

Earlier quoted context omitted.

I don't think it's that complicated, but yeah, it's not as simple as $X/month. The primary difference is that with Lambda you pay by the second, not by the month. According to my math, the break-even point for a 8GB allocation (the minimum exe.dev supplies) would be about 1.65 days of continuous runtime. Less than that, and you're better off with Lambda. More than that, and you're better off with exe.dev (assuming we…

I’m running a web server in a VM and I use it every day. It’s mostly idle, but it’s continually available. I wonder how much “continuous runtime” that is?

The stopwatch starts when a request arrives and stops after your processor sends the response. You’re not charged for idle time. For low-demand services, it’s a bargain. The tradeoff is a bit of extra latency for cold starts (i.e. when a request hasn’t been processed in a while). Nowhere near a full classic VM launch though—typically under a second.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#169
post #18

What's the best provider to self-host Firecracker? I feel that AWS is not a safe or cost-effective option for a self-funded startup or small business. Although is anything cost effective anymore? Hetzner just had a massive price hike. Part of it might just be that I am old and inflation is catching up with my understanding of prices. But as far as AWS I still have to say no thanks. Imagine some group actually started…

I just went with qemu and run it in my own machine. It is portable so you run it on other OSes which is handy when everything is under the same desktop app. But I was after better isolation and the ability to be fully in control of the agent environment to pair with local llms. As soon as you lift it to some managed environment it becomes hard to justify all of the necessary steps to manage connections, encryption etc., eg passing credentials for access to other resources.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#170

For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand. This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.

I'm a relatively basic claude code user, basically just running a few instances in different terminal tabs and monitoring them pretty closely, but I could definitely see value in being able to dump a bunch of code and tools into a workspace where there's no credentials present and just set an agent some goals to research or try a bunch of things in a mostly unsupervised manner.

I think it’s worth trying. There’s a lot of value in having the agent in the box. You can give it root so it can do something like tcpdump unsupervised. And if you happen to build a new server, you can keep it serving indefinitely. That’s the whole motivation behind exe.dev.
Post reply on HN