Deterministic Automation for Hybrid Infrastructure
Stateful and stateless DR, cloud burst, hybrid HA WAN, and GitOps-ready Kubernetes — validated across Proxmox, Hetzner, and GCP through a cost-aware, contract-driven model.
IPAM • SDN • PostgreSQL HA • RKE2 • VyOS edge • Cloud SQL DR
Current platform stories
Seven platform scenarios — each proven end to end with delivery paths, run records, and a documented walkthrough.
Stand up NetBox-backed IPAM, Proxmox SDN, and foundation services from a clean on-prem environment with deterministic state and repeatable rebuilds.
Deliver segmented VLAN-backed networking, optional host routing, NAT, and DHCP through one controlled Proxmox SDN path instead of hand-built bridge changes.
Run PostgreSQL HA on-prem with Patroni and pgBackRest, restore the cluster into GCP during a DR event, and return it on-prem with checksum-verified application data.
Use a Hetzner-hosted VyOS edge pair as the public WAN anchor, extend on-prem routes through site-extension tunnels, and exchange prefixes with a GCP hub over redundant BGP sessions.
Bring up a highly available on-prem RKE2 control plane and worker pool with a clean kubeconfig handoff, then layer GitOps and workloads on top without changing the underlying execution model.
Establish a managed Cloud SQL standby from the on-prem PostgreSQL HA source, promote it under control, and fail back into an isolated on-prem lane without touching the live service path.
Provision governed EVE-NG environments on Proxmox for on-campus teaching or GCP for remote delivery — same blueprint model, same execution contract, different target.
Capabilities
A compact operating surface that stays stable as environments, policy, and tooling evolve.
Drivers run in isolated workdirs and persist reviewable output under the runtime root. Redaction is default.
<runtime-root>/logs/module/<module_id>/<run_id>/
driver_meta.json
driver_result.json
inputs_runtime.json
workspace_policy.json
backend_binding.json
terragrunt.log
stdout.redacted
stderr.redacted Docs and runbooks describe the wiring. The operating surface stays stable even when the toolchain behind it changes.
Execution model
A strict boundary between intent, policy, and implementation.
Intent only. No backend logic, tool flags, or secret material.
api_version: hybridops/v1
kind: ModuleSpec
module_ref: platform/onprem/postgresql-ha
inputs:
defaults:
apply_mode: auto
patroni_cluster_name: postgres-ha
postgresql_version: 16
dcs_type: etcd
inventory_requires_ipam: true
requirements:
credentials: []
execution:
driver: config/ansible
profile: onprem-linux@v1.0
pack_ref:
id: onprem/common/platform/35-postgresql-ha@v1.0
outputs:
publish:
- pg_host
- cluster_vip
- endpoint_dns_name
- apps
- cap.db.postgresql_ha Profiles carry policy. Packs carry implementation. ModuleSpec remains tool-agnostic.
hyops apply is the stable entry point. Docs describe the wiring.
Pick the edition that fits your risk profile
Start with self-serve evaluation. Add governance, onboarding, and support as your risk profile grows.
For: Teams validating the workflow in a lab or low-risk environment
- Reference modules, docs, and demos
- Structured run records with redacted output
- Lab profiles and practical runbooks
- On-demand cloud — no always-on workload spend
For: Lean IT teams and schools moving from evaluation to adoption
- Everything in Community
- Paid Copilot and full documentation access
- Academy training for guided implementation tracks
- Onboarding, DR drill review, and rollout guidance
- Cost-guarded burst patterns with practical support
For: Regulated, multi-team, or multi-environment organizations
- Everything in SME
- Governance profiles and hardened rollout standards
- Audit-ready evidence and operating model alignment
- Structured training, enablement, and stakeholder support
- Commercial planning for broader adoption
Run your first DR drill in minutes.
Start with the self-serve quickstart to evaluate the workflow directly. For a guided walkthrough or delivery model mapping, use the demo option.
- Install the Community edition — no always-on cloud required
- Pick a reference module and run hyops apply
- Inspect the run record: redacted logs, published outputs, and provenance
- Read the runbook to go further