HN

Comments (28)

• Menu

  adrq
  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.
• Menu

  fabianlindfors
  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. Has the added benefit of us being able to deploy the same config straight to production and switch in production database connections strings and anything else needed.
• Menu

  dbla
  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?
• Menu

  oelmgren
  This is pretty cool, have personally felt this limitation many a time.Basically been relying on spinning up cursor / niteshift / devin workflows since they have their own containers but this could be interesting to keep it all on your main machine.
• jsunderland323
  HN questions we know are coming our way:1) Could you run an agent in the coast?You could... sort of. We started out with this in mind. We wanted to get Claude Max plans to work so we built a way to inject OAuth secrets from the host into the containerized host... unfortunately because the Coast runtime doesn't match the host machine the OAuth token is created on, Anthropic rapidly invalidates the OAuth tokens. This would really only work for TUIs/CLIs and you'd almost certainly have to bring a usage key (at least for Anthropic). You would also need to figure out how to get a browser runtime into the containerized host if you wanted things like playwright to work for your agent.There's so many good host-side solutions for sandboxing. Coasts is not a sandboxing tool and we don't try to be. We should play well with all host-side sandboxing solutions though.2) Why DinD and why not mount namespaces with unshare / nsenter?Yes, DinD is heavy. A core principle of our design was to run the user's docker-compose unmodified. We wanted the full docker api inside the running containerized host. Raw mount namespaces can't provide image caches, network namespaces, and build layers without running against the host daemon or reimplementing Docker itself.In practice, I've seen about 200mb of overhead with each containerized host running Dind. We have a Podman runtime in the works, which may cut that down some. But the bulk of utilization comes from the services you're running and how you decide to optimize your containerized hosts and docker stack. We have a concept of "shared-services". For example if you don't need isolated postgres or redis, you can declare those services as shared in your Coastfile, and they'll run once on the host Docker daemon instead of being duplicated inside each containerized host, coasts will route to them.
• Menu

  Pakvothe
  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.
• Menu

  smcleod
  Does it support native macOS containers?
• Menu

  mike_d
  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.
• syntheticmind
  [dead]
• edinetdb
  [dead]
• aplomb1026
  [dead]
• MeetRickAI
  [flagged]
• imta71770
  [flagged]
• syntheticmind
  [flagged]
• Menu

  Copperline-Labs
  [flagged]
• wokgr3t4
  [dead]
• Menu

  Sim-In-Silico
  [flagged]