Skip to content

Fixed-Endpoint Deployment

A fixed-endpoint deployment pins an install to a single managed inference endpoint. The install talks only to that endpoint, local serving and provider configuration are hidden and rejected, and the model set can be restricted. This is the shape for a thin-client fleet that consumes a central, organization-run inference service.

For the deployment-profile schema and an example policy, see the Policy Schema Reference. This page covers the operational shape.

How it works

Setting deployment.profile = fixed_endpoint pins inference to the managed endpoint without bypassing the local router. The chat path is unchanged: every model call still flows through the local continuum-router, which preserves model-alias rewriting, web-search injection, health checks, and retry.

At startup the app pre-provisions exactly one OpenAI-compatible router backend pointed at the resolved endpoints.inferenceApi URL. Its API key is read from the OS keychain and passed to the router as an environment-variable reference, so the plaintext key never lands in the on-disk router config. Switching the profile back to standard removes that backend.

The endpoint is an ordinary managed service endpoint, not bespoke deployment config. The URL lives in endpoints.inferenceApi.baseUrl (with mode = custom), and the credential is written write-only to the keychain through the managed-endpoints credential command, never stored in the policy file or echoed back. The deployment section references the endpoint kind; it does not carry the URL or the secret.

Capability flags

The deployment section drives what a user may do. The flags are policy-only and read-only to the user, and the backend enforces each over both transports (the Tauri command guard and the REST route gate), failing closed:

  • deployment.allowLocalServing: whether a user may start a local inference server. When false, on-demand model loading is rejected on both transports. The router and the pinned fixed backend stay up; only local serving stops.
  • deployment.allowProviderConfig: whether a user may add or edit upstream providers. When false, the provider-configuration surface is rejected and the Providers tab is hidden from the API page.
  • deployment.allowModelDownload: whether a user may download models. When false, the model-download surface is rejected; browsing an already-installed catalog still works.
  • deployment.allowedModelIds: a list of model ids the install is restricted to. Empty means unrestricted. This is a soft restriction independent of the profile.

When profile = fixed_endpoint and allowLocalServing = false, the Models and Engines pages are also hidden. The policy author does not list them; they are derived from the profile and unioned into the effective hidden pages.

Model-id allowlisting

deployment.allowedModelIds is copied into the pinned router backend's model allowlist. This means the restriction holds for API clients too, not just the UI selector: a request for a model id outside the list is refused at the router, so a user cannot bypass the allowlist by calling the local API directly. Leave the list empty to allow any model the endpoint serves.

A typical fixed-endpoint deployment pairs the profile with all three capability flags off and the endpoint in custom mode, so the install only ever reaches the managed endpoint:

{
  "schemaVersion": 1,
  "policyId": "example-corp-fixed-endpoint",
  "issuedAt": "2026-06-24T00:00:00Z",
  "settingsOverrides": {
    "deployment": {
      "profile": "fixed_endpoint",
      "allowedModelIds": ["internal/llama-3"],
      "allowLocalServing": false,
      "allowProviderConfig": false,
      "allowModelDownload": false
    },
    "endpoints": {
      "inferenceApi": { "mode": "custom", "baseUrl": "https://models.internal/v1" }
    }
  },
  "lockedPaths": [
    "deployment.profile",
    "deployment.allowLocalServing",
    "deployment.allowProviderConfig",
    "deployment.allowModelDownload",
    "endpoints.inferenceApi.mode",
    "endpoints.inferenceApi.baseUrl"
  ]
}

Lock the deployment and endpoint paths so a user cannot change them. The endpoint's API key, if the server requires one, is set write-only through the managed-endpoints credential command, never in the policy file.

What the user experiences

A user on a fixed-endpoint install opens the app and chats. Model loading, downloads, provider setup, and the Models and Engines pages are gone or disabled, each with a "Managed by your organization" affordance where a control would be. Every model call goes to the managed endpoint through the local router, so aliases, health, and retry behave as usual. Every blocked action records one policy_gated audit entry; see Audit and Compliance.

Combine with air-gap

A fixed-endpoint deployment pairs naturally with air-gapped mode: pin inference to the internal endpoint, then add egress.airGapped: true with egress.allowedHosts listing the endpoint host so the install reaches nothing else. See Air-Gapped Deployment.

Next steps