Know what it does. Know where it stops.
A runtime that moves production traffic should be able to explain itself: who can change it, what waits for approval, what is written down, and how it recovers. This page is that explanation — behaviour and documents, not badges.
The runtime does five things. And refuses five others.
It does
- Schedules your services on managed capacity in the regions you list
- Routes requests to the healthiest nearby runtime and fails over proportionally
- Builds images from your runtime file and rolls them out in canary steps
- Forms batches inside your latency budget and scales capacity to demand
- Collects health, latency and request-flow metrics and the logs you enable
It never
- Reads, stores or trains on the content of your requests beyond the logs you configure
- Moves a workload to a region you did not list
- Scales above a capacity ceiling you set, or changes a ceiling on its own
- Promotes a canary past a failed gate without a human or a passing signal
- Deletes a deployment: destroy is explicit, confirmed and logged
Five controls, each with an exception path.
Open a control to see how it behaves day to day and what happens when something goes wrong. Everything below is a description of the runtime, not a promise about it.
01 Identity & access Three roles, scoped per project. Enterprise adds SSO and SCIM.
- Who can do what
- Viewer reads dashboards and logs. Deployer deploys and rolls back. Admin edits routing, ceilings, alerting and members.
- Authentication
- Email + TOTP on every plan; SAML / OIDC single sign-on and SCIM provisioning on Enterprise.
- Tokens
- CLI and SDK tokens are scoped to a project and a role, expire, and can be revoked from the audit view.
02 Approvals & change control Every production change is a rollout with gates, not a switch.
- Rollouts
- Canary 5 → 25 → 100 %. Each step waits for its error-rate and latency gates; you can require a named approver as well.
- Routing & capacity
- Region removals drain in-flight requests first. Raising a capacity ceiling is an explicit, logged action.
- Destructive actions
- destroy and region removal require confirmation of the resource name and are recorded with who and when.
03 Audit & logging What changed, who changed it, and what the runtime decided.
- Audit log
- Deployments, rollbacks, routing edits, ceiling changes, member and token events. 30 days on Team, one year and exportable on Enterprise.
- Request logs
- Sampled routing decisions with their score breakdown; retention and sampling rate are yours to set.
- Export
- Logs and metrics export to your own stack over an OpenTelemetry endpoint. Log queries and exports are themselves logged.
04 Data handling Processed in the region that serves the request. Persisted only as the logs you configure.
- In flight
- TLS between the edge, the router and the runtime. Request bodies are not written to disk unless request logging is enabled by you.
- At rest
- Images, runtime files, metrics and logs are encrypted at rest. Enterprise can pin all storage to named jurisdictions.
- Your models
- Model weights and containers stay in your project. We do not train on, share or inspect their content.
05 Failure & rollback Failure is a ramp, not a cliff — and every ramp has a reverse gear.
- Region degradation
- Traffic is shed proportionally as the health score falls, then the region is marked unhealthy after three failed probes. Neighbours absorb the load.
- Bad release
- A failed gate pauses the rollout with the previous version still serving all traffic. terrane rollback returns to the last healthy version in under a minute.
- Incidents
- You are notified, with the affected regions and services named. Post-incident notes are published on the changelog.
Documents, on request.
We would rather send your security team a document they can review than show a badge on a marketing page. Ask for any of these from the contact form; Enterprise customers receive them during onboarding.
- 01 Data processing agreement
Standard DPA on Team, custom terms on Enterprise.
- 02 Sub-processor list
Providers that handle customer data, with region and purpose.
- 03 Security questionnaire
Completed vendor questionnaires (yours or ours), including current certification status.
- 04 Architecture overview
Data flows, trust boundaries and retention, as a document your security team can review.
01 Who owns the models, containers and runtime files?
You do. They stay in your project, export with terrane export, and are deleted when you destroy the project.
02 Where is my data processed?
In the region that serves each request. Metrics and logs are stored in the region of the project unless Enterprise residency pins them elsewhere.
03 Can I integrate with my existing tooling?
Yes: OpenTelemetry export for metrics and logs, webhooks for deployment and incident events, SSO on Enterprise.
04 How do you review changes to the runtime itself?
Runtime releases go through the same canary gates our customers use, region by region, with the ability to roll back. Notable changes are listed on the changelog.
05 What happens if Terrane has an outage?
The edge and runtimes keep serving with the last known routing state; the control plane recovers independently. You are notified with scope and timeline.
06 What does procurement receive?
The documents listed above, PO invoicing and a named contact. Certification status is stated in the questionnaire rather than as badges on this page.
Evaluate it on real traffic.
The free tier is the same runtime with the same controls. When your review needs paperwork, we send it — no sales call required to read it.