Deployment
Deployment models and data boundaries
Context deploys four ways: managed, in your VPC, on-premises, or air-gapped. In every mode the entire platform deploys, not just model inference — the architecture, data boundaries, and operating responsibilities for each are documented below.
Deployment scope
The unit of deployment is the whole platform — the control plane that schedules and governs work, the isolated environments where agents execute, the context filesystem agents read, and the run history that records what happened. Context deploys the entire platform, not just inference: whichever perimeter you choose, all of it deploys there together.
You pick the perimeter; model endpoints, connectors, the update process, and the support model are configured for that architecture, and the resulting data-flow boundaries are documented during implementation.
Deployment model
Managed
In a managed deployment Context stands up and operates the platform — control plane, execution, and run history — for your workspace. Your team connects through SSO, defines runbooks, and governs policy; Context handles infrastructure operations, updates, and support.
Run traces stay inside the deployment. What does cross a boundary is model inference when a workflow uses a commercial endpoint. That provider's retention and training settings are documented and verified with you during implementation, and endpoints can be restricted to the providers your policy allows.
- Perimeter
- A deployment Context operates for your workspace
- Operations
- Context operates the platform; you govern policy and access
- Run traces
- Stay inside your deployment
- Model endpoints
- Commercial or open-weight endpoints, configured per policy
Deployment model
Your VPC
In a VPC deployment the entire platform runs inside a cloud account you own on AWS, Azure, or GCP — not just model inference behind an API. The control plane, execution environments, the context filesystem, and run history all live under your cloud controls: your network rules, your monitoring.
Sensitive data is not moved into someone else's cloud. Model inference can use private endpoints so traffic does not leave your network, and where a workflow is configured to call an external provider, that flow is documented during implementation.
- Perimeter
- Your own AWS, Azure, or GCP account
- Operations
- Runs under your cloud controls; operations shared per the deployment design
- Run traces
- Stay inside your VPC
- Model endpoints
- Private endpoints; traffic need not leave your network
Deployment model
On-premises
On-premises, Context runs on hardware you rack and operate, inside the perimeter your security team already defends. The update process and the support model are configured for this architecture during implementation — how releases arrive, how they are verified, and what Context can see when you ask for help are all decided with your operations team.
The data-flow boundary is the one you already enforce at the network edge. Which model endpoints are reachable from inside — and whether any are — is a configuration decision documented during implementation.
- Perimeter
- Your data center, on infrastructure you operate
- Operations
- You operate the infrastructure; updates and support configured for it
- Run traces
- Stay inside your perimeter
- Model endpoints
- Endpoints available inside your perimeter, per the deployment design
Deployment model
Air-gapped
Air-gapped deployment exists for environments designed for disconnected operation. The entire platform — control plane, execution, the context filesystem, and run history — deploys inside the boundary. Updates and support follow the process designed for disconnected operation during implementation.
Model inference runs on open-weight models served inside the boundary, because a disconnected environment cannot call a commercial API. The trade for total isolation is the model catalog available inside it.
- Perimeter
- A disconnected environment; the entire platform inside the boundary
- Operations
- You operate the environment; updates follow the disconnected process
- Run traces
- Never leave the boundary — run history deploys inside it
- Model endpoints
- Open-weight models served inside the boundary
Mode comparison
The same platform in each column — what changes is where the perimeter sits, who operates the infrastructure inside it, and which model endpoints are reachable from it.
| Managed | Your VPC | On-premises | Air-gapped | |
|---|---|---|---|---|
| Perimeter | A deployment Context operates for your workspace | Your own AWS, Azure, or GCP account | Your data center, on infrastructure you operate | A disconnected environment; the entire platform inside the boundary |
| Who operates what | Context operates the platform; you govern policy and access | Runs under your cloud controls; operations shared per the deployment design | You operate the infrastructure; updates and support configured for it | You operate the environment; updates follow the disconnected process |
| Run traces | Stay inside your deployment | Stay inside your VPC | Stay inside your perimeter | Never leave the boundary — run history deploys inside it |
| Model endpoints | Commercial or open-weight endpoints, configured per policy | Private endpoints; traffic need not leave your network | Endpoints available inside your perimeter, per the deployment design | Open-weight models served inside the boundary |
Controls in every mode
The control set is the same in every mode. Engine runs each agent in an isolated environment and gives it only the tools configured for its runbook. Read access, write access, and human approval are configured separately, so a workflow can be broad in what it reads and narrow in what it may change.
The execution environments enforce network policy: default-deny egress with allowlists per workflow, so an agent reaches exactly what its task requires and nothing else.
In every mode: agents get identity from your IdP, every action is authorized against policy and recorded in an append-only trail, and credentials are brokered to connectors at runtime — never written into runbooks or prompts.
Request documentation
The document library covers audit reports, assessments, and procurement paperwork. Request what your review needs; anything that requires an NDA is shared once it is in place.
Also documented: Identity & authorization · Data handling · Compliance program