Part II · Instance setup
Instance setup¶
Instance Settings is the admin surface of Foundry — everything that is true for the whole installation, before any individual product enters the picture. You reach it at /settings; it is visible to users with the admin role.
The header shows the live health of Polis, Foundry's agent-orchestration layer. If Polis is unhealthy, agents cannot run, so the status sits where an admin sees it first.
The five tabs¶
| Tab | What it configures | Why it is instance-level |
|---|---|---|
| Providers | The model backends — named connections to LLM APIs (Anthropic, OpenAI, Google Vertex, …) with credentials and billing mode | Credentials and vendor relationships belong to the installation, not to a product. Users can layer their own keys on top (see Your account). |
| Models | The model catalog aggregated from all providers: visibility, pricing, capability metadata | Pricing and availability are facts about the vendor, shared by every product. |
| Copilot | The one generic assist agent that powers every non-lifecycle assist surface | One agent, one configuration — every assist surface behaves the same way. |
| MCP Servers | The tool backends — MCP servers whose tools agents can call. The deliberate sibling of Providers: Providers supply models, MCP Servers supply tools. | Tool endpoints and their credentials are shared infrastructure. |
| Users | Who may log in to this instance, and whether they are admin or member | Instance access is an allowlist; membership in individual products is granted separately in Product Settings → Team. |
Suggested setup order¶
- Providers — nothing works without at least one working model backend.
- Models — sync pricing and hide what your teams should not use.
- Copilot — point the assist agent at a provider and test it.
- MCP Servers — the built-in presets already cover most tooling; add external servers when you need them.
- Users — invite your team.
Each tab is documented in its own page, including why the controls are shaped the way they are.