# Lunar MCPX alternative: count your servers first

> Lunar's MCPX fronts the MCP servers you already run. If you run none, the right Lunar MCPX alternative removes the servers instead of proxying them.

**TL;DR** Lunar.dev describes MCPX as a self-hosted gateway that sits between agents and the MCP servers, APIs and LLM providers they use, and Boomi has completed its acquisition of Lunar.dev. If your estate already has servers in it, that shape fits. If it has none, Elaichi is the Lunar MCPX alternative that removes the servers: one organization-wide MCP endpoint behind OAuth, with connectors Elaichi authors and serves itself. Self-hosting still wins where policy puts the tool plane inside your own network.

## Do you already run MCP servers?

Count them before you shop, because the count decides the answer. An engineer stands up an MCP server for the internal ticketing API. A data team ships a second one over the warehouse. A year later there are nine, each with a token file, a deploy story and its own opinion about who may call what. That estate has a gateway-shaped problem, and a Lunar MCPX alternative that is itself a gateway is the right purchase.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps

A company with zero MCP servers reads the same gateway pages and reaches the wrong answer. Support, finance and legal are not waiting for a proxy. They are waiting for Salesforce, NetSuite and Jira to show up inside ChatGPT with limits attached. Buying a gateway in that state means first building the servers the gateway is supposed to govern.

## What Lunar.dev's MCPX is built for

MCPX is built for an estate that already has servers in it. Lunar.dev describes MCPX as a self-hosted "Enterprise MCP Gateway" that sits between agents and the MCP servers, APIs and LLM providers they use, with an open-source version on GitHub ([lunar.dev](https://www.lunar.dev/), checked September 2026).

Read the shape of that sentence. A gateway is a middle. It assumes two ends: agents on one side, servers and APIs on the other. Its value comes from consolidating control over things you deployed and intend to keep. If you deployed them, that value arrives on day one. You keep the server code, the network path and the release cycle, and you gain one place to watch the traffic.

The same sentence describes the standing work. A middle is only as current as its ends. Nine servers still need nine upgrades when a vendor changes an API, and nine owners on call when one of them stops refreshing a token. That is a fair price for an estate that wanted those servers. It is a strange price for an estate that never asked for them. Tyk and Zuplo sell a related shape from an API management starting point. Tyk's MCP Gateway proxies and governs remote MCP servers ([tyk.io](https://tyk.io/docs/ai-management/mcp-gateway/overview), checked September 2026). Zuplo federates MCP servers behind one OAuth-protected gateway ([zuplo.com](https://zuplo.com/mcp-gateway), checked September 2026).

## What does the Boomi acquisition change?

It changes who owns the roadmap, not the shape of the product. Boomi announced its intent to acquire Lunar.dev on 13 May 2026 and has since completed it ([boomi.com](https://boomi.com/blog/lunar-dev-boomi-acquisition/), checked September 2026).

Treat that as a set of questions to put in writing, not as a verdict. Ask about standalone pricing now that the gateway sits inside a larger platform. Ask about the release cadence of the open-source version. Ask whether support terms survive without a wider platform contract. Ask which buyer the roadmap now follows. An acquisition is not a reason to rule a product out. An unanswered roadmap question is a reason to keep the first commitment short.

## Why a Lunar MCPX alternative removes the servers instead of fronting them

| Axis | Lunar MCPX | Elaichi |
| --- | --- | --- |
| Architecture | Self-hosted gateway in front of the MCP servers you already run; the tool plane stays inside your own network, which some auditors require | Hosted control plane; every SaaS account served through one org-wide `POST /mcp` endpoint behind OAuth |
| Connector authoring | You author and deploy the servers behind the gateway; open-source version on GitHub | Elaichi authors and serves the connectors (450+ today); custom work through JSON config or forks with a review surface for upstream changes |
| Restrictions per tool | Whatever the gateway inspects plus what each backend server enforces | Block or allow rules on role or user, matched by tool name or pinned operation, resolved at four points including the outbound URL |
| Offboarding | Depends on your identity provider and each server's credential model | Grant re-read on every call; a preflight refuses removal until personal connections are transferred or deleted |
| Audit shape | Split across the gateway and each backend server; correlated later | One record shape across audit and application logs; the row names the connection actually reached |
| Pricing model | Self-hosted (engineer-weeks), open-source available; standalone commercial terms worth confirming after the Boomi acquisition | Gold at $15 per user per month or $120 per user per year, 14-day trial with no card, free read-only Auditor seat |

For a company with no servers, the server is the cost, so the useful Lunar MCPX alternative deletes that line rather than governing it. A gateway routes traffic to destinations you run. A control plane serves the destinations directly.

Elaichi is a governed MCP control plane. Every SaaS account the company uses is connected once, and the tools those accounts expose are served through one organization-wide endpoint: `POST /mcp`, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. There are no per-toolbox URLs and no embedded tokens. Claude, ChatGPT and Cursor each get pointed at that one address through their own admin console, and each person signs in as themselves. Elaichi authors, maintains and serves the connectors from its own infrastructure, and the catalog runs to 450+. There is no registry of somebody else's servers underneath and nothing for your team to deploy.

## Who decides what a tool call may touch

Three layers decide it, and they stay separate. Permissions group about 38 action strings into roles, and a member holds exactly one role, so every role is a complete persona. Sharing is a grant of view, use or edit on a resource to a user, a team or the whole org, and a member sees only what they own or what was shared with them. Org owners are included in that.

Restrictions are the third layer: which connectors and which individual tools a target may reach. Note that restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule on a user replaces the role rules for that user rather than adding to them. Blocks always beat allows inside the winning layer. A block matches the tool name or the pinned operation, while an allow matches the pinned operation only, which is the subject of [the pinned operation writeup](/blog/block-matches-name-allow-matches-operation/). The same resolver runs at four points: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.

## Who holds the credentials in each shape

With a gateway in front of servers you run, your team holds them. Each server carries its own secret and its own refresh path, and rotation is a job with your name on it.

Connector credentials never sit in Elaichi. A separate credential service holds per-account secrets, encrypted at rest, and owns refresh. A failed refresh marks the connection `needs_reauth` rather than failing quietly. A connect URL is a one-time session that carries no token, which is why it is safe to return over MCP. Read-back of an account's configuration returns public values plus the list of dot-paths that were encrypted, carrying none of their values. An org can supply its own OAuth app per connector, gated on `connector:manage` rather than `connection:manage`, so everyone who can delete a connection does not silently gain the ability to repoint the org's OAuth app.

## Where self-hosting is still the requirement

Self-hosting wins whenever your policy puts the tool plane inside your own network. An air-gapped segment, an internal system with no internet-reachable API, or a control that requires inspection of every outbound packet all point at a self-hosted gateway. Elaichi runs as a service, so in those estates it is not the answer and MCPX is a reasonable place to look.

Elaichi does carry controls that satisfy some regulated buyers. An organization picks its region at creation. The `eu` and `us` regions are hard residency, a Cloudflare Durable Object jurisdiction, so compute and storage both stay there. The `apac` region is a placement hint (best-effort). Eu and us are the two hard-residency zones. Envelope encryption with a customer-managed key in AWS KMS is available per org. None of that is the same sentence as "inside our VPC", so check which sentence your auditor actually wrote.

## What you give up when the servers disappear

Three things, stated plainly. First, you no longer own the connector code. Elaichi authors it. You can fork a public connector, edit its JSON config, and pull upstream changes. A review surface separates new tools, safe updates, config diffs, conflicts and upstream removals. But the base is not yours.

Second, prompt injection. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint: role-based permissions per operation, the `forbidden` classification that no OAuth scope reaches, output redaction, scope limits and full audit logging.

Third, cost shape. There are two plans, Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year, with a 14-day trial and no card to start. If a trial ends without checkout the workspace pauses rather than losing anything. A self-hosted gateway converts that line into engineering time, which is cheaper at some headcounts and much more expensive at others; [the self-hosted versus managed arithmetic](/blog/self-hosted-mcp-servers-vs-control-plane/) works it through. One more disclosure while you cost it: deleting an organization tears down the workspace but has no path to purge its log tenant, and the response names the residue rather than claiming a clean wipe.

## How each shape answers "which account did the agent write to?"

Elaichi answers it from the audit trail without correlation work. one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. Audit events and application logs share one record shape, so a single query answers what happened. `actor_kind` is a recorded field rather than a guess from a user agent, and its values include `ai_assistant`. Argument names and counts are logged; argument values never are. Export forwards to your own destination, with Datadog implemented. The read-only Auditor seat is free, so a compliance reviewer does not consume a license.

Two error strings exist per failed call. The one returned to the caller derives from the third party's response body. The one written to the audit trail never does, because audit records are org-visible and fan out to whatever SIEM you configured. With a gateway in front of servers you run, the answer to the account question depends on what the gateway records and on what each server behind it records. Settle that inventory question on a quiet afternoon rather than during an incident.

## What happens on the day somebody leaves

removing or suspending a member revokes every live grant in the same transaction as the membership change. A grant is the OAuth authorization a client holds for that person, and its revocation status is re-read on every single call, so removal is effective on the next call. Role and restriction changes are different. They resolve through a short cache and take effect within about two minutes, on the MCP endpoint, the console and the REST surface alike.

Offboarding runs a preflight. Personal connections referenced by a toolbox entry must be transferred to the org, a team or another member, or deleted, or the removal is refused. A private connection is not transferable at all, because a credential only its owner could use does not become someone else's. For the contractor version of this problem, [the offboarding walkthrough](/blog/shadow-ai-contractor-offboarding/) covers what to do before any of this is in place.

## How to sort your own estate in an afternoon

Start with the count, then price both shapes against it. The steps below take a couple of hours and settle the question better than any feature grid.

1. List every MCP server running in your company today, with an owner name against each.
2. List the AI clients your people already use, and check which have an admin console you can point at one URL.
3. Read your own policy for the sentence about where third-party processing may happen.
4. Price the gateway path as engineer-weeks per quarter, and the control plane path as billable seats.
5. Trial whichever shape the first four answers favor, scoped to one team and one connected app.

If the count in step one is zero and step three does not require your own network, you are buying a control plane. If it is nine, you are buying a gateway, and the acquisition questions belong in that conversation. If both answers feel premature, [the case for waiting](/blog/when-you-dont-need-an-mcp-gateway/) is a real one. When you want to see what a single endpoint would serve, browse the [connector catalog](/connectors/) or the [team use cases](/use-cases/).

## FAQ

### Is Lunar's MCPX self-hosted?

Yes. Lunar.dev describes MCPX as a self-hosted Enterprise MCP Gateway that sits between agents and the MCP servers, APIs and LLM providers they use, with an open-source version on GitHub (lunar.dev, checked September 2026). It is built to front infrastructure you already run, so it assumes MCP servers exist in your estate.

### Did Boomi acquire Lunar.dev?

Yes. Boomi announced its intent to acquire Lunar.dev on 13 May 2026 and has since completed the acquisition, per Boomi's own announcement (boomi.com, checked September 2026). For a buyer evaluating MCPX, the useful follow-ups are standalone pricing, the release cadence of the open-source version, and support terms outside a wider platform contract.

### What is a Lunar MCPX alternative for a company that runs no MCP servers?

Elaichi, a governed MCP control plane. Instead of proxying servers you deployed, Elaichi serves every connected SaaS account through one organization-wide endpoint at POST /mcp, standard MCP over Streamable HTTP and JSON-RPC 2.0, behind OAuth. There are no per-toolbox URLs and no embedded tokens, and Elaichi authors and serves the connectors itself, so the company never runs an MCP server.

### When is a self-hosted MCP gateway still the right choice?

When policy requires the tool plane to run inside your own network. Air-gapped segments, internal systems with no internet-reachable API, and controls that require inspection of every outbound packet all point at self-hosting. Elaichi runs as a service, with hard EU and US residency and customer-managed keys in AWS KMS, but those are not a substitute for running the software in your own VPC.

### How quickly does a permission change take effect in Elaichi?

Role and restriction changes take effect within about two minutes, because they resolve through a short cache on every surface. Grant revocation is faster. removing or suspending a member revokes every live grant in the same transaction as the membership change, and revocation status is re-read on every call, so it is effective on the next call.

## Read next

- [Elaichi vs Composio for company-wide MCP access](/blog/elaichi-vs-composio/) — Elaichi vs Composio: one organization-wide MCP endpoint with connectors Elaichi authors, against per-team endpoints over a large third-party app registry.
- [Elaichi vs native AI connectors: one plane, many clients](/blog/elaichi-vs-native-ai-connectors/) — Elaichi vs native AI connectors: what a second AI client costs in repeated authorization, provisioning, audit shapes and role models, and when native is still right.
- [Per-user MCP server vs shared endpoint at 200 people](/blog/per-user-mcp-servers-vs-one-endpoint/) — Per-user MCP server vs shared endpoint, compared as whole shapes: what each costs to set up at 200 people, and what each costs the hour somebody leaves.