vibecarbon 0.1.2 → 0.1.4

package/carbon/docker-compose.yml

@@ -129,9 +129,31 @@ services:
       - -c
       - archive_mode=on
       - -c
-      - archive_command=/usr/local/bin/wal-g wal-push %p
+      # Fault-tolerant wrapper around `wal-g wal-push`. If wal-g fails (S3
+      # outage, bad creds, missing bucket), the wrapper retries with backoff
+      # then logs "WAL_ARCHIVE_FAILED" to stderr and exits 0 so PG can recycle
+      # the segment instead of pinning the entire pg_wal directory. Without
+      # this, a single archive failure pins WAL forever and fills the disk
+      # within days (~20 GiB/day of WAL on an idle Supabase DB given
+      # archive_timeout below, because supabase extensions like pg_cron,
+      # pg_stat_statements, realtime publications all generate background
+      # writes every minute). RCA: prod-1 2026-05-26, 58 GiB of WAL retained
+      # in 3 days because wal-g couldn't reach the configured S3 bucket;
+      # disk filled, db went into Error state, /api/v1/notifications 500'd,
+      # whole stack down. Trade-off: a persistent archive outage leaves a
+      # PITR gap, but the DB stays up — strictly better than the previous
+      # behavior for a SaaS template. Grep `docker logs db` for
+      # WAL_ARCHIVE_FAILED to detect silent backup regressions.
+      - archive_command=/etc/postgresql/wal-archive.sh %p
       - -c
-      - archive_timeout=60
+      # 60s was too aggressive — on an idle Supabase DB, that forces a
+      # 16 MiB segment switch every minute regardless of write volume (PG14+
+      # is supposed to skip empty switches but supabase's bundled extensions
+      # write enough every minute to trip it). 23 GiB/day of WAL baseline.
+      # 900s (15 min) drops baseline to ~1.5 GiB/day with an RPO cap that's
+      # plenty for SaaS workloads. Override via postgresql.conf or compose
+      # if tighter RPO is needed.
+      - archive_timeout=900
       - -c
       # hot_standby=on lets a server in recovery mode (i.e. our standby)
       # accept read-only psql connections. Required so failover's
@@ -167,6 +189,7 @@ services:
       WALG_COMPRESSION_METHOD: lz4
     volumes:
       - db_data:/var/lib/postgresql/data
+      - ./volumes/db/wal-archive.sh:/etc/postgresql/wal-archive.sh:ro,Z
       - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/98-roles.sql:Z
       - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
       - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z

package/carbon/functions/main/index.ts

@@ -0,0 +1,17 @@
+// Edge Functions main entrypoint.
+//
+// docker-compose.prod.yml starts the supabase/edge-runtime container with
+// `--main-service /home/deno/functions/main`, which requires this file to
+// exist. Without it the container crash-loops with
+// "could not find an appropriate entrypoint".
+//
+// This stub returns 404 for any path. Add real edge functions by routing in
+// the request handler below, or by mounting per-function directories under
+// functions/<name>/index.ts and updating this dispatcher.
+
+Deno.serve((_req: Request) => {
+  return new Response(
+    JSON.stringify({ error: 'No edge function configured for this path' }),
+    { status: 404, headers: { 'content-type': 'application/json' } }
+  );
+});

package/carbon/package.json

@@ -50,41 +50,41 @@
     "stripe:listen": "stripe listen --forward-to localhost:3000/api/webhooks/stripe"
   },
   "dependencies": {
-    "@base-ui/react": "^1.3.0",
+    "@base-ui/react": "^1.5.0",
     "@fontsource-variable/noto-sans": "^5.2.10",
     "@fontsource/jetbrains-mono": "^5.2.8",
     "@hono/node-server": "^1.19.13",
-    "@hono/zod-openapi": "^1.2.3",
-    "@hookform/resolvers": "^5.2.2",
+    "@hono/zod-openapi": "^1.4.0",
+    "@hookform/resolvers": "^5.4.0",
     "@mdx-js/react": "^3.1.1",
     "@mdx-js/rollup": "^3.1.1",
-    "@scalar/api-reference-react": "^0.9.15",
+    "@scalar/api-reference-react": "^0.9.41",
     "@supabase/ssr": "^0.9.0",
-    "@supabase/supabase-js": "^2.100.0",
+    "@supabase/supabase-js": "^2.106.2",
     "@tanstack/react-query": "^5.95.2",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "cmdk": "^1.1.1",
     "date-fns": "^4.1.0",
     "embla-carousel-react": "^8.6.0",
-    "framer-motion": "^12.38.0",
-    "hono": "^4.12.16",
+    "framer-motion": "^12.40.0",
+    "hono": "^4.12.23",
     "i18next": "^25.10.9",
     "i18next-browser-languagedetector": "^8.2.1",
     "input-otp": "^1.4.2",
     "ioredis": "^5.10.1",
-    "lenis": "^1.3.20",
+    "lenis": "^1.3.23",
     "lucide-react": "^1.7.0",
     "next-themes": "^0.4.6",
-    "nodemailer": "^8.0.5",
+    "nodemailer": "^8.0.8",
     "pino": "^10.3.1",
-    "react": "^19.2.4",
+    "react": "^19.2.6",
     "react-day-picker": "^9.14.0",
-    "react-dom": "^19.2.4",
+    "react-dom": "^19.2.6",
     "react-hook-form": "^7.72.0",
     "react-i18next": "^16.6.6",
-    "react-resizable-panels": "^4.7.6",
-    "react-router-dom": "^7.13.2",
+    "react-resizable-panels": "^4.11.2",
+    "react-router-dom": "^7.15.1",
     "recharts": "^3.8.1",
     "rehype-autolink-headings": "^7.1.0",
     "rehype-slug": "^6.0.0",
@@ -113,7 +113,8 @@
       "ip-address@<10.1.1": ">=10.1.1",
       "fast-uri@<3.1.2": ">=3.1.2",
       "protobufjs@<7.5.6": "^7.5.6",
-      "@protobufjs/utf8@<1.1.1": "^1.1.1"
+      "@protobufjs/utf8@<1.1.1": "^1.1.1",
+      "ws@>=8.0.0 <8.20.1": ">=8.20.1"
     },
     "peerDependencyRules": {
       "allowedVersions": {
@@ -122,33 +123,33 @@
     }
   },
   "devDependencies": {
-    "@biomejs/biome": "^2.4.9",
+    "@biomejs/biome": "^2.4.15",
     "@hono/swagger-ui": "^0.6.1",
-    "@scalar/hono-api-reference": "^0.10.5",
+    "@scalar/hono-api-reference": "^0.10.19",
     "@tailwindcss/typography": "^0.5.19",
-    "@tailwindcss/vite": "^4.2.2",
+    "@tailwindcss/vite": "^4.3.0",
     "@testing-library/jest-dom": "^6.6.3",
     "@testing-library/react": "^16.3.0",
     "@testing-library/user-event": "^14.6.1",
-    "@types/node": "^25.5.0",
-    "@types/nodemailer": "^7.0.11",
+    "@types/node": "^25.9.1",
+    "@types/nodemailer": "^8.0.0",
     "@types/pg": "^8.20.0",
-    "@types/react": "^19.2.14",
+    "@types/react": "^19.2.15",
     "@types/react-dom": "^19.2.3",
-    "@vitejs/plugin-react": "^6.0.1",
-    "@vitest/coverage-v8": "^4.1.1",
+    "@vitejs/plugin-react": "^6.0.2",
+    "@vitest/coverage-v8": "^4.1.7",
     "concurrently": "^9.2.1",
-    "esbuild": "^0.27.4",
+    "esbuild": "^0.28.0",
     "jsdom": "^26.1.0",
-    "pg": "^8.20.0",
+    "pg": "^8.21.0",
     "pino-pretty": "^13.1.3",
     "remark-gfm": "^4.0.1",
-    "shadcn": "^4.1.0",
-    "tailwindcss": "^4.2.2",
-    "tsx": "^4.21.0",
+    "shadcn": "^4.8.1",
+    "tailwindcss": "^4.3.0",
+    "tsx": "^4.22.3",
     "tw-animate-css": "^1.4.0",
-    "typescript": "^6.0.2",
-    "vite": "^8.0.5",
-    "vitest": "^4.1.1"
+    "typescript": "^6.0.3",
+    "vite": "^8.0.14",
+    "vitest": "^4.1.7"
   }
 }

package/carbon/vite.config.ts

@@ -68,7 +68,19 @@ export default defineConfig(({ mode }) => {
               return 'vendor-react';
             if (id.includes('node_modules/@supabase/')) return 'vendor-supabase';
             if (id.includes('node_modules/@tanstack/react-query')) return 'vendor-query';
-            if (id.includes('node_modules/recharts')) return 'vendor-charts';
+            // DO NOT split recharts into its own chunk. With rolldown-vite (Vite 8 +
+            // rolldown 1.x), splitting a CJS-React consumer causes rolldown to bundle
+            // a *second* copy of React inside that chunk to satisfy the CJS interop
+            // for `import * as React from 'react'`. The main entry then imports its
+            // React namespace (X.lazy, X.useState) from the recharts chunk while
+            // page chunks still import from vendor-react — two Reacts in one app.
+            // React.lazy elements created by one and rendered by the other resolve
+            // to {} and React throws minified #306 ("Lazy element type must resolve
+            // to a class or function") on first render → ErrorBoundary catches →
+            // white screen. Verified 2026-05-26 against rolldown 1.0.1 by patching
+            // the deployed vendor-react and dumping the failing lazy's payload.
+            // Leave recharts in the default chunk so React stays single-copy.
+            // if (id.includes('node_modules/recharts')) return 'vendor-charts';
             if (id.includes('node_modules/framer-motion')) return 'vendor-motion';
             if (
               id.includes('node_modules/cmdk') ||

package/carbon/volumes/db/wal-archive.sh

@@ -0,0 +1,43 @@
+#!/bin/bash
+# Fault-tolerant archive_command for Postgres + wal-g.
+#
+# Standard archive_command (`wal-g wal-push %p`) blocks WAL recycling until it
+# succeeds. If wal-g fails for any reason (S3 outage, bad credentials, bucket
+# missing, network), pg_wal grows unbounded — combined with archive_timeout
+# this fills the disk in days even on an idle DB.
+#
+# This wrapper:
+#   1. Tries `wal-g wal-push` with $RETRIES attempts and exponential backoff.
+#   2. On final failure, logs loudly to stderr (visible in `docker logs db`)
+#      and exits 0 so PG can recycle the segment. PITR coverage degrades for
+#      the failed segment; the database stays up.
+#
+# Trade-off: a persistent archive outage means a gap in your PITR chain. The
+# alternative — letting WAL fill the disk and taking the DB offline — is worse
+# for any SaaS template. Monitor for the "WAL_ARCHIVE_FAILED" line to detect
+# silent backup regressions.
+#
+# Invoked by postgres as: wal-archive.sh <wal-file-path>
+# %p is passed by Postgres and is the absolute path to the WAL segment.
+
+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
+
+# All retries exhausted. Loud, greppable log line so monitoring/alerting can
+# catch this — but exit 0 so PG recycles the segment instead of pinning it.
+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/volumes/loki/loki-config.yml

@@ -56,3 +56,11 @@ compactor:
   retention_enabled: true
   retention_delete_delay: 2h
   compaction_interval: 10m
+  # Loki 3.x requires delete_request_store when retention_enabled is true,
+  # otherwise the container fails to start with "CONFIG ERROR: invalid
+  # compactor config: compactor.delete-request-store should be configured
+  # when retention is enabled" and crash-loops. RCA: prod-1 2026-05-26,
+  # loki had been restart-looping since first deploy because of this.
+  # filesystem matches the storage_config above; switch to s3/gcs if the
+  # rest of loki storage moves off filesystem.
+  delete_request_store: filesystem

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibecarbon",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "description": "Create and manage production-ready Vibecarbon applications",
   "type": "module",
   "bin": "./src/cli.js",

package/src/lib/providers/hetzner-s3.js

@@ -355,16 +355,28 @@ export class HetznerS3Provider {
    * @param {string} bucketName - Bucket name
    */
   async deleteBucket(bucketName) {
-    for (let attempt = 0; attempt < 5; attempt++) {
+    // Hetzner's S3 returns BucketNotEmpty for some time after the last object
+    // deletion finishes propagating, even when GET/LIST already report the
+    // bucket as empty. Observed in prod-1 destroy 2026-05-26: cleanup ran,
+    // all subsequent listings returned 0 items, but DeleteBucket still raised
+    // BucketNotEmpty for >30s. Manual `aws s3api delete-bucket` minutes later
+    // succeeded immediately. Backoff schedule below totals ~90s wall time
+    // across 7 attempts — covers the consistency lag we've seen without
+    // dragging out the destroy stage on the happy path.
+    const delays = [2000, 5000, 10000, 15000, 20000, 25000, 30000];
+    let lastErr;
+    for (let attempt = 0; attempt <= delays.length; attempt++) {
       try {
         await this._send(new DeleteBucketCommand({ Bucket: bucketName }));
         return;
       } catch (err) {
+        lastErr = err;
         const isNotEmpty = err.Code === 'BucketNotEmpty' || err.message?.includes('not empty');
-        if (!isNotEmpty || attempt === 4) throw err;
-        await new Promise((r) => setTimeout(r, 3000 * (attempt + 1)));
+        if (!isNotEmpty || attempt === delays.length) throw err;
+        await new Promise((r) => setTimeout(r, delays[attempt]));
       }
     }
+    throw lastErr;
   }
 
   /**
@@ -546,7 +558,15 @@ export class HetznerS3Provider {
       // multipart API absent — covered above
     }
 
-    return parts.length > 0 ? parts.join(', ') : 'unable to list remaining contents';
+    // If all three listings succeeded and returned zero items, the bucket
+    // *appears* empty but DeleteBucket still raised BucketNotEmpty. Almost
+    // always Hetzner consistency lag — the upstream caller has already
+    // exhausted its retry budget by this point, so tell the operator how to
+    // recover instead of the generic "unable to list" message which sounds
+    // like the diagnostic itself broke.
+    return parts.length > 0
+      ? parts.join(', ')
+      : 'bucket appears empty in all listings — likely Hetzner S3 eventual-consistency lag. Wait ~60s, then retry the destroy or delete the bucket manually with `aws s3api delete-bucket --bucket <name> --endpoint-url <endpoint>`.';
   }
 
   /**