This repository manages home-lab services through two delivery paths: existing host Compose stacks and a Talos Kubernetes cluster reconciled by Argo CD.

flowchart LR
  developer[Developer workstation]
  repo[Gitea repository<br/>whentimeslows/home-services]

  subgraph compose[Compose delivery path]
    actions[Gitea Actions]
    nas[Self-hosted runner: nas1]
    rhel[Self-hosted runner: rhel1]
    nasStack[compose-services/media_nas1<br/>Docker Compose]
    rhelStack[compose-services/media_rhel1<br/>Podman Compose]
    actions --> nas --> nasStack
    actions --> rhel --> rhelStack
  end

  subgraph bootstrap[Terraform bootstrap path]
    terraform[Terraform]
    secrets[Talos machine secrets]
    talosConfig[Role-specific Talos machine configuration]
    terraform --> secrets
    terraform --> talosConfig
  end

  subgraph cluster[Talos Kubernetes cluster]
    cp[Control-plane nodes]
    workers[Worker nodes]
    argocd[Argo CD]
    appsets[ApplicationSets]
    apps[Generated Applications]
    workloads[Cluster workloads]
    cp --> argocd
    workers --> workloads
    argocd --> appsets --> apps --> workloads
  end

  subgraph gitops[GitOps repository directories]
    appsetFiles[bootstrap/applicationsets]
    infra[infrastructure/*<br/>Cilium and Longhorn charts]
    services[services/*<br/>Vaultwarden and other charts]
    appsetFiles -. registers .-> appsets
    infra --> apps
    services --> apps
  end

  developer -->|pushes code| repo
  repo -->|workflow checkout| actions
  repo -->|Terraform source and chart source| terraform
  terraform -->|configures and bootstraps| cluster
  repo -->|Git polling or webhook| argocd
  developer -->|kubectl handoff| appsetFiles

The Compose path deploys host services through Gitea Actions. The GitOps path uses Terraform for Talos day-zero bootstrap, then Argo CD pulls chart definitions from Gitea and continuously reconciles Kubernetes resources. The bootstrap/applicationsets/ manifests are the initial handoff between Terraform-installed Argo CD and the GitOps repository.

Repository layout

compose-services/
  media_nas1/
    compose.yaml
  media_rhel1/
    compose.yaml
terraform/
bootstrap/applicationsets/
infrastructure/
services/
  vaultwarden/
composectl.py
update_containers.sh
.gitea/
  workflows/
    deploy.yaml

compose-services/ contains host-specific Compose stacks managed by Gitea Actions.
infrastructure/ and services/ contain Helm charts discovered by Argo CD ApplicationSets.
terraform/ bootstraps Talos and installs the Argo CD engine; it does not manage day-two workloads.
composectl.py infers Compose stack names and paths from compose-services/.
update_containers.sh is a compatibility shim that delegates to the Python tool.

Runtime support

The CLI detects and uses whichever runtime is available:

docker compose ...
podman compose ...

This means the same service directories can be managed from either backend without changing the compose files.

Common commands

From the repository root:

python3 composectl.py --help
python3 composectl.py --dry-run --stack media_nas1 refresh
python3 composectl.py --dry-run --stack media_rhel1 refresh
python3 composectl.py --stack media_nas1 pull
python3 composectl.py --stack media_rhel1 status

The shell entrypoint delegates to the Python tool:

bash update_containers.sh --dry-run --stack media_rhel1 refresh

Refresh flow

The refresh flow validates and updates one stack:

compose config
pull
up -d --remove-orphans
optionally image prune -f when --prune is supplied

The up operation avoids an unnecessary down, reducing downtime during normal updates.

GitOps bootstrap

The Kubernetes path accepts a nodes list containing any number of control-plane and worker nodes. Each node has a unique name, IP address, and role; exactly one control-plane node is marked bootstrap = true. The endpoint, Kubernetes version, storage device, Cilium interface, and load-balancer address pool remain explicit inputs because they are site-specific.

Copy terraform/terraform.tfvars.example to a local .tfvars file and fill in the supported Kubernetes version, stable control-plane endpoint, and nodes list.
Create a dedicated Gitea service account with read-only access to whentimeslows/home-services, then create a read-only personal access token for that account. Do not use an administrator token or commit the token to terraform.tfvars.
From terraform/, export the Gitea credentials for this apply. The Terraform Kubernetes provider will create the Argo CD repository Secret named gitea-repository in the argocd namespace:

export TF_VAR_gitea_username="argocd-home-services"
export TF_VAR_gitea_password="<read-only-gitea-token>"

The token is stored in Terraform state and in the Kubernetes Secret, so protect the state backend and shell history. Use an environment variable or a protected variable-file mechanism rather than committing the token. 4. Run terraform init, terraform fmt, and terraform validate from terraform/. 5. Boot every KVM VM from the Talos ISO with its install disk attached. Terraform applies the role-specific configuration to every node, installs Talos to install_disk, bootstraps the selected control-plane node, and installs Argo CD. 6. Export the kubeconfig produced by Terraform before running kubectl. Terraform cannot safely infer your shell's active kubeconfig or make a later interactive kubectl command part of the apply, but it does expose the generated config as the sensitive kubeconfig output:

export KUBECONFIG="$HOME/.kube/home-services"
mkdir -p "$(dirname "$KUBECONFIG")"
terraform output -raw kubeconfig > "$KUBECONFIG"
chmod 600 "$KUBECONFIG"
kubectl cluster-info

Set KUBECONFIG only after terraform apply has completed and the kubeconfig output exists. This file is a cluster credential and must not be committed or shared. 7. Export the Talos client configuration for talosctl:

export TALOSCONFIG="$HOME/.talos/home-services/talosconfig"
mkdir -p "$(dirname "$TALOSCONFIG")"
terraform output -raw talosconfig > "$TALOSCONFIG"
chmod 600 "$TALOSCONFIG"
talosctl --nodes "$(terraform output -json talos_nodes | jq -r 'join(",")')" version

Apply both ApplicationSets with kubectl apply -f bootstrap/applicationsets/.
Connect the Argo CD CLI through the internal service:

argocd login --port-forward --port-forward-namespace argocd argocd-server
argocd app list

Retrieve the initial admin password with:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d

Confirm Argo CD discovers infrastructure/cilium, infrastructure/longhorn, and services/vaultwarden.

Talos uses its default CNI during bootstrap so Argo CD can start. Cilium is then reconciled as the first infrastructure application. Confirm the LAN interface and address pool before enabling production LoadBalancer services. Longhorn also requires a validated disk or mount on the storage node.

The Terraform Talos provider uses one generated machine-secrets bundle for the whole node list. If the nodes were previously configured with another Talos CA, reset/reinstall them or restore the matching Terraform state before applying. Terraform state contains the generated Talos credentials and must remain private.

Terraform's Talos client certificates must match the CA already installed on the nodes. If apply reports x509: certificate signed by unknown authority, stop and verify the node IPs and recover the original machine-secrets bundle/state. Recreating Terraform secrets without rebuilding the nodes will not repair the trust relationship.

Secrets

SOPS with age is the intended secret boundary. The repository policy is in .sops.yaml; age private keys and plaintext secret files are ignored. Provision the age private key to the cluster through a protected bootstrap process, then commit only files matching the repository's encrypted-file policy. Vaultwarden expects an existing Secret named vaultwarden-secrets.

Gitea Actions deployment

The workflow in .gitea/workflows/deploy.yaml deploys each host-specific stack to its matching self-hosted runner:

runner label nas1 deploys media_nas1 with Docker
runner label rhel1 deploys media_rhel1 with Podman

Install and register one persistent Gitea Actions runner on each server. The runner should use a dedicated service account and should only execute trusted changes from the protected main branch.

Deployments run on:

pushes to main
manual workflow dispatch
the first Friday of each month at 03:00 using a fixed UTC-6 offset (09:00 UTC)

The scheduled trigger evaluates every Friday and skips dates after the seventh day, leaving only the first Friday eligible. The host jobs always target their own stack; they do not use --all.

To roll back, dispatch the workflow from a known-good commit or revert the change on main and redeploy.