Is Lunar 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 October 2026). It is built to front servers and APIs your agents already use, so it pays off when those exist in your estate.

Did Boomi acquire Lunar.dev?

Yes. Boomi announced a letter of intent to acquire Lunar.dev on May 13, 2026, and has since completed the acquisition, per Boomi's own announcements (boomi.com, checked October 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 most connectors and governs vendors' own MCP servers for the rest, so the company never runs an MCP server.

Can Elaichi sit in front of an MCP server we run?

Yes. On the Gold plan, an Org Owner or Org Admin can add a remote MCP server as the organization's own connector, as long as it speaks MCP over Streamable HTTP and is reachable over public HTTPS. A localhost address, an IP literal or an internal hostname is refused. Members then connect to it with their own sign-in, and restrictions, OAuth scopes and the audit log apply to its tools the same way they apply to any other connector.

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 three regions, EU, US and APAC. For EU and US, the data store and the execution of org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. In Elaichi, customer-managed keys in AWS KMS come with the Black plan. Neither is 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. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Revocation status is re-read on every call, so it is effective on the next call.

Lunar.dev MCPX alternatives for governed AI access

Do you already run MCP servers?

The main Lunar.dev MCPX alternatives are Elaichi, Runlayer, Mintive (formerly MintMCP), Tyk and Zuplo. Elaichi is the hosted one with no servers to run: one MCP address that Claude, ChatGPT, Cursor and Microsoft Copilot sign in to, in front of connectors Elaichi authors or governs.

Count your servers first, because the count decides which one fits. With none, look at a hosted MCP server such as Elaichi, which serves your SaaS accounts with no servers of your own to run. With several, a gateway is the right shape, and MCPX belongs on the shortlist. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

The gateway case looks like this. 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 gateway is the right purchase.

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, Xero and Jira to show up inside ChatGPT with limits attached. Buying a gateway in that state means first finding or building the servers it is supposed to govern.

What is Lunar.dev's MCPX built for?

MCPX is built for an estate that already has servers in it. Lunar.dev presents MCPX as an "Enterprise MCP Gateway" that sits between agents and the MCP servers, APIs and LLM providers they use (checked October 2026). The same page says MCPX is fully self-hosted, running inside your own infrastructure, and an open-source version is on GitHub.

Read the shape of that description. 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 servers and APIs your agents already use. If those exist, 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 description implies 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 (both checked October 2026). Tyk's MCP Gateway proxies and governs remote MCP servers. Zuplo's MCP Gateway federates MCP servers behind one OAuth-protected gateway.

What are the best Lunar.dev MCPX alternatives?

The alternatives divide on one question: who runs the gateway. Lunar.dev presents itself as an enterprise MCP gateway and AI control plane that sits between employees and agents and the tools they use, namely MCP servers, APIs and LLM providers, and its FAQ says MCPX is fully self-hosted inside the customer's infrastructure (checked October 2026).

Elaichi is the hosted answer to the same problem. It is a governed MCP control plane at one address, https://api.elaichi.ai/mcp, which Claude, ChatGPT, Cursor and Microsoft Copilot all sign into with OAuth. There is no per-team and no per-client URL, and there is nothing to deploy. Behind that address sits a governed catalog of 650+ connectors. Elaichi authors and runs most of them itself, and the rest are native MCP connectors, where the vendor builds and runs the server and Elaichi handles sign-in, access and audit.

So the choice is whether you want to own the runtime or only the rules. A team that already runs MCP servers, and wants the proxy inside its own network, reads MCPX. A team with no servers and a list of SaaS apps reads a hosted control plane.

The other alternatives sit between those two ends. Each vendor describes its own deployment shape:

Runlayer. Its docs say it runs as a hosted deployment or self-hosted in your own AWS account (docs.runlayer.com, checked October 2026).
Mintive (formerly MintMCP). Its gateway FAQ says it is managed in the US or the EU, with VPC and self-hosted deployments available on request (mintive.com, checked November 2026).
Tyk. Its MCP Gateway proxies and governs remote MCP servers through a central gateway layer (tyk.io, checked October 2026).
Zuplo. Its MCP Gateway federates remote MCP servers behind one gateway with an OAuth server built in (zuplo.com, checked October 2026).
Docker MCP Gateway. Docker calls it its open source solution for orchestrating MCP servers (docs.docker.com, checked November 2026).

Runlayer alternatives and MintMCP alternatives compare those two gateways in more depth.

What does the Boomi acquisition change?

It changes who owns the roadmap, not the shape of the product. Boomi announced a letter of intent to acquire Lunar.dev on May 13, 2026 (Boomi press release). It has since completed the acquisition (Boomi blog, checked October 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.

What does a Lunar MCPX alternative look like with no servers to front?

Axis	Lunar MCPX	Elaichi
Where it runs	Self-hosted, inside your own infrastructure, which some auditors require	Hosted service; every SaaS account served through one org-wide `POST /mcp` endpoint behind OAuth
What it serves	The MCP servers, APIs and LLM providers your agents already use	650+ connectors, most authored by Elaichi and the rest vendors' own MCP servers it governs
Who maintains the tools	Whoever runs each server behind the gateway	Elaichi; custom work through JSON config, or forks with a review step for upstream changes
Per-tool rules	Ask how rules are written and where each one is enforced	Block or allow rules on a role or a user, checked wherever a member can reach a connector or tool, including the outbound URL
A leaver's access	Ask how it is cut at the gateway and at each server	Grant re-read on every call; a preflight for personal connections
Audit	Ask what the gateway records and what each server records	One record shape across audit and application logs; each entry names the account reached
Cost model	Engineer time to run it; open-source version on GitHub; commercial terms to confirm after the Boomi deal	Gold lists at $15 per user per month in USD, or $10 per user per month billed annually; 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 servers that already exist. Elaichi serves the tools itself.

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. No toolbox gets its own URL, and no token rides inside a link. An admin adds that address once where each AI client allows it, and each person then connects and signs in as themselves. Connecting ChatGPT shows one client's flow end to end. Elaichi authors, maintains and serves most of the connectors from its own infrastructure, and the catalog runs to 650+. The rest are vendors' own MCP servers that Elaichi staff publish one by one, not an open registry, and there is nothing for your team to deploy.

Who decides what a tool call may touch?

Three layers decide it, and they stay separate. Permissions group 58 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. Nobody sees a resource they neither own nor were given, org owners included.

Restrictions are the third layer: which connectors and which individual tools a target may reach. One limit on them is deliberate: restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Blocks always beat allows inside each layer. A block can match a tool's name or the operation underneath it, while an allow matches the operation alone. The reason is in the writeup on names versus operations. Every rule is checked at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file.

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. Secrets for each account live in a separate credential service that encrypts them at rest and handles refresh. A refresh that fails flags the connection needs_reauth, so the break shows up where someone will see it. 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. That setting is gated on connector:manage, not connection:manage, so deleting a connection and repointing the org's OAuth app stay separate powers.

When is self-hosting 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 regulated buyers ask about. An organization picks its region at creation. Elaichi has three regions, EU, US and APAC. For EU and US, the organization's data store and the execution of its org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. The audit trail is stored in one EU log instance for every region. In Elaichi, customer-managed keys in AWS KMS come with the Black plan. None of that is the same sentence as "inside our VPC", so check which sentence your auditor actually wrote.

Who should not pick Elaichi?

A team that must run the gateway inside its own infrastructure should not pick Elaichi. Elaichi is a hosted service, so if your policy puts the tool plane in your own VPC, or the systems you want to reach sit in an air-gapped segment, a self-hosted gateway is the honest answer and MCPX belongs on that shortlist. Two smaller cases point away as well. A team that wants to own every line of connector code will chafe at connectors Elaichi authors. A single engineer wiring one local server to one client needs nothing in the middle at all.

What do 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 an audit row for each call that reaches execution.

Third, cost shape. Gold lists at $15 per user per month in USD, or $10 per user per month billed annually, and pricing shows the price where you are. Elaichi has three plans: Personal, which is free, then Gold and Black, and every new workspace starts on a 14-day Black trial, no credit card to start. Buying Gold or Black during the trial keeps its remaining days rather than granting a fresh 14, so it is one continuous trial, and the seats are first charged when it ends. A workspace that buys nothing moves to the free Personal plan. Nothing is deleted when a trial ends. 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 works it through.

One more disclosure while you cost it: deleting an organization deletes its connector credentials but leaves three stores: the audit history, analytics events, and the credential service's organization, environment and installed-connector configuration rows. Elaichi reports that residue by name. It never claims a clean wipe.

How does each shape show which account an agent wrote to?

Elaichi answers from its own audit trail, with no correlation work. The trail holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection on each entry is the account the call reached, taken from the execution itself. Audit events and application logs share one record shape, so a single query answers what happened. The actor_kind field is recorded at the point of action rather than guessed from a user agent, and its values include ai_assistant, which marks only the Elaichi Agent. In Elaichi, a call from an MCP client is recorded under the person who signed in, with surface mcp and the OAuth client named. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments. Beyond the in-app trail, export to your own Datadog comes with the Black plan. 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 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?

In Elaichi, 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. 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 that lists every connection the departing member owns, private and shared alike. A private connection that a shared toolbox still relies on blocks the removal until you transfer it to an active member, never to the organization, to a team, or to the admin running the removal. At offboarding, a private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. A shared connection a team still depends on is left untouched unless you delete it, so transfer it to someone who is staying, which leaves every grant on it as it was. For the contractor version of this problem, the offboarding walkthrough covers what to do before any of this is in place.

How do you 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.

List every MCP server running in your company today, with an owner name against each.
List the AI clients your people already use, and check how each one lets an admin add a single URL for members to connect to.
Read your own policy for the sentence about where third-party processing may happen.
Price the gateway path as engineer-weeks per quarter, and the hosted path as billable seats.
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 hosted MCP server. 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 is a real one. For the wider field, see what an MCP gateway is, shape by shape. When you want to see what a single endpoint would serve, browse the connector catalog or the team use cases.