Lunar.dev: an MCP gateway and API proxy in one TypeScript repository
lunar.dev: Agent native MCP Gateway for governance and security
At a glance
- What is it?
- TheLunarCompany/lunar ships two components, Lunar Proxy and Lunar MCPX, aimed at governing outbound API and agent traffic. The README describes the intent well and the operational detail thinly, so adoption hinges on reading the per-component READMEs before committing.
- Who is it for?
- Adopt it if you already run several MCP servers and want a single aggregation point with rate limiting and traffic visibility in front of them, and if you are willing to read the proxy and mcpx READMEs rather than the top-level one.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Lunar.dev is trying to mediate
The problem the README names is specific: as agents and autonomous workflows call external APIs, something has to sit between the caller and the services it depends on. Without that layer, each application or agent holds its own credentials, its own retry logic, and its own idea of how much of a paid API it is allowed to consume. The README calls this a mediation layer and a central aggregation point.
The intended audience is not a single developer calling one API. It is a team running multiple agents or applications against multiple third-party services, where someone needs to see the traffic and cap it. The README lists five things that layer should deliver: live metrics on latency, errors, cost and token usage; policy enforcement over tool access and agent actions; rate limits, retries, priority queues and circuit breakers; cost reduction through traffic shaping; and consolidation of multiple MCP servers behind one gateway.
That is a broad scope for one repository. The README acknowledges it by splitting the project into two components and telling readers to pick one or use both. Whether the two share configuration or deploy independently is not stated in the top-level README, which is the first thing a prospective adopter has to resolve.
Two components, two READMEs, one repository
Lunar Proxy is described as the core API gateway and control layer. Lunar MCPX is described as a zero-code aggregator for multiple MCP servers with unified API access. The word zero-code matters: it implies MCPX is configured rather than programmed against, which is a different adoption cost from a library you import.
The topics list on the repository reinforces the split. It includes api-proxy, mcp, mcp-client, mcp-gateway, mcp-security, mcp-server, mcp-servers, rate-limit, throttling and visibility. There is no separate topic for the proxy's own policy engine, so the proxy's capabilities have to be read out of its README rather than inferred from metadata.
The practical consequence is that this is not one product with one install path. A team that only needs to aggregate MCP servers reads mcpx/README.md. A team that only needs rate limiting and visibility on outbound HTTP reads proxy/README.md. The top-level README does not tell you how the two interact when both are deployed, or whether MCPX traffic flows through the proxy. That is a real gap for anyone planning a full-stack deployment, which the README itself suggests as an option.
The mechanism the README actually describes
Strip away the feature list and the architecture implied by the README is a forward proxy. Outbound traffic from applications and agents is routed through a gateway, which observes it, applies policy, and shapes it before it reaches the third-party service. The metrics named (latency, errors, cost, token usage) are the kind you can only produce by sitting on the request path, not by sampling logs after the fact.
MCPX works differently. It is an aggregator, so it presents multiple MCP servers through one interface. That means MCPX has to hold connections or configuration for each upstream server and expose them as a unified set of tools or endpoints to the client. The README does not describe the aggregation protocol, whether it namespaces tool names, or how it resolves collisions when two upstream servers expose a tool with the same name. Those are the questions that decide whether aggregation is usable in practice.
The policy layer sits on top of the proxy. The README lists tool access control, throttling of agent actions, rate limits, retries, priority queues and circuit breakers as separate capabilities, which suggests they are configured separately rather than derived from one policy document. Nothing in the supplied material shows the configuration schema, so the granularity of a rule (per agent, per API, per tool, per key) cannot be confirmed here.
Getting it running means leaving the top-level README
The top-level README contains no install command, no configuration example, and no environment variable. It links to two component READMEs and to docs.lunar.dev. That is the honest state of the supplied material, and it is worth saying plainly rather than reconstructing commands that are not there.
What can be traced: the project is TypeScript, the default branch is main, and the components live at proxy/ and mcpx/ in the repository tree, since the README links to https://github.com/TheLunarCompany/lunar/tree/main/proxy#readme and https://github.com/TheLunarCompany/lunar/tree/main/mcpx#readme. Any setup instructions, config keys and startup commands are in those two files or in the external documentation site.
For a team evaluating this, the first task is not deployment. It is reading both component READMEs and checking whether the configuration surface matches the policies you need to express. If your requirement is a rate limit per API key per upstream service, and the proxy only supports a global limit, you find that out before writing a deployment manifest, not after.
Where the release history and the commit history disagree
The release list is the most concrete limitation in the supplied material. The three most recent releases are lunar-proxy-v0.9.2 from 21 March 2024, lunar-proxy-v0.9.1 from 17 March 2024, and lunar-proxy-v0.8.27 from 14 January 2024. All three carry the lunar-proxy prefix, so no release tag in this list covers MCPX. The last push to main is dated 10 September 2026.
That combination needs care. A repository that is actively pushed to but has no recent tagged release may be developing toward a release, may have moved to a different release mechanism, or may be publishing tags that the supplied release list does not capture. The material here cannot distinguish between those cases. What it does mean is that anyone pinning a dependency should not assume the tag list reflects current main.
The version numbers themselves sit below 1.0. For an API gateway that sits on the request path of production traffic, a pre-1.0 version line is a statement about interface stability, and the project does not contradict it anywhere in the README. The README also states that advanced features for production environments come through guided onboarding and platform tiers. So the open-source core and the production offering are not the same thing, and the boundary between them is not drawn in the supplied text.
How it differs from putting a general reverse proxy in front
The obvious alternative for outbound traffic control is a general-purpose proxy such as Envoy or a similar gateway configured with rate limit and observability filters. That approach is mature and widely deployed. The difference in approach is what the policy is expressed against. A general proxy reasons about routes, clusters, hosts and headers. Lunar.dev's README reasons about tools, agents, token usage and MCP servers.
That distinction is not cosmetic. Token usage is not a header a generic proxy understands. Tool access control requires knowing which MCP tool an agent invoked, which means parsing the MCP protocol rather than routing on HTTP paths. If your governance questions are phrased in terms of agents and tools, a general proxy forces you to translate those questions into route-level rules, and some of them will not translate.
The trade-off runs the other way too. Envoy has years of documented failure modes, a large configuration ecosystem, and a release cadence you can plan around. Lunar.dev's advantage is protocol awareness; its cost is that you are adopting a pre-1.0 project whose MCPX component has no release tag in the supplied list. If your traffic is plain HTTP between services, the protocol awareness buys you nothing and the general proxy is the safer choice.
Licence and the production boundary
The repository is MIT licensed, and the README repeats the MIT badge at the top. The same README then states that the project remains open-source at its core and is free for non-production and personal use, with production environments served through guided onboarding and platform tiers.
Those two statements need to be read together, and this is not legal advice. An MIT licence on the code and a stated restriction on production use are different instruments, and how they interact depends on what exactly is licensed under MIT and what is offered as a separate platform tier. The supplied material does not resolve that. A team planning production deployment should read the LICENSE file and the terms referenced from lunar.dev rather than relying on the README's summary sentence.
On maintenance cost, the material supports one observation and no more. There are two components to track, and the release tags cover only one of them. If MCPX ships without its own versioned releases, upgrading it means tracking main, which changes the cost of staying current from a version bump to a code review.
Who this fits, and what to check first
The clearest fit is a team already running more than one MCP server, with agents that call paid external APIs, and a requirement to see and cap that traffic. MCPX addresses the aggregation problem directly and the proxy addresses the governance problem, and the README positions them as usable together.
The clearest mismatch is a team that needs a stable release line with a documented upgrade path today. The release list stops at lunar-proxy-v0.9.2 in March 2024, MCPX has no tag in that list, and the version numbers are below 1.0. That is not a reason to avoid the project, but it is a reason to check how releases are actually cut before designing around them.
The verification order is short. Read proxy/README.md and decide whether the policy granularity matches your rules. Read mcpx/README.md and check how tool name collisions between upstream servers are handled. Then confirm the licence position for production, because the README's own wording separates non-production use from production tiers, and that sentence is the one that decides whether the MIT badge is the whole story for your deployment.
Editorial conclusion
Adopt it if you already run several MCP servers and want a single aggregation point with rate limiting and traffic visibility in front of them, and if you are willing to read the proxy and mcpx READMEs rather than the top-level one. Do not adopt it if you need a stable, versioned release line today: the most recent release tags in the repository are lunar-proxy-v0.9.2 from March 2024, and the last push to main is dated September 2026, so the release history and the commit history tell different stories. Before deploying anything, open proxy/README.md and mcpx/README.md, confirm which of the two components you actually need, and check the license terms for production use, since the top-level README states the project is free for non-production and personal use only.
Community notes