A contract-driven runtime for governed infrastructure operations across hybrid environments.
HybridOps Core verifies authority, dependencies and recovery conditions before an operation advances, dispatches governed stages through versioned contracts, and retains a structured record of every transition.
Quickstart · Reference scenarios · Documentation · Research
flowchart LR
intent["Declared operation"] --> resolve["Resolve contracts<br/>and policy"]
resolve --> ready["Evaluate authority<br/>and readiness"]
ready --> dispatch["Dispatch governed<br/>stages"]
dispatch --> verify["Verify required<br/>outcomes"]
verify --> close["Guard recovery<br/>and closure"]
close --> record["Write operation state<br/>and run record"]
| 86 runtime modules |
30 reference blueprints |
64 public decision records |
8 supported targets |
Hybrid infrastructure operations carry authority, policy, dependency state, validation, recovery decisions and operating records across system boundaries. HybridOps Core brings those concerns into one stable operator contract while each native platform remains authoritative for its own resources.
A ModuleSpec defines intended capability. A Profile carries environment policy. A Driver binds execution. A versioned Pack carries implementation assets. A Blueprint composes modules into a dependency-aware lifecycle. The runtime resolves these contracts, performs preflight, executes the selected implementation, publishes outputs and writes a structured run record.
Core governs five connected responsibilities:
- contract and policy resolution: deterministic input merge, validation, dependency ordering and environment policy
- authority and readiness: declared authority selection, required conditions and pre-dispatch checks
- governed dispatch: ordered execution through versioned drivers and implementation packs
- verification and lifecycle control: acceptance, recovery, release and closure conditions
- operation state and evidence: outputs, lifecycle transitions and non-secret run records with redacted logs
HybridOps is exercised through complete platform paths rather than isolated configuration examples.
- Authoritative on-prem foundation: source-of-truth network and platform foundation
- PostgreSQL HA recovery cycle: backup continuity, failover, failback, and controlled cutover
- Kubernetes HA platform foundation: highly available cluster foundation with GitOps delivery
- Network lab continuity: verified intake, private access, preservation and reconstruction for EVE-NG, GNS3 and Containerlab
See the full reference scenario library.
For installation, workstation setup, target initialisation, and first-run guidance, see the Quickstart.
You can inspect blueprints locally without cloud credentials or a live environment. These commands validate the manifest and display the execution plan:
hyops blueprint validate --ref onprem/authoritative-foundation@v1
hyops blueprint plan --ref onprem/authoritative-foundation@v1List local runtime environments without contacting their infrastructure:
hyops show env list
hyops show env list --jsonSee the authoritative foundation blueprint or browse the Blueprint Index.
Intent, policy, implementation and execution records remain separate. Blueprints add explicit ordering, required preflight evaluation and guarded lifecycle operations around the same runtime path.
Run records are written under stable paths such as:
~/.hybridops/logs/module/<module_id>/<run_id>/
~/.hybridops/logs/init/<target>/<run_id>/
- Python >= 3.11
- Module-specific execution dependencies are documented with the relevant module and runbook
HybridOps Core is the public reference implementation for ongoing work in platform engineering and infrastructure automation.
See Research and External Review for published papers, implementation maps, and external technical reviews.
- Full docs and reference scenarios: docs.hybridops.tech
- Public site: hybridops.tech
- Contributing: Contribution guide
- Security: Security policy