https://github.com/openziti/mcp-gateway
MCP servers work great locally over stdio... until you need one on another machine, or want to share tools across a team. Most approaches to that involve exposing endpoints and managing network access. I built a tool that keeps remote MCP as simple and secure as local stdio.mcp-bridge wraps any stdio MCP server in one command and shares it over a zrok/OpenZiti overlay. mcp-gateway aggregates...
https://github.com/openziti/llm-gateway
I built an OpenAI-compatible LLM gateway that routes requests to OpenAI, Anthropic, Ollama, vLLM, llama-server, SGLang... anything that speaks /v1/chat/completions. Single Go binary, one YAML config file, no infrastructure.It does the things you'd expect from this kind of gateway... semantic routing via a three-layer cascade (keyword heuristics, embedding similarity, LLM classifier) that picks...
There's a bunch of zrok stuff in the pipeline that's way more important to get to first... but maybe down the line we can support some kind of extension mechanism in zrok and static site generators could just sort of snap right in...
Stuff to think about anyway.
Update:
https://blog.openziti.io/the-zrok-sdk
Pretty excited to share this... Just finished up a blog post about the new, simple, secure peer-to-peer networking SDK for zrok.Build zrok applications with just a few lines of golang!
I've got a couple of big announcements that I'd like to share...
First, the service instance at zrok.io is now in public beta. We've been running a private beta since March. If you want to start working with zrok and aren't ready to self-host, you can easily and quickly get an account with zrok.io and start experimenting right away.
Second, since our last post here we've added full tunneling support to zrok. In addition to sharing HTTP-based resources, you can now share your raw TCP and UDP network endpoints using zrok.
Lots of other powerful stuff is coming in the next couple months. Check out the link for more details!
We could certainly incorporate an "embeddable" SDK so that zrok can be incorporated into other applications.
As it currently stands, you would need access to a zrok "service instance" ("cloud"), running the zrok controller (providing API access). But we could certainly look at other kinds of use cases where that control plane is potentially enabled ephemerally or on-demand. I have some ideas for things we might be able to do.
Neither of these are on the immediate roadmap. But if people ask for them, we could certainly build them.