Live data from Hacker News

Show HN: Coasts – Containerized Hosts for Agents

github.com

31–40 of 54 posts

Re: Show HN: Coasts – Containerized Hosts for Agents

#31

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).

Re: Show HN: Coasts – Containerized Hosts for Agents

#33
post #26

Just FYI you might want to reconsider your branding. Using the term "Coast Guard" in pretty much any capacity without written authorization is a felony.

Super not true. Unless they're actively _impersonating_ a Coast Guard officer and acting overtly in that purported role, there's no crime. Simply having a thing called "coast guard" doesn't run afoul of anything. (18 USC SS 912/913).

Re: Show HN: Coasts – Containerized Hosts for Agents

#34
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…

Thank you for the detailed info! I will check it out

Re: Show HN: Coasts – Containerized Hosts for Agents

#35

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).

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.

Re: Show HN: Coasts – Containerized Hosts for Agents

#38
post #37

How reliably do agents stick to the 'coast exec' boundary in practice? Especially when they spawn subagents that may or may not inherit the instructions.

Actually pretty reliably but you do need to explicitly call out the skill. I usually start agent threads with /coasts or in codex $coasts. Once it’s in the conversation they stick to it though.

One cool thing we do is we have the docs and semantic search of our docs baked into the CLI, so if the agents get lost they can usually figure things out kind of quickly by searching the docs via the cli.

Also we have a little section our agent.md and claude.md,I’m not sure how well it works without that.

Re: Show HN: Coasts – Containerized Hosts for Agents

#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 naturally recover once the watcher picks up the inotify events from the new mount?

Post reply on HN