HybridOps Core

A contract-driven runtime for repeatable infrastructure execution across on-prem, cloud, Kubernetes, and local targets.

73 runtime modules

26 reference blueprints

52 public decision records

8 supported surfaces

---

What this is

HybridOps Core is the automation runtime behind a hybrid infrastructure platform that runs across Proxmox, Hetzner, GCP, AWS, Azure, Kubernetes, Cloudflare, and local targets.

It acts as a contract-driven execution layer above tools such as Terraform, Terragrunt, Ansible, and Packer. It adds:

• controlled execution: how modules and blueprints are resolved and run
• governance and preflight validation: checks before an operation proceeds, including blueprint-level preflight before deploy execution
• structured run records: a non-secret record for every operation

Each module carries a declarative intent contract (spec.yml). A CLI (hyops) resolves the contract, selects a driver, executes it, and writes a structured run record. Blueprints sequence modules into repeatable multi-step deployments, evaluate required preflight checks before execution, and surface explicit confirmation when rerun or destructive risk is detected.

Validation

HybridOps is validated through recorded reference scenarios rather than isolated examples. The public scenario library covers source-of-truth operations, Kubernetes platform foundations, hybrid WAN extension, secret delivery, and disaster recovery workflows.

Representative scenarios:

• Authoritative on-prem foundation: NetBox-backed source-of-truth operations and Proxmox SDN baseline
• PostgreSQL HA failover and failback: Patroni, pgBackRest, GCP recovery, and controlled failback
• RKE2 HA platform foundation: RKE2 cluster foundation with GitOps delivery

The full reference scenario library is published at docs.hybridops.tech/reference-scenarios.

Quick start

python3 -m venv .venv && . .venv/bin/activate
pip install .

Initialise a target environment:

hyops init proxmox --env dev
hyops init gcp --env dev

Run a module:

hyops apply --env dev --module platform/onprem/rke2-cluster
hyops apply --env dev --module org/gcp/project-factory

Run a full blueprint (ordered multi-step deployment):

hyops blueprint deploy --env dev --ref onprem/rke2@v1 --execute

The runtime root defaults to ~/.hybridops. Override with --root <path> or $HYOPSRUNTIMEROOT.

Execution model

flowchart LR
    spec["ModuleSpec / spec.yml<br/>intent contract"]
    cli["hyops apply<br/>merge and validate"]
    driver["Driver<br/>execute in workdir"]
    record["Run record<br/>redacted evidence"]
    profile["Profile<br/>policy and defaults"]
    pack["Pack<br/>tool assets"]
spec --> cli     profile --> cli     cli --> driver     pack --> driver     driver --> record

This boundary keeps intent, policy, implementation, and execution evidence separate: module specs define intent, profiles carry policy, packs carry implementation assets, and drivers produce reviewable run records.

Blueprints sequence modules into repeatable deployments with explicit ordering, required preflight evaluation before execution, and confirmation prompts when rerun or destructive risk is detected.

Every hyops command writes a non-secret structured run record:

~/.hybridops/logs/module/<moduleid>/<runid>/
~/.hybridops/logs/init/<target>/<run_id>/

Requirements

• Python ≥ 3.11
• Tool dependencies vary by module: terraform, terragrunt, ansible, packer, gcloud, kubectl; only the tools used by the modules you run need to be present

Documentation

• Full docs and reference scenarios: docs.hybridops.tech
• Public site: hybridops.tech
• Contributing: CONTRIBUTING.md
• Security reports: security@hybridops.tech, see SECURITY.md
• Bugs and feature requests: use the issue tracker
• Reference model: Anuket CNTT

License

MIT-0