Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

Post reply on HN
Print view View original

171–180 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#171

Post by sublimefire »

crawshaw wrote: post #71

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.

Yeah I have some stuff which is supposed to be “there” for months with the agents continually moving it forward. Not to mention the need to run different software. Running local VMs for now.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#172

Post by tough »

dbmikus wrote: post #50
PeterStuer wrote: post #43

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

heh I vibe-coded a little local app to have smolmachines and tart, for smolmachines i had to vibe-fork 2 deps deep to get GUI support working, but now i have linux desktop computers on smol machines!

also have support for lima/colima/podman

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#173

Post by tough »

tptacek wrote: post #165
ilaksh wrote: post #154

Earlier quoted context omitted.

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.

You’re optimizing for one class of customer by denying another class a choice they explicitly want.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#174

Post by bkircher »

praveenhm wrote: post #122

what is the trend right now on mac to run microvm? I am using OrbStack.. is anything micro than this?

Yes. On macOS particularly you can do sandbox-exec(1) with custom / per-task SBPL profiles. Combined with strict control over environment variables that are passed into the agent process plus an outbound firewall like LittleSnitch.

Important is to isolate tasks from each other. Example: for work related tasks I let the agent access Datadog or Docker socket. Everything else does not have access to these.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#175

Post by tough »

justincormack wrote: post #67
alexellisuk wrote: post #41

Earlier quoted context omitted.

Yeah, I'm surprised Justin posted this like it was new(s). Wasn't it doing the rounds on the 22nd when it launched?

I didn't post it 3 hours ago, it must have gone through the magic HN re-up process.

Second-chance pool https://news.ycombinator.com/pool https://news.ycombinator.com/item?id=26998308

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#176

Post by crawshaw »

sublimefire wrote: post #171
crawshaw wrote: post #71

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.

Yeah I have some stuff which is supposed to be “there” for months with the agents continually moving it forward. Not to mention the need to run different software. Running local VMs for now.

If you have a good local VM flow that’s great. I couldn’t make it work for me. I ended up needing it to run when my laptop was shut, both as an agent and the servers I am building.

It’s a real tension, working with a remote dev env has never been my first choice. But agents seem to tip the balance enough in favor of remote that I have switched.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#177

Post by rvz »

sureglymop wrote: post #42
dbmikus wrote: post #32

There are sooooo many sandbox providers out there. They do spike on different features like: - snapshotting and forking - good SSH and VPN access for end-users - agent-friendly features, like obscuring secrets at network layer Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolat…

Why isn't libkrun good enough for hosted stuff? I use it as a podman backend in a microservice architecture.

libkrun is not production ready compared to Firecracker which the latter is used in 99.9% of many companies.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#178

Post by sublimefire »

0xbadcafebee wrote: post #121
nok22kon wrote: post #96

Earlier quoted context omitted.

imagine installing an agent in slack at a company with 1000 employees, and you want each request to have its own VM for data analysis, downloading repos and working on them, ... regular VMs just use too much memory, a typical ubuntu uses 512 MB as a baseline

^ this. a single long session may use 20 subagents, each of which need their own VM, on top of the parent agent's VM, all of which may need separate security credentials, isolation, in addition to the spinup time, and resources used. each user might do 100 sessions a week. so that's 2,000 VMs per week per user. each regular VM takes, let's say, 10s to boot up. that's 5.5 hours per week just waiting for VMs to start (…

This example is a bit over the top and is more of an edge case, subagents of the same session can use the same VM because what is the point to isolate among them? If at least one subagent is trying to hack you then I would consider the whole session was compromised anyway as you cannot guarantee the agents leaking this among themselves.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#179

Post by raesene9 »

PeterStuer wrote: post #43
dbmikus wrote: post #32

There are sooooo many sandbox providers out there. They do spike on different features like: - snapshotting and forking - good SSH and VPN access for end-users - agent-friendly features, like obscuring secrets at network layer Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolat…

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

Yep I've got one I built and it's absolutely fine for my use cases has a web interface/API custom kernels and rootfs, even the facility to set-up custom Kubernetes clusters. It's been really useful for other work like testing out vulnerabilities or security features in isolated envs.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#180

Post by crawshaw »

indigodaddy wrote: post #150
messh wrote: post #133

Earlier quoted context omitted.

Checkout https://shellbox.dev for exactly thisnusecase: boxes can be stopped, they are snapshotted to disk then cost just $0.5/month. They wakeup with the same state (memory and processes too) on ssh connections, or web endpoint activity, or just just a cron schedule. When you dont need the box... Just delete it and stop paying. No subscription, managed via ssh

Yeah crawshaw, you should check that out... ;)

I’m just going to keep building. :)
Post reply on HN