[HN Gopher] Show HN: Coasts - Containerized Hosts for Agents
___________________________________________________________________
Show HN: Coasts - Containerized Hosts for Agents
Hi HN - We've been working on Coasts ("containerized hosts") to
make it so you can run multiple localhost instances, and multiple
docker-compose runtimes, across git worktrees on the same computer.
Here's a demo: https://www.youtube.com/watch?v=yRiySdGQZZA. There
are also videos in our docs that give a good conceptual overview:
https://coasts.dev/docs/learn-coasts-videos. Agents can make code
changes in different worktrees in isolation, but it's hard for them
to test their changes without multiple localhost runtimes that are
isolated and scoped to those worktrees as well. You can do it up to
a point with port hacking tricks, but it becomes impractical when
you have a complex docker-compose with many services and multiple
volumes. We started playing with Codex and Conductor in the
beginning of this year and had to come up with a bunch of hacky
workarounds to give the agents access to isolated runtimes. After
bastardizing our own docker-compose setup, we came up with Coasts
as a way for agents to have their own runtimes without having to
change your original docker-compose. A containerized host (from
now on we'll just say "coast" for short) is a representation of
your project's runtime, like a devcontainer but without the IDE
stuff--it's just focused on the runtime. You create a Coastfile at
your project root and usually point to your project's docker-
compose from there. When you run `coast build` next to the
Coastfile you will get a build (essentially a docker image) that
can be used to spin up multiple Docker-in-Docker runtimes of your
project. Once you have a coast running, you can then do things
like assign it to a worktree, with `coast assign dev-1 -w
worktree-1`. The coast will then point at the worktree-1 root.
Under the hood the host project root and any external worktree
directories are Docker-bind-mounted into the container at creation
time but the /workspace dir, where we run the services of the coast
from, is a separate Linux bind mount that we create inside the
running container. When switching worktrees we basically just do
umount -l /workspace, mount --bind <path_to_worktree_root>, mount
--make-rshared /workspace inside of the running coast. The rshared
flag sets up mount propagation so that when we remount /workspace,
the change flows down to the inner Docker daemon's containers. The
main idea is that the agents can continue to work host-side but
then run exec commands against a specific coast instance if they
need to test runtime changes or access runtime logs. This makes it
so that we are harness agnostic and create interoperability around
any agent or agent harness that runs host-side. Each coast comes
with its own set of dynamic ports: you define the ports you wish to
expose back to the host machine in the Coastfile. You're also able
to "checkout" a coast. When you do that, socat binds the canonical
ports of your coast (e.g. web 3000, db 5432) to the host machine.
This is useful if you have hard coded ports in your project or need
to do something like test webhooks. In your Coastfile you point to
all the locations on your host-machine where you store your
worktrees for your project (e.g. ~/.codex/worktrees). When an agent
runs `coast lookup` from a host-side worktree directory, it is able
to find the name of the coast instance it is running on, so it can
do things like call `coast exec dev-1 make tests`. If your agent
needs to do things like test with Playwright it can so that host-
side by using the dynamic port of your frontend. You can also
configure volume topologies, omit services and volumes that your
agent doesn't need, as well as share certain services host-side so
you don't add overhead to each coast instance. You can also do
things like define strategies for how each service should behave
after a worktree assignment change (e.g. none, hot, restart,
rebuild). This helps you optimize switching worktrees so you don't
have to do a whole docker-compose down and up cycle every time.
We'd love to answer any questions and get your feedback!
Author : jsunderland323
Score : 49 points
Date : 2026-03-30 15:17 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jsunderland323 wrote:
| 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.
| oelmgren wrote:
| 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 wrote:
| Thanks!
|
| Yeah, I think there's a ton of great remote solutions right
| now. I think worktrees make the local stuff tricky but
| hopefully Coasts can help you out.
|
| Let me know how it goes!
| dbla wrote:
| 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?
| jsunderland323 wrote:
| 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) You can preserve your regular Docker setup without needing
| to alter it around dynamic ports and parallelized runtimes. I
| like this a lot because I want to know that my docker-compose
| is an approximation of production.
|
| 3) Docker basically leaves you with one type of strategy...
| docker compose up and docker compose down. With coasts you can
| decide on different strategies when you switch worktrees on a
| per service basis.
|
| 4) This is sort of back to point 2, but more often than not you
| want to do things like have some shared services or volumes
| across parallelized runtimes, Coasts makes that trivial (You
| can also have multiple coast configs so you can easily create a
| coast type that has isolated volumes). If you go the pure
| docker route, you are going to end up having multiple docker-
| composes for different scenarios that are easily abstracted by
| coasts.
|
| 5) The UI you get out of the box for keeping track of your
| assigned worktrees is super useful.
|
| 6) There's a lot of built in optimizations around switching
| worktrees in the inner bind mount that you'll have to manually
| code up yourself.
|
| 7) I think the ergonomics are just way better. I know that's
| kind of a vibesey answer but it was sort of the impetus for
| making Coasts in the first place.
|
| 8) There's a lot of stuff around secrets management that I
| think Coasts does particularly well but can get cumbersome if
| you're hand-rolling a docker solution.
| magic_hamster wrote:
| > docker-in-docker solution
|
| Goodbye Mac users.
| jsunderland323 wrote:
| Why do you say that?
|
| It works fine on mac (that's what we developed it on) and
| it's not nearly as much overhead as I was initially
| expecting. There's probably some added latency from virtual
| box but it hasn't been noticeable in our usage.
| smcleod wrote:
| Does it support native macOS containers?
| jsunderland323 wrote:
| It does not. It works through Docker Desktop, Orb Stack, or
| Colima on macOS.
| fabianlindfors wrote:
| 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.
| jsunderland323 wrote:
| We started with an approach like that but I think our grounding
| principal has been that you shouldn't have to modify your
| docker-compose to get parallelized local development. I think
| we want to layer onto your existing setup, not make you re-
| write your stack around us.
|
| I haven't really had a bad experience with Docker on Mac. but
| Is the idea you basically just build your service on top of
| specific.dev's provided services (postgres and redis) and those
| run bare-metal locally and then you can deploy to
| specific.dev's hosted solution?
| fabianlindfors wrote:
| 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 case of
| docker-compose that is often orthogonal to the production
| infrastructure in some sense.
|
| One thing I've used to great success though is taking an
| existing project or example docker-compose and simply asking
| the coding agent to translate it to Specific's IaC. Works a
| treat, especially as the coding agent can read all the code
| at the same time and connect it all together.
|
| (also it looks like we were in the same batch!)
| jsunderland323 wrote:
| 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!
| Pakvothe wrote:
| 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.
| cyanydeez wrote:
| 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.
| jsunderland323 wrote:
| There a couple of ways you can go about MCP within coasts (also
| depends on what the MCP does). You can either install the MCP
| service host-side (something like playwright), in which case
| everything should just work out of the box for you.
|
| Alternatively, you can setup the Coast to install MCP services
| in the containers. There are some cases around specific logging
| or db MCP's where this might make sense.
|
| >Would love to see this support stdio-to-HTTP bridging so local
| MCP servers can be exposed as remote ones without rewriting
| them.
|
| Are you saying if you exposed the MCP service in the Coast and
| hosted it remotely you could expose back the MCP service
| remotely? That's actually a sort of interesting idea. Right
| now, the agents basically need to exec the mcp calls if they
| are running host-side and need to call an inner mcp. I hadn't
| considered the case of proxying the stdout to http. I'll think
| about how best to implement that!
___________________________________________________________________
(page generated 2026-03-30 23:00 UTC)