Deployment & Security

oper8r can be hosted by oper8r, managed privately, or deployed in a customer-controlled environment. The right model depends on the workflow, source systems, security requirements, procurement constraints, and whether your team wants oper8r to operate the workflow after launch.

Deployment Options

Option	Best fit
Hosted oper8r	Fastest path for teams that can use oper8r-hosted infrastructure.
Managed private deployment	Teams that need stricter environment boundaries, custom controls, or customer-specific operations.
Customer cloud	Teams that want oper8r deployed into their cloud account or approved infrastructure.
On-premise	Teams with strict data residency, network, or credential handling requirements.

Data Boundaries

Before connecting systems, define:

Which source systems are approved.
Which users or roles can connect each source.
Which records are in scope.
Whether data belongs in shared employee graph context, private user context, or not in oper8r at all.
Which outputs can be customer-facing.
Which workflows require human review.

Credential Posture

oper8r integrations should use the least privilege required for the workflow.

Recommended practices:

Use OAuth where supported.
Use read-only scopes unless a write workflow is explicitly approved.
Store secrets in approved secret infrastructure.
Do not put provider tokens or API keys in graph facts, prompts, skills, or documents.
Rotate credentials according to your internal policy.

Hosted Versus On-Prem

Hosted deployments are useful when speed matters and your data policy allows a managed SaaS path.

On-prem or customer-cloud deployments are useful when:

Source systems are only reachable from your network.
Data residency policy requires customer-controlled infrastructure.
Credentials cannot leave your environment.
Procurement requires dedicated infrastructure.
The workflow needs custom monitoring or approval controls.

Review And Audit

For mutating workflows, oper8r should expose enough context for a human reviewer to understand:

The actor or API key.
The target organization and graph scope.
The source-backed payload or payload hash.
The intended mutation.
The result or error.
The evidence used to justify the action.

Launch Checklist

Confirm deployment model.
Confirm source systems and permissions.
Confirm graph and data boundaries.
Confirm API and MCP grants.
Confirm reviewer path for mutating workflows.
Run test accounts or sample records.
Document the operating procedure.
Train users or install relevant agent skills.

For deployment planning, book time or email hello@oper8r.io.