Run multiple platform instances

A single platform instance is fine for the first phase of any deployment. The complications start later. A staging environment is created so that risky configuration changes can be tested before they touch production. A second region is added because data residency requirements demand local processing. A subsidiary acquires its own instance because the parent's contract does not cover them. A research team needs a sandbox that they can break without affecting the rest of the organisation. Each of these is a perfectly reasonable reason to run more than one platform instance, and each of them brings the same set of operational questions: which is which, what is configured where, how do the configurations stay in step where they should, and how do they stay independent where they should not.

---

The Admin Dashboard's Instances surface is the entry point for that work. It surfaces the configuration that defines what an instance is: the gateway URL, the Console and Admin Dashboard URLs, the deployment mode (SaaS or Enterprise), the enabled feature set, and the current software version. It is not a multi-instance management surface in the strict sense; each instance is administered through its own Admin Dashboard. What the screen provides is the per-instance ground truth that makes coordinated multi-instance operation possible. This guide covers how to read that ground truth, the common multi-instance topologies the platform supports, and the operational disciplines that keep multiple instances coherent without accidentally making them entangled.

Persona: Platform operator working in the Admin Dashboard, often across more than one instance.

Estimated time: 10--15 minutes per instance for initial orientation; longer for setting up the operational disciplines that span instances.

When this guide applies

This guide is relevant in any of these situations:

Situation	What it covers
Setting up a separate staging environment alongside production	The per-instance configuration model and the disciplines that keep two instances coherent
Operating multiple production instances for regulatory or regional reasons	The independence model between instances and the cross-instance audit posture
Onboarding a subsidiary or business unit with its own instance	The verification step that confirms a fresh instance is configured as expected
Coordinating a platform upgrade across several instances	The version field on the Instances surface and the rolling-update considerations
Investigating why one instance behaves differently from another	The configuration drift the Instances surface makes visible

For single-instance deployments, this guide is mostly informational; the same surface still applies, but the multi-instance disciplines do not. The configuration model is worth understanding either way, because every deployment has at least one instance.

Outcomes

By the end of this guide:

• The Instances surface has been opened and the configuration fields are understood.
• The deployment mode of the current instance (SaaS or Enterprise) is clear, along with what that mode controls.
• The conditions under which fields are editable are clear, and any editable settings have been verified.
• The cross-instance disciplines (configuration parity, version coherence, audit segregation) are understood for deployments that need them.

Prerequisites

• Administrator access to the Admin Dashboard, typically the super_admin role.
• For multi-instance work: administrator access to each instance, since each one is administered separately.
• For Enterprise deployments: the underlying Kubernetes context required to make data-plane-level changes. Configuration that lives in the Admin Dashboard is editable from inside the platform; configuration that lives in the data plane manifests is editable through whatever GitOps or manual process the deployment uses.

Step 1: open the instances surface and orient

The Instances surface is the canonical source of truth for what a given instance is.

1. Sign in to the Admin Dashboard.

2. Open Settings → Instances from the sidebar.

3. Review the fields surfaced for the instance:

   Field	What it captures
   Instance Name	The identifier for this deployment, distinguishing it from any others
   Deployment Mode	SaaS (hosted by Tetrate) or Enterprise (self-hosted in customer infrastructure)
   Gateway URL	The base URL of the AI gateway proxy endpoint
   Console URL	The URL where developers reach the Console
   Admin URL	The URL where operators reach the Admin Dashboard
   Enabled Features	The platform capabilities active for this instance
   Version	The current software version of the deployment

4. Confirm that every value matches the documented expectation for this instance. A staging instance whose gateway URL accidentally points at production, or a production instance whose enabled-feature list has drifted from the rest of the fleet, are both reliable sources of "why is this weird" investigations weeks later.

The Instance Name is the single most important field for multi-instance operation. Naming conventions that include the environment (prod, staging, dev), the region (us-east-1, eu-central), and the business unit (platform, research, subsidiary-name) make the rest of the operational discipline considerably easier. A flat name like agent-router-2 becomes ambiguous immediately.

Step 2: understand the deployment mode

The deployment mode is the most consequential field on the screen because it determines who manages what.

Mode	Who manages infrastructure	Who manages configuration	Update model
SaaS	Tetrate, end-to-end	Customer, through the Admin Dashboard	Managed by Tetrate; the customer is notified through release notes
Enterprise	Customer, in their own Kubernetes cluster	Customer, both through the Admin Dashboard and through the data plane manifests	Customer controls timing; the upgrade flow is documented in the installation materials

A SaaS instance is appropriate when the customer wants a managed platform and does not require the data plane to live inside their own network boundary. An Enterprise instance is appropriate when data sovereignty, integration with internal networking, or fine-grained control over update timing makes the self-hosted model worthwhile. Most large organisations end up with Enterprise; smaller pilots and certain customer-specific PoCs use SaaS.

The deployment mode also determines what is editable on the Instances surface. SaaS instances generally expose a smaller surface for direct edit because the underlying infrastructure is managed; Enterprise instances expose more, because the customer is the operator at every level of the stack.

Where a setting is editable, subject to the deployment mode and the operator's permissions, it is changed in place:

1. Select Edit next to the configurable setting.
2. Update the value and select Save.

Changes may require a brief propagation period before they take effect across the platform.

Step 3: verify the gateway and Console URLs

The URL fields are where misconfiguration causes the most user-visible damage. A wrong gateway URL means requests do not reach the platform; a wrong Console URL means developers cannot find the surface they need; a wrong Admin URL means the operator team can be locked out of their own instance.

1. Confirm the Gateway URL matches what is documented in the team's integration guides. This is the URL that every developer-side integration (the base_url in their SDK calls) has to point at.
2. Confirm the Console URL is reachable from the network where developers actually work. A Console URL that resolves only inside a corporate VPN is a usability problem if developers are expected to use the Console from home.
3. Confirm the Admin URL is reachable from where operators actually work. The same VPN consideration applies.

These three URLs are the most-shared facts about an instance. Including them on the team's internal wiki, in the platform's runbook, and in the Console Dashboard itself (where the Gateway URL is also surfaced) keeps the misconfiguration-driven incident rate low.

Step 4: review the enabled feature set

Different deployment tiers, contracts, and customer commitments expose different features. The Enabled Features section is the authoritative list of what is active on this instance.

Typical entries include:

• MCP Profile support. The MCP catalogue and profile mechanism described in Govern MCP Server Access.
• Bring Your Own Key (BYOK). The developer-side BYOK surface described in Use Your Own Provider Credentials.
• OpenTelemetry export. The telemetry export described in Export Telemetry to an Observability Stack.
• Usage analytics. The analytics surface described in Audit Platform Activity.

Features not listed are not available on this instance, either because the deployment tier does not include them or because they have been disabled deliberately. Attempts to use a non-enabled feature surface as either a missing screen, an inactive control, or a clear "not available on this instance" message, not as a generic error. If a feature that the team expects is missing from the list, the resolution is typically a contractual or deployment-tier change rather than a configuration toggle.

Step 5: apply multi-instance discipline

For single-instance deployments, the work ends at Step 4. For multi-instance deployments, the disciplines that follow are what keep the fleet coherent.

Configuration parity for environments

Production, staging, and development instances should match each other in configuration shape, even if they differ in scale or upstream credentials. A change made in staging should be reflected in production once it is verified, and vice versa. The Instances surface itself does not enforce parity; the operator team's process does.

A typical pattern is to keep a written checklist of configuration that is supposed to match across environments (provider list, enabled feature set, SSO configuration shape, MCP catalogue) and to run it as part of any cross-environment change. Drift is most often discovered at the worst possible moment, during an incident, so periodic checks pay for themselves.

Configuration independence for separate tenants

For instances that belong to different business units, different regions, or different regulatory boundaries, the goal is the opposite: keep them independent. Each instance has its own Admin Dashboard, its own user records, its own credentials, its own audit log, and its own data plane. Cross-instance leakage of any of these is a serious problem, not an inconvenience.

Two disciplines help here:

• Naming. An instance name that includes the tenant identifier (a region, a business unit, an environment) makes cross-instance confusion in tooling, logs, and team conversations dramatically less likely.
• Access. Operator access to each instance should reflect the boundary the instance represents. A super_admin on the EU instance should not automatically be a super_admin on the US instance; SSO and role mapping make this easy to enforce if both instances point at the same IdP, but the role-claim mapping has to be configured per instance.

Version coherence

The Version field captures the current software version. In Enterprise deployments, the operator controls when each instance upgrades; in SaaS, Tetrate controls the schedule.

For multi-instance fleets, the typical pattern is to upgrade staging first, run for a few days to confirm nothing has surprised the team, then promote to production. The Version field across instances makes the current state of the rollout immediately visible: staging on the new version, production still on the old one, both visible on their respective Instances screens.

Audit segregation

Each instance has its own audit logs and usage analytics, both described in Audit Platform Activity. The two surfaces do not span instances; an event recorded on the US instance does not appear in the EU instance's log, and vice versa. For investigations that span instances, the operator team has to either correlate manually across both surfaces or, more sustainably, export both audit streams to a centralised SIEM via the OpenTelemetry path described in the developer-side observability guide.

Field reference

The Instances surface displays the following configuration for each instance:

Field	Description
Instance Name	The identifier for this deployment instance
Deployment Mode	SaaS (hosted by Tetrate) or Enterprise (self-hosted in customer infrastructure)
Gateway URL	The base URL of the AI gateway proxy endpoint
Console URL	The URL where developers access the Console
Admin URL	The URL where operators access the Admin Dashboard
Enabled Features	The platform capabilities active for this instance
Version	The current software version of the deployment

Three routine tasks operate against these fields:

• View instance configuration. Open the Instances surface from Settings and review the deployment details (all URLs, the deployment mode, and the enabled-feature list) to confirm the instance is configured as expected.
• Verify gateway URLs. Check the Gateway URL to confirm the proxy endpoint that developers and API clients send requests to, then verify it matches the URL documented in the team's integration guides and surfaced in the Console Dashboard.
• Review enabled features. Check the Enabled Features section against the platform capabilities expected for the deployment tier. Capabilities not listed are unavailable for the tier or have been disabled.

What to do next

• Audit platform activity. The audit posture differs per instance; multi-instance audit work is the natural next step. See Audit Platform Activity.
• Configure single sign-on. SSO is configured per instance, with the considerations described here. See Configure Single Sign-On.
• Working with budgets. Budgets are also per-instance and need to be designed in step with how traffic actually distributes across the fleet. See Working with Budgets.

---

Where to go next

Audit platform activity

The audit posture differs per instance; multi-instance audit work is the natural next step.

Configure single sign-on

SSO is configured per instance, with the considerations described here.