Documentation Portal¶
HybridOps.Core is a licensed platform-in-a-box for hybrid infrastructure operations, with first-class targets including Proxmox, Hetzner, Azure, and GCP. HybridOps separates contracts, execution, and governance so the same modules can run in lightweight product mode or in a fully governed multi-cloud platform.
This portal is the primary entrypoint for operators and reviewers. It documents the architecture, operating model, and verification probes used to validate specified behaviour.
Start here¶
| Audience | Start here | What to expect |
|---|---|---|
| Tech Nation assessor | Tailored review guide | Review path, criteria mapping, verification anchors. |
| Hiring manager | What this demonstrates | Capability summary, design trade-offs, delivery patterns. |
| Engineer running the product | Quickstart: Install and run HybridOps.Core | Operator workflow using hyops, setup, and runbooks. |
| Learner / practitioner | Series roadmap | Learning path mapped to modules, procedures, and evidence. |
| Academy / bootcamp prospect | HybridOps Academy overview | Outcomes, syllabus structure, engagement paths. |
Product model¶
HybridOps is delivered as repositories and release artefacts with clear responsibilities:
- HybridOps.Core (runtime)
Delivered as a versioned, licensed release tarball. It contains: hyopsoperator CLI- modules (contract-driven automation units)
- drivers (tool adapters: Terraform, Packer, NetBox, Argo CD, and related tooling)
- probes (verification scripts)
-
operator utilities required to install and operate the runtime
-
HybridOps.Workloads (desired state)
GitOps-ready workload definitions consumed by Argo CD, organised by domain and environment. -
HybridOps.Docs (this portal)
Standards, contracts, ADRs, runbooks, HOWTOs, and evidence maps. This is the canonical source of truth for intent, operation, and verification. -
HybridOps.Workbench (internal)
Engineering staging and integration used to harden candidate modules, drivers, and workloads before promotion into Core and Workloads.
What is documented here¶
| Area | Description |
|---|---|
| Quickstart | Minimal path to install HybridOps.Core and run the reference chain. See Quickstart. |
| How-To Guides | Task-oriented procedures. See How-To index. |
| Runbooks | Reproducible operational procedures grouped by category and severity. See Runbooks index. |
| Showcases | End-to-end flows (CI/CD, DR, autoscaling, network automation). See Showcases overview. |
| Architecture decisions | ADR library explaining key decisions and trade-offs. See ADR overview. |
| Contracts and standards | Normative behaviour and shared conventions. See Contracts and Standards. |
| Evidence | Evidence map and curated proof anchors for key flows. See Evidence map. |
| Reference | Repository and module maps, plus supporting references. See Reference map. |
| HybridOps Academy | Learning and delivery paths built on the same operating model. See Academy overview. |
Platform overview¶
HybridOps.Core implements a hybrid operations blueprint built around:
- Proxmox as a first-class on-prem target, with cloud landing zones and hybrid connectivity into Azure and GCP, and cost-efficient edge patterns using Hetzner.
- Immutable images built with Packer for Linux (Ubuntu, Rocky) and Windows Server / Windows 11, used consistently across control and workload planes.
- Infrastructure provisioning with Terraform and configuration/verification using Ansible collections, with NetBox as a source of truth.
- CI/CD using Jenkins and GitHub Actions, with GitOps workflows (for example Argo CD) for Kubernetes workloads and platform configuration.
- Observability and decision logic using Prometheus federation and a decision service to support autoscale, burst, failover, and failback.
- Explicit network design and route governance, validated through repeatable drills and recorded evidence.
Evidence-first operation¶
HybridOps is designed to be verifiable. The standard verification chain is:
ADR (why) → contract/standard (what must remain stable) → runbook/HOWTO (how) → evidence artefacts (proof).
Start with:
Guardrails¶
Cost is treated as a first-class design driver, alongside security and maintainability.
License¶
- Code: MIT-0
- Documentation and diagrams: CC BY 4.0