On-premise
Appilot's client pieces are endpoint-agnostic: they talk to whatever Appilot backend you point them at, and none of them hard-codes a host. The backend itself is not something you can download today. This page says which is which, so an evaluation does not discover it late.
What you can run yourself today
The widget
The bundle is a static file with no Appilot host baked into its behaviour. Host it on your own CDN and point it at your backend:
<script type="module"
src="/assets/appilot.esm.js"
data-api-key="wk_live_..."
data-api-url="https://appilot.internal.example.com"></script>
Or from a bundler:
bootAppilotWidget({
widgetScriptUrl: '/assets/appilot.esm.js',
appilotApiUrl: 'https://appilot.internal.example.com',
tokenEndpoint: '/api/widget/token',
});
Your identity relay already runs in your own backend, so nothing about the relay changes.
Self-host the documentation too if your users cannot reach the public site, and
point the panel's help links at your copy with data-docs-base-url.
The MCP server
appilot-mcp is one binary that serves any instance. Set APPILOT_BASE_URL to
your own host and it never touches ours:
{
"mcpServers": {
"appilot": {
"command": "npx",
"args": ["-y", "appilot-mcp"],
"env": { "APPILOT_BASE_URL": "https://appilot.internal.example.com" }
}
}
}
With no registry access at all, fetch the package once on a connected machine and carry the tarball in:
npm pack appilot-mcp # on a connected machine
npm install -g ./appilot-mcp-<version>.tgz # inside the network
Then point the MCP entry at the installed appilot-mcp command instead of
npx. The static gate (validate_config) needs no network of any kind; only
the server echo and the live soak reach your instance.
The hosted endpoint at mcp.appilot.space fronts the Appilot cloud and cannot
reach a private instance. A deployment serves exactly one instance, and the
caller does not choose which, because a caller-chosen address would make the
service a relay into networks it has no business touching. For ChatGPT or
claude.ai against a private instance you run your own endpoint; ask us for the
container image and the four environment variables it takes.
An on-premise language model
gemma-on-prem is an OpenAI-compatible adapter for an engine you run yourself,
and it is the only provider Appilot treats as sovereign. A self-hosted DeepSeek
works through a custom base URL and is still classified as cloud, so a policy
that requires sovereignty will not accept it.
The default engine is DeepSeek, chosen because it is open-weights and the cheapest engine that handles the agent loop's tool use well. In the closed beta it points at DeepSeek's managed API, which processes in China with no adequacy decision and no Article 46 instrument. Because the weights are open, the same engine can run on your own infrastructure. See Bring your own LLM.
The extension
A production build carries the hosts it was built with, and a Chrome managed
policy moves all four of them (apiUrl, accountUrl, backofficeUrl,
landingUrl) without repackaging anything. Where no central Chrome management
exists, build your own with VITE_API_URL, VITE_ACCOUNT_URL,
VITE_BACKOFFICE_URL and VITE_LANDING_URL set for your deployment. Both
routes are in
Enterprise deployment.
What is not self-service
The Appilot backend, its database and its migrations are not published as an installable artifact, and there is no downloadable air-gapped bundle of the platform. Running Appilot inside your own network is an arrangement we make with you: we agree the deployment shape, the model, the identity integration and the support terms, and we hand over what that deployment needs.
Enterprise SSO (OIDC and SAML) is configured per organization by the Appilot operator and is available on a self-hosted deployment as part of that arrangement.
If you are evaluating Appilot for a sovereign or air-gapped environment, the useful first conversation is about which of your constraints are legal, which are network, and which are procurement. Write to us at appilot.space.