Orbit Explained: A Self-Hosted Gateway for Models and MCP

Orbit is described as a self-hosted gateway for connecting private data models and MCP tools, giving an organization a place to manage how applications reach those resources. The key idea is to keep the gateway under your control rather than assume that model and tool traffic must pass through a hosted intermediary; the exact capabilities depend on the Orbit project and its configuration.

What Orbit means by a gateway

A gateway is a service positioned between clients and the systems they need to use. In this case, the relevant clients may be AI applications or agents, while the destinations may include language models, internal data services, and tools exposed through the Model Context Protocol (MCP). Instead of each client independently holding connection details for every destination, clients can be configured to communicate through a shared layer.

“Self-hosted” means the organization runs that layer in infrastructure it controls, such as its own server or private cloud environment. It does not automatically mean that every connected model runs locally, or that data can never leave the organization. If Orbit is configured to call an external model provider or a remote MCP server, information may still travel to that service. Hosting the gateway and hosting every dependency are separate decisions.

Background: models, private data, and MCP

A model produces responses from the prompt and context supplied to it. For useful work, an application may need to provide information from company documents, databases, or other systems. A “private data model” can refer to a model or model-backed application used with private organizational information; the phrase alone does not establish where the model runs, how data is stored, or what privacy guarantees apply.

MCP is a protocol for connecting AI applications with external context and tools. An MCP server can make capabilities available to a client, for example a search function over an approved document collection or a tool that reads project records. MCP is not itself a model, a database, or a promise that a tool is safe. The server and its exposed functions still need to be selected and managed carefully.

Orbit’s gateway framing brings these pieces into one integration point. That can make the overall arrangement easier to reason about, but it does not erase the distinctions between the model, the data source, the MCP server, and the gateway.

How the setup works

A typical gateway arrangement has a client, Orbit, and one or more back-end destinations. The client sends a request to the gateway; the gateway handles the connection to the configured model or tool; then a response is returned along the route. The precise routing, authentication, and policy features must be verified against Orbit’s own documentation rather than inferred from the word “gateway.”

For example, an internal assistant might ask a model to summarize a question and use an MCP tool to search a permitted set of documents. The gateway may act as the shared connection point for the assistant and those services. Whether the search results are sent to the model, logged, cached, or retained depends on the application and service settings—not merely on the fact that Orbit is self-hosted.

At a high level, an organization evaluating this kind of setup should:

• Identify which clients, models, data sources, and MCP servers need to connect.
• Decide which components will run on its own infrastructure and which remain external.
• Configure access credentials and network routes for each connection.
• Test expected requests, failures, and access restrictions before relying on the setup.
• Review logs and data handling so they do not expose information the organization meant to protect.

Why use a self-hosted gateway?

A gateway can reduce repeated integration work. If several clients need access to the same approved model or tools, a common connection point may simplify configuration and make changes easier to coordinate. It can also give operators a clearer place to inspect connectivity and apply whatever controls the software actually supports.

Self-hosting may appeal to teams that need operational control over deployment location, network access, or updates. It can be useful when internal services are reachable only from a private network. But it also transfers responsibility to the operator: someone must deploy the service, maintain it, monitor it, manage credentials, and respond when it becomes unavailable or needs an update.

It is a misconception that a self-hosted gateway automatically makes an AI system private. Privacy depends on the full path of a request, including the client, gateway, model provider, MCP server, and any logging or storage. A locally hosted gateway can still forward sensitive content to an external destination.

Security and operational questions

Before connecting business data, determine what Orbit supports and what must be handled elsewhere. Do not assume that it provides a particular authentication method, role system, audit trail, policy engine, or encryption feature unless the project documentation confirms it. These details affect whether the gateway fits a specific environment.

Useful questions for an evaluation include:

• Where does each request go, and which services can receive prompts or tool results?
• How are credentials supplied, stored, rotated, and restricted?
• Can a client reach only the models and tools it is meant to use?
• What information is recorded in logs, and who can read those logs?
• How are updates, backups, availability, and incident response handled?

Tool permissions deserve particular attention. A read-only search tool and a tool that can modify records have different consequences. Give each connection only the access it requires, test it with non-sensitive data first, and confirm that the model’s instructions cannot cause an MCP tool to exceed its intended permissions. A gateway can help organize access, but safe behavior also depends on the connected systems and their own controls.

Choosing Orbit or another approach

Start with the requirement, not the product label. If the main need is a shared route to several model or tool services, a gateway may be appropriate. If the need is to run a model entirely on local hardware, a gateway alone does not satisfy it; the model must also be deployed locally and configured as a destination. If the need is to expose internal data safely, assess the data source, identity controls, and tool permissions as carefully as the gateway.

Compare Orbit with other approaches by checking practical fit:

• Integration: Does it support the clients, model interfaces, and MCP servers you actually use?
• Deployment: Can your team operate it in the required network and hosting environment?
• Controls: Are its documented authentication, authorization, and logging options sufficient?
• Maintenance: Is there a clear process for upgrades, configuration changes, and troubleshooting?
• Dependencies: Which services remain external, and what happens if one is unavailable?

A direct connection from each client to each service may be simpler for a small setup, but can duplicate configuration. A managed hosted gateway may reduce deployment work, but involves trusting and relying on its operator. A self-hosted gateway offers a different balance: more control over the gateway’s environment, alongside more operational responsibility. No option is inherently private or secure without examining its complete data flow.

Frequently Asked Questions

Is Orbit an AI model?
Orbit is described here as a gateway, not as the model itself. It connects clients with model and tool services; the models and MCP servers are separate components.

Does self-hosted mean my data never leaves my network?
No. A self-hosted gateway can still send requests to external models or tools. Check every destination and the handling of prompts, results, and logs.

What does MCP do in this setup?
MCP provides a protocol for AI clients to connect with external context and tools. An MCP server supplies the particular functions or data it exposes.

Can Orbit make a local model private?
A gateway may connect to a locally deployed model, but it does not make the model local by itself. Confirm where the model runs and whether other connected services receive data.

Does Orbit automatically secure MCP tools?
Do not assume so. Tool permissions, authentication, network restrictions, and logging depend on Orbit’s documented features and the configuration of each connected service.

Related

• AI-Generated Code: Does It Work, and Do You Understand Why?
• Terminal-Based Postman Alternatives for AI Workflows
• Rules-Based Ad Automation vs Generative AI in Regulated Marketing