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

21–30 of 54 posts

Re: Show HN: Coasts – Containerized Hosts for Agents

#21

Post by jsunderland323 »

fabianlindfors wrote: post #20
jsunderland323 wrote: post #19

Earlier quoted context omitted.

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 ser…

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!

Re: Show HN: Coasts – Containerized Hosts for Agents

#22

Post by 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.

Re: Show HN: Coasts – Containerized Hosts for Agents

#23

Post by cyanydeez »

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.

Re: Show HN: Coasts – Containerized Hosts for Agents

#24

Post by jsunderland323 »

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.

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!

Re: Show HN: Coasts – Containerized Hosts for Agents

#27

Post by jsunderland323 »

mike_d wrote: 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.

Interesting, I was not aware.

Well fortunately it's the name of a local observability ui and not the actual product. We'll change it if it becomes a problem.

Re: Show HN: Coasts – Containerized Hosts for Agents

#29

Post by TZubiri »

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.

There's this naïve approach to security that obsesses with building walls, because walls are secure and nothing gets through.

Apparently a lot of people get nerd sniped into building impenetrable 10meter thick steel walls instead of thinking about doors and the windows.

Re: Show HN: Coasts – Containerized Hosts for Agents

#30

Post by sReinwald »

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.

Third-party MCP servers create at least two different security problems. One is prompt/context injection through the tool output. The other is the much more conventional risk of executing untrusted code with transient dependencies on your machine (which is how the recent litellm compromise was discovered).

Containerization only helps with the second one, not the first, but that still matters. If you’re going to run random third-party MCP servers, isolating them from your host and any sensitive local data is still an obvious improvement over no isolation.

Post reply on HN