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

Show HN: Coasts – Containerized Hosts for Agents

github.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Show HN: Coasts – Containerized Hosts for Agents

#41

Post by jsunderland323 »

rakeshd wrote: post #39

This is really cool, been feeling this pain with worktrees for a while. Curious about the hot strategy: when you do umount -l /workspace + mount --bind + mount --make-rshared inside the DinD container, lazy unmount means a running file watcher can still hold open fds to the old worktree while the new bind is already live. Have you hit cases where it keeps writing to stale paths after the switch? Or does it just natur…

I have waited 12 hours for someone to ask this! You are my hero.

So the name "hot" is a bit misleading. The containers don't actually stay alive through the switch. What happens is we do the umount -l /workspace, mount --bind, mount --make-rshared sequence first, and then we run docker compose up --force-recreate. Force-recreate skips compose down (which would tear down the network, named volumes, everything) and just swaps the container processes in place. The old containers and their file watchers are killed and new ones start up.

By the time the new container processes start, /workspace already points at the new worktree so all their file handles are fresh and correct. There's no window where a watcher could be writing to stale paths because the old processes are just gone.

I was pretty afraid of this at first too but it turns out the force-recreate sidesteps the whole problem.

Re: Show HN: Coasts – Containerized Hosts for Agents

#42

Post by fabianlindfors »

jsunderland323 wrote: post #21
fabianlindfors wrote: post #20

Earlier quoted context omitted.

Yes, exactly. Probably two different focuses between us, we are more focused on providing the full environment to build productively with coding agents, from local dev all the way to prod. The key thing for us is that the agent can write code, build infrastructure and test the entire system autonomously locally, and then deploying to production should be dead simple. A bit of a different approach from the classic use…

I could definitely see that being useful for folks who are Docker-fearful or just less infra literate in general. I think we're focused on the other end of the spectrum. Folks who like docker and have a good docker setup but want to have parallel runtimes. Anyway, best of luck!

Same to you!

Re: Show HN: Coasts – Containerized Hosts for Agents

#44

Post by lukebaze »

jsunderland323 wrote: post #8
dbla wrote: post #6

This looks really cool and I've definitely been feeling this pain. I've been building out a solution for myself on top of docker. What are the advantages of using coasts over docker?

Hey thanks! To be clear it does use docker. It's a docker-in-docker solution. I think there's a quite a few things: 1) You need a control plane to manage the host-side ports. Docker alone cannot do that, so you're either going to write a docker-compose for your development environment where you hard code dynamic ports into a special docker-compose or you're going to end up writing your own custom control plane. 2) Yo…

[dead]

Re: Show HN: Coasts – Containerized Hosts for Agents

#45

Post by n1tro_lab »

cyanydeez wrote: post #23
Pakvothe wrote: post #22

This is interesting for MCP server deployment. Right now most MCP servers run as local stdio processes. Containerizing them would solve the security and isolation concerns that come up every time someone installs a thirdparty MCP server. Would love to see this support stdio-to-HTTP bridging so local MCP servers can be exposed as remote ones without rewriting them.

Isn't the primary security concern with thirdparty MCP servers the actual injected context and not whatever sandbox the MCP server is in? It doesn't really matter if the MCP can't do something to it's host; it's that it can manipulate the context to whatever ends it deems fit, which then is intractable in whatever LLM is calling it. I'm really struggling to understand what peoples security concepts are with LLMs.

[flagged]

Re: Show HN: Coasts – Containerized Hosts for Agents

#46

Post by fabianlindfors »

chrisweekly wrote: post #31
fabianlindfors wrote: post #18

We have been trying to solve the same problem (and a bunch of other ones) with https://specific.dev as well. We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac. Our approach is having our CLI handle port assignments (and pass any connection details/ports along as env vars) and that way being able to spin up “isolated” copies of the local dev environment. Ha…

> "We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac." This seems to be a pretty common perspective, but isn't it mostly about Docker Desktop? Orbstack solved my complaints, and I'm genuinely curious if I'm missing something significant (which is def possible).

Orbstack is definitely much better but far from native speeds in my experience. From our perspective of wanting all users to have a good experience, we also can't really point folks towards Orbstack as a "solution" to make the local dev experience great.

Re: Show HN: Coasts – Containerized Hosts for Agents

#48

Post by markamo »

This solves the parallel runtime problem well.

The adjacent problem I’ve been focused on is what happens after the agent finishes in its isolated environment: how do you review what it actually changed before accepting the result?

I’m interested in diff/commit/rollback at the filesystem level, so you can selectively keep some changes and discard others.

Different problem, but they compose naturally.

Re: Show HN: Coasts – Containerized Hosts for Agents

#49

Post by pdimitar »

chrisweekly wrote: post #31
fabianlindfors wrote: post #18

We have been trying to solve the same problem (and a bunch of other ones) with https://specific.dev as well. We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac. Our approach is having our CLI handle port assignments (and pass any connection details/ports along as env vars) and that way being able to spin up “isolated” copies of the local dev environment. Ha…

> "We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac." This seems to be a pretty common perspective, but isn't it mostly about Docker Desktop? Orbstack solved my complaints, and I'm genuinely curious if I'm missing something significant (which is def possible).

To put things into perspective: we have an integration test suite that takes:

- 30 minutes with Colima on Mac;

- 20 minutes with OrbStack on Mac;

- 13 minutes on a weaker CPU (Ryzen 5500U) on a native Linux laptop;

- 14 minutes on a Ryzen 5600X and a virtualized Debian inside Windows 10 WSL2.

Pretty stark differences. Granted our test suite is mostly I/O bound but that really tells you something about the VM overhead on a Mac and the lack of an actual kernel-native containerization support on macOS.

Re: Show HN: Coasts – Containerized Hosts for Agents

#50

Post by pdimitar »

jsunderland323 wrote: post #35
chrisweekly wrote: post #31

Earlier quoted context omitted.

> "We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac." This seems to be a pretty common perspective, but isn't it mostly about Docker Desktop? Orbstack solved my complaints, and I'm genuinely curious if I'm missing something significant (which is def possible).

I think this was a common perspective from early docker days with regard to local bind mounts (before docker switched from virtual box with hyperkit on macos). I do use Orb Stack and have noticed faster build times with Orb Stack but I haven't really noticed any difference in runtime performance between Orb Stack and Docker Desktop.

There are differences, but I think most people's code does not expose macOS' suboptimal containerization performance is all. Check my comment sibling to yours. We have noticed very observable differences.

Until Apple adds a kernel-level containerization support (likely: never) then this difference in performance will continue to exist.

That being said, Orbstack really is the best on macOS. Docker Desktop is only slightly slower but much worse as an UX. Colima I appreciate for its full headless nature but it's severely behind in performance, sadly.

Post reply on HN