Documentation/Deployment

Deployment

Raincurve runs inside your environment by default. This page covers deployment models, components, security boundaries and how a rollout is staged.

Deployment models

ModelWhere Raincurve runsTypical fit
PrivateEntirely inside customer-owned infrastructure, including open-weight modelsRegulated operators, GPU clouds, carriers
HybridCollection and execution on-premises; reasoning in a dedicated environment you controlMulti-site enterprises
CloudDedicated single-tenant environment operated with RaincurveCloud-first platform teams

In every model, collection and any execution against your infrastructure happen inside your boundary.

Components

ComponentRole
CollectorsRead telemetry, inventory and change data from existing systems; read-only by default
Contract serviceCompresses raw signals into Compact Contracts and links them to raw evidence
Topology serviceMaintains the live cross-layer dependency graph
Curve-1 reasoningPre-filter scoring, trajectory encoding, hypothesis generation and incident clustering
Verification serviceChecks proposed actions against live state and in-flight work
Sandbox runnersExecute diagnostics and approved actions in isolated Firecracker microVMs
Console and APIsIncident views, approvals, reports and integrations with your tools

Security boundaries

  • Data residency. Operational telemetry stays inside the deployment boundary you choose.
  • Least privilege. Collectors start read-only. Write access is granted per action type, only when automation is enabled for it.
  • Isolated execution. Each task runs in its own microVM, restored from a clean copy-on-write snapshot; a failed or compromised run cannot reach the host, other sandboxes or anything outside its task.
  • Audit trail. Proposals, verification results, approvals and executions are recorded with their evidence.
  • Permissive open source. The underlying stack uses permissively licensed components (Apache 2.0, MIT, BSD-3, MPL 2.0).

Staged rollout

  1. Read-only. Collectors connect; the dependency graph is built and validated with your engineers.
  2. Shadow reasoning. Raincurve produces incidents and hypotheses alongside your current process; results are compared, not acted on.
  3. Recommendations. Hypotheses and verified action recommendations appear in your ticketing and chat tools.
  4. Approved actions. Engineers approve verified actions; Raincurve paces and executes them in sandboxes.
  5. Automatic actions. Specific, well-understood action types run automatically inside agreed limits.
Progressive automationEach step has explicit exit criteria agreed during the pilot. Moving to automatic actions is always a per-action-type decision.

Make infrastructure intelligence operational.

Start with a conversation about your environment.