Deterministic Automation for Hybrid Infrastructure

HybridOps gives platform teams a stable way to run DR drills, burst paths, HA services, and edge changes across mixed infrastructure. Module intent stays separate from policy and implementation, while every run leaves behind the evidence needed for review.

IPAM • SDN • PostgreSQL HA • RKE2 • VyOS edge • Cloud SQL DR

Get started Book a demo

Sample verified surface

PostgreSQL HA failback

passed

hyops apply \
  platform/onprem/postgresql-ha \
  --profile onprem-linux@v1.0 \
  --record

preflight ok

plan captured

apply ok

probes passed

record written

<runtime-root>/logs/module/postgresql-ha/<run_id>/

Blueprints in core

Runtime modules

Public decision records

Supported surfaces

Community edition available→

Current platform stories

Eight platform scenarios with delivery paths, run records, and documented walkthroughs.

Authoritative on-prem foundation

Stand up NetBox-backed IPAM, Proxmox SDN, and foundation services from a clean on-prem environment with deterministic state and repeatable rebuilds.

View walkthrough

Reusable Proxmox SDN foundation

Deliver segmented VLAN-backed networking, optional host routing, NAT, and DHCP through one controlled Proxmox SDN path instead of hand-built bridge changes.

View walkthrough

PostgreSQL HA failover and failback

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.

View walkthrough

Hybrid WAN edge and site extension

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.

View walkthrough

RKE2 HA platform foundation

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.

View walkthrough

Managed PostgreSQL DR with Cloud SQL

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.

View walkthrough

Hybrid portal burst to GKE

Burst an authenticated portal web tier to GKE with GitOps, cloud-native secret delivery, and a controlled public cutover while authoritative identity and entitlement services remain upstream.

View walkthrough

Governed network emulation delivery

Provision governed EVE-NG environments on Proxmox for on-campus teaching or GCP for remote delivery; same blueprint model, same execution contract, different target.

View walkthrough

Capabilities

A compact operating surface that stays stable as environments, policy, and tooling evolve.

DR drills

Rehearsed failover and failback with structured run records, redacted logs, and a clear verification chain.

Controlled burst

Provision burst capacity only when signals and policy allow. Keep cloud spend event-driven.

Policy profiles

Centralize backends, approvals, connectivity expectations, and toolchain policy without leaking it into module intent.

Replaceable packs

Swap Terraform (via Terragrunt), Ansible, or Packer plans without breaking the module contract.

Validation

Deterministic input merge with module-owned validators and preflight before execution runs.

Run records

Every run persists deterministic results, redacted logs, and published outputs that can back an incident review or audit.

Representative runtime record

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.

ModuleSpec

Intent contract: inputs, constraints, probes

Driver

Execution engine and isolation boundary

Profile

Policy and defaults (governance)

Pack

Replaceable tool plan bundle

Evidence

Deterministic outputs and provenance

ModuleSpec stays clean

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.

Run records stay reviewable

Inputs

Merged with deterministic precedence, then validated.

Workdir

Packs are copied into an isolated workdir under the runtime root.

Run record

Stable paths with redaction by default and deterministic published outputs.

hyops apply is the stable entry point. Docs describe the wiring.

Choose the right rollout path

Start in the lab with Community. Add Copilot, Academy tracks, onboarding, and governance support when the work moves toward production.

Self-serve

Community

For: Labs, evaluation, and first DR drills

Community runtime and reference modules
Lab-ready profiles and runbooks
Structured run records for every run
No always-on cloud required

Guided rollout Common fit

SME

For: Lean teams taking HybridOps into production

Guided onboarding from Community
Platform Copilot and full docs
Academy implementation tracks
DR drill review and rollout support

Programme rollout

Enterprise

For: Regulated or multi-team programmes

SME plus governance profiles
Hardened rollout standards
Audit-ready run records
Training and enablement planning

Start here

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 with no always-on cloud required
Pick a reference module and run hyops apply
Inspect the run record: redacted logs, published outputs, and provenance
Follow the quickstart runbook to extend the drill

Run the Quickstart

Explore next

Why HybridOps Use cases Academy

Deterministic Automation for Hybrid Infrastructure

Current platform stories

Capabilities

Execution model

Choose the right rollout path

Run your first DR drill in minutes.

Book a call

Thanks, we have your details.