TazLab Cluster Delivery Flow

Scope

This page explains the end-to-end delivery path for the active TazLab cluster from operator environment to live reconciled workloads.

Current Synthesis

The active cluster path is a layered handoff. The operator works through TazPod, infrastructure bootstrap is performed by ephemeral-castle, Flux is bootstrapped as part of that provider-specific layer, and steady-state cluster resources are then reconciled from tazlab-k8s.

The concrete layer-by-layer Flux graph is documented in TazLab Flux DAG. The provider-specific bootstrap details live in Ephemeral Castle Cluster Bootstrap.

Delivery Stages

Stage 1: Operator Environment

  • tazpod provides the operator shell, tools, and secret access
  • this is where bootstrap credentials and GitHub access are made available

Stage 2: Provider-Specific Bootstrap

  • ephemeral-castle provisions Proxmox plus Talos infrastructure
  • the same repository also installs foundational pieces such as ESO, MetalLB, Longhorn, and Flux bootstrap inputs
  • cluster-vars is produced here and later consumed by Flux manifests

Stage 3: Flux Handoff

  • Flux is bootstrapped pointing at tazlab-k8s
  • the cluster moves from imperative bootstrap to declarative reconciliation

Stage 4: GitOps Reconciliation

  • tazlab-k8s applies its DAG of operators, configs, instances, and applications
  • applications such as hugo-blog and mnemosyne-mcp are deployed through that steady-state model
  • the OpenClaw branch exists in the repository but is intentionally out of scope for this documentation pass

Why This Matters

This split is one of the core architectural boundaries in TazLab. ephemeral-castle owns provider-specific bootstrap truth, while tazlab-k8s owns provider-agnostic steady-state truth. Understanding that handoff is necessary for correct debugging, changes, and onboarding.

Relationships

Source Basis

  • AGENTS.ctx/ephemeral-castle/CONTEXT.md
  • AGENTS.ctx/tazlab-k8s/CONTEXT.md
  • AGENTS.ctx/cluster/CONTEXT.md