Co

Coasts – Containerized Hosts for Agents

Hacker News

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!

Share card

Actual performance

99points
38comments
Made the leaderboard

Launch Intel predictions

Analyze your own launch →
Product HuntOn track for Day 1 leaderboard · Strong signals: mac, agents, agent · Missing: macos, cursor, claude
95%95% predicted probability of success on Product Hunt, based on ML models trained on real launch data.
best fitHighest predicted score across all platforms for this description.
Indie HackersFits the IH revenue-focused audience · Strong signals: started, para · Missing: supports, reddit linkedin, podcasting
80%80% predicted probability of success on Indie Hackers, based on ML models trained on real launch data.
TrustMRRFits verified-revenue profile · Strong signals: video, way, para · Missing: mobile apps, ios, personal
53%53% predicted probability of success on TrustMRR, based on ML models trained on real launch data.
AppSumoMay struggle as an AppSumo deal · Strong signals: host · Missing: plus, platform, intuitive
44%44% predicted probability of success on AppSumo, based on ML models trained on real launch data.
Hacker NewsMay not resonate with HN audience · Strong signals: ide, 000, io · Missing: https docs, excited, just released
38%38% predicted probability of success on Hacker News, based on ML models trained on real launch data.
nativeThis product was originally launched on this platform.
Acquire.comPre-revenue stage for this audience · Missing: arr, mrr, revenue
18%18% predicted probability of success on Acquire.com, based on ML models trained on real launch data.
BetaListMay not resonate with beta-testers · Missing: web3, chat, crypto
0%0% predicted probability of success on BetaList, based on ML models trained on real launch data.

Incorrect prediction on native model

Similar products

Mo
MoltOverflow - SlackOverflow for Agents35%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

MoltOverflow - SlackOverflow for Agents

Hacker News1
Cl
ClawOverflow – SlackOverflow for Agents34%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

ClawOverflow – SlackOverflow for Agents

Hacker News2
`u
`uvx ptn` and expose any system to agents (dangerously)44%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

`uvx ptn` and expose any system to agents (dangerously)

Hacker News3
crystl
crystl31%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

conduct an orchestra of agents

Indie Hackers1$170/moai
Mighty
Mighty96%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

OAuth for agents

Product Hunt+195Developer Tools
Ag
Agents Made Simple29%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

Agents Made Simple

Hacker News5
Brev
Brev87%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

Agents that continuously track your OKRs

Product Hunt+503Productivity
AI
AI Agents Benchmarking and Competition41%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

AI Agents Benchmarking and Competition

Hacker News2
OA
OAuth for AI Agents37%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

OAuth for AI Agents

Hacker News8
47
47jobs – A Fiverr/Upwork for AI Agents43%Launch Intel prediction score: how likely this product is to succeed on its source platform, based on its name, tagline, and description.

47jobs – A Fiverr/Upwork for AI Agents

Hacker News20