Adapt GitOps bootstrap for private single-node Hetzner cluster

apps/demo.yaml

@@ -28,7 +28,7 @@ spec:
   project: default
 
   source:
-    repoURL: https://github.com/YOUR_GITHUB_USERNAME/k8s-starter-pack.git
+    repoURL: https://tea.ahmza.com/ahmza.com/vps-k8s.git
     targetRevision: main
     path: apps/demo
 

apps/demo/service.yaml

@@ -3,28 +3,16 @@
 # time. This Service selects any Pod labelled app: demo (see
 # deployment.yaml) and forwards traffic to it.
 #
-# type: LoadBalancer asks the cluster for a real, dedicated IP address that
-# anything on your network can reach directly. On a cloud provider that
-# would provision an actual cloud load balancer; on bare metal there's
-# nothing to provision it, which is exactly the gap MetalLB
-# (apps/metallb.yaml) fills — it watches for LoadBalancer Services and
-# hands them an address from the pool configured in
-# apps/metallb/templates/ipaddresspool.yaml. Until that pool exists, this
-# Service's address will show as <pending>; see docs/05-metallb.md.
+# ClusterIP keeps this demo internal: this Hetzner deployment does not use
+# MetalLB or a cloud load balancer. Reach it with kubectl port-forward over
+# the private Kubernetes API rather than opening public application ports.
 apiVersion: v1
 kind: Service
 metadata:
   name: demo
   namespace: demo
-  annotations:
-    # Requests this specific address from MetalLB's pool, so it stays
-    # predictable across rebuilds instead of getting whatever's next free.
-    # Must fall inside the range in
-    # apps/metallb/templates/ipaddresspool.yaml, or MetalLB will never
-    # satisfy the request.
-    metallb.universe.tf/loadBalancerIPs: "192.168.1.241" # EDIT ME
 spec:
-  type: LoadBalancer
+  type: ClusterIP
   selector:
     app: demo
   ports:

apps/longhorn.yaml

@@ -20,7 +20,7 @@ spec:
   project: default
 
   source:
-    repoURL: https://github.com/YOUR_GITHUB_USERNAME/k8s-starter-pack.git
+    repoURL: https://tea.ahmza.com/ahmza.com/vps-k8s.git
     targetRevision: main
     path: apps/longhorn
 

apps/metallb.yaml

@@ -25,7 +25,7 @@ spec:
   project: default
 
   source:
-    repoURL: https://github.com/YOUR_GITHUB_USERNAME/k8s-starter-pack.git
+    repoURL: https://tea.ahmza.com/ahmza.com/vps-k8s.git
     targetRevision: main
     path: apps/metallb
 

argocd/app-of-apps/app-of-apps.yaml

@@ -4,9 +4,8 @@
 # gets applied automatically, because this Application's job is to watch
 # that folder.
 #
-# Before applying this file, edit spec.source.repoURL below to point at YOUR
-# fork of this repo (Argo CD needs to clone it, so it must be a real URL it
-# can reach — not this template's URL).
+# This deployment uses the public repository at tea.ahmza.com. Every child
+# Application needs its own matching repoURL; they do not inherit this one.
 #
 # >> Ask Claude: "why does the app-of-apps live in argocd/app-of-apps
 #    instead of inside apps/ with everything else?" before moving on — the
@@ -20,7 +19,7 @@ spec:
   project: default
 
   source:
-    repoURL: https://github.com/YOUR_GITHUB_USERNAME/k8s-starter-pack.git
+    repoURL: https://tea.ahmza.com/ahmza.com/vps-k8s.git
     targetRevision: main
     path: apps
     directory:
@@ -34,6 +33,10 @@ spec:
       # subfolders" — so the app-of-apps only ever sees the Application
       # manifests, never the workloads themselves.
       recurse: false
+      # This single Hetzner node has neither a LAN MetalLB pool nor the
+      # dedicated disks/extensions expected by Longhorn. Explicitly opt in
+      # to demo only; extend this filter when adding another Application.
+      include: demo.yaml
 
   destination:
     server: https://kubernetes.default.svc

docs/04-app-of-apps.md

@@ -1,5 +1,18 @@
 # 04 — The app-of-apps pattern
 
+> **Current Hetzner deployment:** Application sources point to the public
+> `https://tea.ahmza.com/ahmza.com/vps-k8s.git` repository on `main`.
+> The app-of-apps explicitly selects only `demo.yaml` via
+> `spec.source.directory.include`; MetalLB and Longhorn remain unused
+> reference manifests, not automatic installs. The demo uses `ClusterIP`
+> (an internal-only Service address), reached via port-forward rather than
+> a public load balancer. In the steps below, commit and push the changed
+> manifests before applying the parent Application, and expect only `demo`
+> beneath it. Skip the LAN MetalLB/Longhorn phases for this setup. When
+> adding another app later, extend the parent's `include` filter too—for
+> example, `'{demo.yaml,new-app.yaml}'`. The three-app walkthrough below
+> describes the original LAN template, not this deployment.
+
 This is the last manual step. After this, Git drives everything.
 
 ## The idea