vibecarbon 0.3.0 → 0.4.0

package/carbon/db/Dockerfile

@@ -1,20 +1,31 @@
 # syntax=docker/dockerfile:1
 FROM supabase/postgres:15.8.1.085
 
-# Install WAL-G v3.0.5 — kept in lockstep with carbon/backup/Dockerfile.
+# Install WAL-G v3.0.5. This image IS the backup tooling now (both compose
+# and k8s): wal-g runs co-located with PGDATA in this container for continuous
+# WAL archiving, base backups, and restore — no separate backup image.
 # Earlier v3.0.3 URL 404'd in 2026-04-26 (alpine variant retired upstream),
 # and curl without --fail piped a 404 HTML body into tar which surfaced
 # as "not in gzip format" instead of an honest HTTP error. --fail makes
 # curl exit non-zero on 4xx/5xx so the failure is unmistakable.
 #
+# Build target MUST match the base image's glibc: supabase/postgres:15.8.1.085
+# is Ubuntu 20.04 (glibc 2.31). The ubuntu-22.04 wal-g build is linked against
+# glibc 2.35 and dies at runtime with `version 'GLIBC_2.3{2,3,4}' not found`
+# — which breaks BOTH base backups and WAL archiving (the archive_command
+# shells out to wal-g), and is invisible at deploy time because we only assert
+# archive_mode=on, never that wal-g actually runs. The ubuntu-20.04 build links
+# against glibc 2.31 and runs on this base. (RCA 2026-05-30: e2e k8s/k8s-ha
+# backup step — wal-g exited 1 with the GLIBC error inside the db pod.)
+#
 # Single RUN with `apt-get purge -y --auto-remove curl` collapses the
 # install + cleanup into one layer so the curl binary doesn't end up
 # in the published image (saving ~5MB and reducing attack surface).
 RUN apt-get update && apt-get install -y --no-install-recommends \
         curl \
         ca-certificates \
-    && curl -fL https://github.com/wal-g/wal-g/releases/download/v3.0.5/wal-g-pg-ubuntu-22.04-amd64.tar.gz | tar -xz \
-    && mv wal-g-pg-ubuntu-22.04-amd64 /usr/local/bin/wal-g \
+    && curl -fL https://github.com/wal-g/wal-g/releases/download/v3.0.5/wal-g-pg-ubuntu-20.04-amd64.tar.gz | tar -xz \
+    && mv wal-g-pg-ubuntu-20.04-amd64 /usr/local/bin/wal-g \
     && chmod +x /usr/local/bin/wal-g \
     && apt-get purge -y --auto-remove curl \
     && rm -rf /var/lib/apt/lists/*

package/carbon/docker-compose.dns01.prod.yml

@@ -0,0 +1,42 @@
+# DNS-01 ACME override — applied ONLY for managed-DNS deploys (cloudflare / hetzner).
+#
+# Activated by the deploy bundler (src/lib/deploy/bundle.js -> composeFileFlags)
+# when the deploy manages DNS via an API. It is appended AFTER
+# docker-compose.prod.yml, so the `command:` below REPLACES the base Traefik
+# command — Compose replaces sequences, it does not merge them. That means the
+# full command list must be restated here; keep every non-ACME flag in sync
+# with docker-compose.prod.yml. Only the two `httpchallenge` lines are swapped
+# for the three `dnschallenge` lines.
+#
+# Why: cloudflare/hetzner expose an API lego (Traefik's ACME client) uses to
+# solve the DNS-01 challenge by writing a TXT record. This removes the HTTP-01
+# race against A-record propagation, so the deploy no longer needs the
+# DNS-propagation poll or the Traefik cert self-heal. `manual` DNS keeps the
+# base HTTP-01 path (this override is not applied for it).
+#
+# Tokens: lego picks the provider from ACME_DNS_PROVIDER and reads its token.
+# Hetzner uses the consolidated Cloud API token HETZNER_API_TOKEN (lego v4.27+,
+# Traefik >= 3.6.6; we pin v3.6.11) — the same token as server ops. Cloudflare
+# uses CF_DNS_API_TOKEN. Both are passed through; only the active provider's
+# token is read. All three are populated in .env by the bundler.
+services:
+  traefik:
+    command:
+      - "--api.dashboard=true"
+      - "--providers.docker=true"
+      - "--providers.docker.endpoint=tcp://docker-socket-proxy:2375"
+      - "--providers.docker.exposedbydefault=false"
+      - "--providers.file.directory=/etc/traefik/dynamic"
+      - "--entrypoints.web.address=:80"
+      - "--entrypoints.websecure.address=:443"
+      - "--certificatesresolvers.letsencrypt.acme.dnschallenge=true"
+      - "--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=${ACME_DNS_PROVIDER}"
+      - "--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53"
+      - "--certificatesresolvers.letsencrypt.acme.email={{ADMIN_EMAIL}}"
+      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
+      - "--certificatesresolvers.letsencrypt.acme.caserver=${ACME_CA_SERVER:-https://acme-v02.api.letsencrypt.org/directory}"
+      - "--log.level=WARN"
+    environment:
+      ACME_DNS_PROVIDER: ${ACME_DNS_PROVIDER:-}
+      CF_DNS_API_TOKEN: ${CF_DNS_API_TOKEN:-}
+      HETZNER_API_TOKEN: ${HETZNER_API_TOKEN:-}

package/carbon/k8s/base/backup/configmap-walg.yaml

@@ -0,0 +1,47 @@
+# Fault-tolerant WAL-archive wrapper mounted into the supabase-db container at
+# /etc/postgresql/wal-archive.sh (see k8s/values/supabase.values.yaml
+# deployment.db.volumes/volumeMounts). Postgres' archive_command invokes it as
+# `bash /etc/postgresql/wal-archive.sh %p` (enabled via ALTER SYSTEM in
+# applyK3sManifests). wal-g reads WALG_S3_PREFIX / AWS_* from the db
+# container's env.
+#
+# IMPORTANT: keep this script body byte-for-byte in sync with
+# carbon/volumes/db/wal-archive.sh (the compose mount). Same retry + exit-0
+# semantics: a persistent S3 outage degrades PITR for the failed segment but
+# keeps the DB up instead of filling the disk.
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: vibecarbon-wal-archive
+  namespace: vibecarbon
+  labels:
+    app: vibecarbon-backup
+    component: backup
+data:
+  wal-archive.sh: |
+    #!/bin/bash
+    # Fault-tolerant archive_command for Postgres + wal-g.
+    # Invoked by postgres as: wal-archive.sh <wal-file-path>
+    # (%p — absolute path to the WAL segment). Retries with backoff, then
+    # logs WAL_ARCHIVE_FAILED and exits 0 so PG recycles the segment rather
+    # than pinning it and filling the disk. Keep in sync with
+    # carbon/volumes/db/wal-archive.sh.
+    set -u
+    WAL_PATH="${1:?archive_command requires a WAL file path}"
+    RETRIES="${WAL_ARCHIVE_RETRIES:-3}"
+    SLEEP_BASE="${WAL_ARCHIVE_SLEEP:-2}"
+
+    attempt=1
+    while [ "$attempt" -le "$RETRIES" ]; do
+        if /usr/local/bin/wal-g wal-push "$WAL_PATH"; then
+            exit 0
+        fi
+        if [ "$attempt" -lt "$RETRIES" ]; then
+            sleep_for=$((SLEEP_BASE ** attempt))
+            sleep "$sleep_for"
+        fi
+        attempt=$((attempt + 1))
+    done
+
+    echo "WAL_ARCHIVE_FAILED: wal-g wal-push '$WAL_PATH' failed after $RETRIES attempts; allowing PG to recycle (PITR gap for this segment)" >&2
+    exit 0

package/carbon/k8s/base/backup/cronjob.yaml

@@ -1,3 +1,17 @@
+# Nightly wal-g base backup.
+#
+# wal-g backup-push needs direct PGDATA filesystem access, which only the
+# supabase-db pod has. So instead of a separate backup container that talks to
+# postgres over the network (the old pg_dump design), this CronJob runs a tiny
+# kubectl image and `kubectl exec`s wal-g INSIDE the db pod — where wal-g, the
+# WALG_*/AWS_* env, and PGDATA already live (see k8s/values/supabase.values.yaml
+# + the WAL-archiving setup in applyK3sManifests). No bespoke backup image, no
+# sideload, no registry push.
+#
+# HA-safe: the command guards on pg_is_in_recovery()=f, so it only takes a base
+# backup on the PRIMARY. On the standby (in recovery) it no-ops, and after a
+# failover the new primary's CronJob transparently starts taking base backups —
+# no per-cluster config.
 apiVersion: batch/v1
 kind: CronJob
 metadata:
@@ -23,98 +37,59 @@ spec:
           restartPolicy: OnFailure
           serviceAccountName: backup-sa
           containers:
-          - name: backup
-            image: ghcr.io/{{GITHUB_OWNER}}/{{PROJECT_NAME}}-backup:latest
-            imagePullPolicy: Always
-            env:
-            - name: PGHOST
-              valueFrom:
-                configMapKeyRef:
-                  name: vibecarbon-config
-                  key: DB_HOST
-            - name: PGPORT
-              valueFrom:
-                configMapKeyRef:
-                  name: vibecarbon-config
-                  key: DB_PORT
-            - name: PGUSER
-              value: supabase_admin
-            - name: PGDATABASE
-              valueFrom:
-                configMapKeyRef:
-                  name: vibecarbon-config
-                  key: DB_NAME
-            - name: PGPASSWORD
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: DB_PASSWORD
-            - name: S3_ACCESS_KEY
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_ACCESS_KEY
-                  optional: true
-            - name: S3_SECRET_KEY
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_SECRET_KEY
-                  optional: true
-            - name: S3_BUCKET
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_BUCKET
-                  optional: true
-            - name: S3_ENDPOINT
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_ENDPOINT
-                  optional: true
-            - name: S3_REGION
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_REGION
-                  optional: true
-            - name: S3_BACKUP_BUCKET
-              valueFrom:
-                secretKeyRef:
-                  name: vibecarbon-secrets
-                  key: S3_BACKUP_BUCKET
-                  optional: true
-            - name: BACKUP_RETENTION_DAYS
-              valueFrom:
-                configMapKeyRef:
-                  name: vibecarbon-config
-                  key: BACKUP_RETENTION_DAYS
-                  optional: true
-            - name: STORAGE_BACKEND
-              value: file
-            # Use pg_dump (network protocol) instead of WAL-G in this
-            # CronJob — WAL-G's backup-push needs direct filesystem access
-            # to PGDATA, which only the supabase-db pod has. The backup
-            # pod runs separately and connects via PGHOST, so it has to
-            # use the libpq-based pg_dump path. Switching WAL-G on for
-            # k8s would require a sidecar inside supabase-db.
-            - name: BACKUP_MODE
-              value: pg_dump
-            - name: PROJECT_NAME
-              valueFrom:
-                configMapKeyRef:
-                  name: vibecarbon-config
-                  key: PROJECT_NAME
-            resources:
-              requests:
-                cpu: 100m
-                memory: 256Mi
-              limits:
-                cpu: 500m
-                memory: 512Mi
-            securityContext:
-              allowPrivilegeEscalation: false
+            - name: backup
+              # Pinned public kubectl image — no build/sideload/push. Bump the
+              # tag deliberately; `latest` would risk a silent client/server
+              # skew on the scheduled run. Needs bash (the script below uses
+              # `set -euo pipefail`) + kubectl on PATH, so the distroless
+              # registry.k8s.io/kubectl is unusable. Was bitnami/kubectl:1.31
+              # until Bitnami sunset their public Docker Hub catalog (2025) and
+              # the tag vanished (`not found` → ImagePullBackOff); alpine/k8s
+              # is the maintained drop-in (alpine base, bash + kubectl).
+              image: alpine/k8s:1.31.12
+              imagePullPolicy: IfNotPresent
+              env:
+                - name: BACKUP_RETENTION_DAYS
+                  valueFrom:
+                    configMapKeyRef:
+                      name: vibecarbon-config
+                      key: BACKUP_RETENTION_DAYS
+                      optional: true
+              command:
+                - /bin/bash
+                - -c
+                - |
+                  set -euo pipefail
+                  RETAIN="${BACKUP_RETENTION_DAYS:-7}"
+                  # Exec wal-g inside the db pod. The guard makes this a no-op on
+                  # a standby (in recovery) so only the primary takes base backups.
+                  kubectl exec -n vibecarbon statefulset/supabase-supabase-db -- bash -c '
+                    set -euo pipefail
+                    # wal-g backup-push connects to Postgres (pg_backup_start) using
+                    # libpq env. Unset, PGUSER defaults to the container OS user
+                    # "root" → "role \"root\" does not exist". And only the cluster
+                    # superuser may call pg_backup_start — supabase_admin is the sole
+                    # superuser ("postgres" gets "permission denied for function
+                    # pg_backup_start"). So pin the libpq connection explicitly.
+                    # (wal-push/archiving and backup-fetch/restore do not connect to
+                    # PG, which is why this only bit backup-push. RCA 2026-05-30.)
+                    export PGUSER=supabase_admin PGHOST=localhost PGPORT=5432 PGDATABASE=postgres
+                    if [ "$(psql -U supabase_admin -d postgres -tAc "SELECT pg_is_in_recovery()")" != "f" ]; then
+                      echo "supabase-db is in recovery (standby) — skipping base backup."
+                      exit 0
+                    fi
+                    wal-g backup-push "$PGDATA"
+                    wal-g delete retain FULL '"${RETAIN}"' --confirm
+                  '
+              resources:
+                requests:
+                  cpu: 50m
+                  memory: 64Mi
+                limits:
+                  cpu: 250m
+                  memory: 128Mi
+              securityContext:
+                allowPrivilegeEscalation: false
           securityContext:
             seccompProfile:
               type: RuntimeDefault

package/carbon/k8s/base/backup/kustomization.yaml

@@ -2,6 +2,7 @@ apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 
 resources:
+  - configmap-walg.yaml
   - cronjob.yaml
   - rbac.yaml
   - network-policy.yaml

package/carbon/k8s/base/backup/network-policy.yaml

@@ -1,3 +1,9 @@
+# The backup CronJob pod no longer talks to postgres:5432 or S3 directly — it
+# runs `kubectl exec` into the supabase-db pod (wal-g runs there). So its only
+# egress need is the Kubernetes apiserver. DNS + intra-namespace egress come
+# from the cluster-baseline policies (network-policies.yaml, podSelector {}).
+# The wal-g → S3 egress now happens from the supabase-db pod, allowed by the
+# supabase-db-s3-egress policy in network-policies.yaml.
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
@@ -10,22 +16,11 @@ spec:
   policyTypes:
     - Egress
   egress:
-    # Connect to PostgreSQL for pg_dump
-    - to:
-        - podSelector:
-            matchLabels:
-              app: vibecarbon-postgres
-      ports:
-        - protocol: TCP
-          port: 5432
-    # Upload to S3 (external HTTPS)
+    # Kubernetes apiserver (kubernetes.default → ClusterIP 10.43.0.1:443) so
+    # `kubectl exec` works. Mirrors the app/traefik apiserver-egress pattern.
     - to:
         - ipBlock:
-            cidr: 0.0.0.0/0
-            except:
-              - 10.0.0.0/8
-              - 172.16.0.0/12
-              - 192.168.0.0/16
+            cidr: 10.43.0.1/32
       ports:
         - protocol: TCP
           port: 443

package/carbon/k8s/base/backup/rbac.yaml

@@ -5,3 +5,43 @@ metadata:
   labels:
     app: vibecarbon-backup
     component: backup
+---
+# The backup CronJob runs `kubectl exec` into the supabase-db pod to invoke
+# wal-g backup-push (wal-g needs local PGDATA access). That requires
+# pods/exec in the vibecarbon namespace. `pods` get/list is needed so
+# `kubectl exec statefulset/...` can resolve the pod.
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: backup-exec
+  namespace: vibecarbon
+  labels:
+    app: vibecarbon-backup
+    component: backup
+rules:
+  - apiGroups: [""]
+    resources: ["pods"]
+    verbs: ["get", "list"]
+  - apiGroups: [""]
+    resources: ["pods/exec"]
+    verbs: ["create"]
+  - apiGroups: ["apps"]
+    resources: ["statefulsets"]
+    verbs: ["get"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: backup-exec
+  namespace: vibecarbon
+  labels:
+    app: vibecarbon-backup
+    component: backup
+subjects:
+  - kind: ServiceAccount
+    name: backup-sa
+    namespace: vibecarbon
+roleRef:
+  kind: Role
+  name: backup-exec
+  apiGroup: rbac.authorization.k8s.io

package/carbon/k8s/base/network-policies.yaml

@@ -93,3 +93,36 @@ spec:
           port: 53
         - protocol: TCP
           port: 53
+
+---
+# Allow the supabase-db pod to egress to S3 (HTTPS) for wal-g: continuous WAL
+# archiving (archive_command → wal-g wal-push) and the nightly base backup
+# (kubectl exec → wal-g backup-push) both run INSIDE the db container and push
+# to Hetzner Object Storage. Without this, the implicit default-deny-egress
+# (allow-dns/allow-intra-namespace-egress select all pods with Egress type)
+# drops the db pod's outbound 443 and wal-g hangs/fails.
+# Selector matches the chart-generated db pod labels; base kustomize `labels:`
+# does not include selectors, so these are not mutated.
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: supabase-db-s3-egress
+  namespace: vibecarbon
+spec:
+  podSelector:
+    matchLabels:
+      app.kubernetes.io/name: supabase-db
+      app.kubernetes.io/instance: supabase
+  policyTypes:
+    - Egress
+  egress:
+    - to:
+        - ipBlock:
+            cidr: 0.0.0.0/0
+            except:
+              - 10.0.0.0/8
+              - 172.16.0.0/12
+              - 192.168.0.0/16
+      ports:
+        - protocol: TCP
+          port: 443

package/carbon/k8s/values/supabase.values.yaml

@@ -54,6 +54,18 @@ secret:
       password: DB_PASSWORD
       database: DB_NAME
 
+# Override the db image with vibecarbon's wal-g-equipped build (carbon/db/
+# Dockerfile: FROM supabase/postgres + wal-g v3.0.5). The stock chart image
+# has no wal-g, which is why k8s historically had no WAL archiving / PITR.
+# Built + sideloaded to the supabase node by deployK3s (k3s-db-build /
+# k3s-db-sideload); IfNotPresent so the sideloaded image is used, not pulled.
+# {{DB_IMAGE}}/{{DB_IMAGE_TAG}} substituted at deploy time in installSupabase.
+image:
+  db:
+    repository: "{{DB_IMAGE}}"
+    tag: "{{DB_IMAGE_TAG}}"
+    pullPolicy: IfNotPresent
+
 # Component enable toggles — chart's path is deployment.<comp>.enabled.
 # Top-level `functions:`/`analytics:`/`vector:` are silently ignored
 # (was the bug behind the 2026-04-26 e2e helm-wait timeout).
@@ -81,6 +93,121 @@ deployment:
         operator: Equal
         value: supabase
         effect: NoSchedule
+    # Headroom for the daily wal-g base backup, which runs INSIDE this
+    # container's cgroup (via `kubectl exec`, see k8s/base/backup/cronjob.yaml).
+    # backup-push streams PGDATA → lz4 → S3; size the limit for the backup
+    # window, not steady state, or it throttles postgres too. WALG_UPLOAD_
+    # CONCURRENCY is kept at 2 (vs compose's 4) to bound the burst.
+    resources:
+      requests:
+        cpu: 250m
+        memory: 512Mi
+      limits:
+        cpu: "2"
+        memory: 2Gi
+    # Mount the fault-tolerant WAL-archive wrapper that postgres'
+    # archive_command calls (enabled at runtime via ALTER SYSTEM in
+    # applyK3sManifests). Script body lives in the vibecarbon-wal-archive
+    # ConfigMap (k8s/base/backup/configmap-walg.yaml) — verbatim copy of
+    # carbon/volumes/db/wal-archive.sh (retry + exit-0 prevents disk-fill).
+    volumeMounts:
+      - name: wal-archive-script
+        mountPath: /etc/postgresql/wal-archive.sh
+        subPath: wal-archive.sh
+        readOnly: true
+      - name: walg-s3-creds
+        mountPath: /etc/walg
+        readOnly: true
+    volumes:
+      - name: wal-archive-script
+        configMap:
+          # Invoked as `bash /etc/postgresql/wal-archive.sh` (archive_command),
+          # so no exec bit is required on the mounted file.
+          name: vibecarbon-wal-archive
+      - name: walg-s3-creds
+        secret:
+          secretName: vibecarbon-secrets
+          # Optional so a no-S3 (dev) deploy still schedules the db pod; wal-g
+          # is simply unconfigured then. items maps the INI key → credentials.
+          optional: true
+          items:
+            - key: S3_CREDENTIALS_INI
+              path: credentials
+    # Restore bootstrap: a marker-gated init container that, ONLY when a
+    # restore is requested (RESTORE_TARGET set in vibecarbon-secrets), fetches
+    # the latest wal-g base backup into PGDATA before postgres starts. On a
+    # normal boot RESTORE_TARGET is empty and the init container is a no-op.
+    # Uses the same wal-g-equipped db image. RESTORE_TARGET is an OPTIONAL
+    # secretKeyRef so deploys without the key still schedule.
+    extraInitContainers:
+      - name: walg-restore
+        image: "{{DB_IMAGE}}:{{DB_IMAGE_TAG}}"
+        imagePullPolicy: IfNotPresent
+        command:
+          - /bin/bash
+          - -c
+          - |
+            set -euo pipefail
+            if [ -z "${RESTORE_TARGET:-}" ]; then
+              echo "walg-restore: RESTORE_TARGET empty — normal boot, skipping."
+              exit 0
+            fi
+            echo "walg-restore: RESTORE_TARGET=${RESTORE_TARGET} — restoring from S3."
+            if [ -f "${PGDATA}/PG_VERSION" ]; then
+              echo "walg-restore: existing PGDATA — clearing for backup-fetch."
+              rm -rf "${PGDATA:?}/"* "${PGDATA:?}/".* 2>/dev/null || true
+            fi
+            # Fetch the latest base backup into PGDATA. (For PITR the base that
+            # precedes the target is also the latest base — base backups are
+            # frequent, so LATEST is the right starting point either way.)
+            wal-g backup-fetch "${PGDATA}" LATEST
+            # Configure archive recovery. A fetched base backup is only
+            # consistent AFTER replaying the WAL from its redo point to its
+            # stop point — and that WAL lives in S3, not in the fetched PGDATA.
+            # Without restore_command + recovery.signal postgres aborts startup
+            # with "could not locate required checkpoint record" (the bug this
+            # fixes — the `latest` branch previously did neither). restore_command
+            # pulls each segment back from S3 via `wal-g wal-fetch`; recovery.signal
+            # puts postgres into archive recovery; on reaching the end of WAL (or
+            # the PITR target) it promotes to read-write. (RCA 2026-05-31: e2e
+            # k8s/k8s-ha restore — postgres crash-looped post-fetch.)
+            {
+              echo "restore_command = 'wal-g wal-fetch \"%f\" \"%p\"'"
+              echo "recovery_target_action = 'promote'"
+              if [ "${RESTORE_TARGET}" != "latest" ]; then
+                # PITR: RESTORE_TARGET is an ISO-8601 timestamp — replay only up
+                # to that point instead of to the end of the WAL stream.
+                echo "recovery_target_time = '${RESTORE_TARGET}'"
+              fi
+            } >> "${PGDATA}/postgresql.auto.conf"
+            touch "${PGDATA}/recovery.signal"
+            echo "walg-restore: backup-fetch complete; archive recovery configured."
+        env:
+          - name: PGDATA
+            value: /var/lib/postgresql/data
+          - name: RESTORE_TARGET
+            valueFrom:
+              secretKeyRef:
+                name: vibecarbon-secrets
+                key: RESTORE_TARGET
+                optional: true
+          - name: WALG_S3_PREFIX
+            value: "{{WALG_S3_PREFIX}}"
+          - name: WALG_COMPRESSION_METHOD
+            value: lz4
+          - name: AWS_ENDPOINT
+            value: "{{S3_ENDPOINT}}"
+          - name: AWS_REGION
+            value: "{{S3_REGION}}"
+          - name: AWS_SHARED_CREDENTIALS_FILE
+            value: /etc/walg/credentials
+        volumeMounts:
+          - name: postgres-volume
+            mountPath: /var/lib/postgresql/data
+            subPath: postgres-data
+          - name: walg-s3-creds
+            mountPath: /etc/walg
+            readOnly: true
 
 # Per-component environment — chart's path is environment.<comp>.
 environment:
@@ -99,6 +226,23 @@ environment:
     GOTRUE_MAILER_AUTOCONFIRM: "true"
   realtime:
     DB_NAME: postgres
+  # Non-secret WAL-G env for the db container (continuous WAL archiving +
+  # the exec'd base-backup CronJob both read these). The chart renders
+  # environment.<comp> as plain `value:` strings (no valueFrom), so the
+  # SECRET keys (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY) are injected
+  # separately via a StatefulSet env patch in applyK3sManifests.
+  # {{WALG_S3_PREFIX}} resolves to s3://<backup-bucket|storage-bucket>/
+  # backups/<project>/walg (fallback handled in installSupabase).
+  db:
+    WALG_S3_PREFIX: "{{WALG_S3_PREFIX}}"
+    WALG_COMPRESSION_METHOD: lz4
+    WALG_UPLOAD_CONCURRENCY: "2"
+    AWS_ENDPOINT: "{{S3_ENDPOINT}}"
+    AWS_REGION: "{{S3_REGION}}"
+    # wal-g (AWS SDK) reads S3 creds from this INI file, mounted from
+    # vibecarbon-secrets (deployment.db.volumes below). File-mount, not env,
+    # so it's helm-owned and survives every upgrade with no db restart.
+    AWS_SHARED_CREDENTIALS_FILE: /etc/walg/credentials
   storage:
     STORAGE_BACKEND: s3
   imgproxy:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibecarbon",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Create and manage production-ready Vibecarbon applications",
   "type": "module",
   "bin": "./src/cli.js",
@@ -76,7 +76,8 @@
       "fast-xml-builder@<1.1.7": ">=1.1.7",
       "ip-address@<10.1.1": ">=10.1.1",
       "protobufjs@<7.5.6": "^7.5.6",
-      "@protobufjs/utf8@<1.1.1": "^1.1.1"
+      "@protobufjs/utf8@<1.1.1": "^1.1.1",
+      "tmp@<0.2.6": ">=0.2.6"
     }
   },
   "devDependencies": {
@@ -88,7 +89,6 @@
     "autocannon": "^8.0.0",
     "better-sqlite3": "^12.8.0",
     "conventional-changelog-conventionalcommits": "^9.3.1",
-    "msw": "^2.12.14",
     "semantic-release": "^25.0.3",
     "tsx": "^4.21.0",
     "vite": "^8.0.14",