A contract-driven runtime for governed infrastructure operations across hybrid environments.
HybridOps Core verifies authority, dependencies and recovery conditions before infrastructure changes advance, coordinates execution across systems, and retains a structured record of every transition.
Quickstart · Reference scenarios · Documentation · Technical papers
flowchart LR
intent["Declared intent"] --> resolve["Resolve contracts<br/>and policy"]
resolve --> preflight["Verify authority<br/>and dependencies"]
preflight --> execute["Execute through a<br/>versioned driver and pack"]
execute --> verify["Validate the<br/>result"]
verify --> record["Publish outputs and<br/>write a run record"]
| 84 runtime modules |
29 reference blueprints |
52 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 four connected stages:
- contract resolution: deterministic input merge, validation, dependency ordering and environment policy
- controlled execution: driver-based dispatch through versioned implementation packs and isolated workdirs
- preflight and verification: required conditions and module probes around execution
- run records: non-secret execution records with metadata, outputs and 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.
If this operating model is useful to your work, star the repository to follow its development.
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
- Reference model: Anuket CNTT