.gitea/workflows/deploy.yml

@@ -0,0 +1,44 @@
+name: Deploy to Coolify
+
+# Follows the fleet-wide pattern used by sax3l/n0d and sax3l/st0re: push to
+# main triggers a POST to Coolify's deploy endpoint for this app's UUID,
+# authenticated with the COOLIFY_TOKEN repo secret. Coolify already has the
+# Dockerfile (build_pack: dockerfile) -- this workflow only fires the
+# rebuild+redeploy, it doesn't build or push an image itself.
+#
+# STATUS (2026-08-09): no Coolify application has been provisioned for 0pt
+# yet -- siax.config.json's `deploy.target` was flipped from "vercel" to
+# "coolify" to state the intended platform, but there is no app UUID to
+# point at. COOLIFY_APP_ID below is a literal placeholder. The guard step
+# fails the job loudly (rather than silently POSTing to a bogus/empty URL)
+# until both the Coolify app exists and its real UUID replaces the
+# placeholder here. See docs/architecture/ARCHITECTURE.md §5/§8 for the
+# open "Vercel or fleet" question this resolves the config side of.
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    env:
+      COOLIFY_APP_ID: "TODO-no-coolify-app-provisioned-yet"
+    steps:
+      - name: Guard against unset token / placeholder app id
+        run: |
+          if [ -z "${{ secrets.COOLIFY_TOKEN }}" ]; then
+            echo "::error::COOLIFY_TOKEN secret is not set on this repo -- cannot redeploy."
+            exit 1
+          fi
+          if [ "$COOLIFY_APP_ID" = "TODO-no-coolify-app-provisioned-yet" ]; then
+            echo "::error::No Coolify app has been provisioned for 0pt yet. Create the app in the Coolify UI (cloud.siax.io), copy its UUID into COOLIFY_APP_ID in this file, and set the COOLIFY_TOKEN repo secret before this workflow can deploy anything."
+            exit 1
+          fi
+      - name: Trigger Coolify redeploy
+        env:
+          COOLIFY_TOKEN: ${{ secrets.COOLIFY_TOKEN }}
+        run: |
+          curl -fsS -X POST \
+            "https://cloud.siax.io/api/v1/deploy?uuid=${COOLIFY_APP_ID}&force=false" \
+            -H "Authorization: Bearer $COOLIFY_TOKEN" \
+            -o /dev/null -w 'coolify deploy HTTP %{http_code}\n'

README.md

@@ -50,7 +50,18 @@ cd services/api && pip install -r requirements.txt && uvicorn orchestrator.main:
 ```
 
 ## Deploy
-- **Frontend** → Vercel (project `0pt`, scope *Simon Axelsson's projects*), domain `0pt.app`.
+- **Config target (as of 2026-08-09):** `siax.config.json` declares `deploy.target: "coolify"`,
+  matching every other SIAX Cloud OS repo (n0d, st0re, aud0, ...) — a Dockerfile "for Coolify"
+  (already committed, see [`Dockerfile`](Dockerfile)) plus [`.gitea/workflows/deploy.yml`](.gitea/workflows/deploy.yml)
+  that POSTs a restart to a Coolify app UUID on `COOLIFY_TOKEN` push.
+- **Actually live right now:** the only running instance of `0pt.app` is still on **Vercel**
+  (project `0pt`, scope *Simon Axelsson's projects*) — no Coolify app has been provisioned for
+  this repo yet, so `deploy.yml`'s app UUID is a placeholder that fails the job on purpose until
+  someone fills it in. Flipping the config declares intent; it does not move traffic. See
+  [`docs/architecture/ARCHITECTURE.md`](docs/architecture/ARCHITECTURE.md) §5/§8 for the full
+  "Vercel or fleet" state and what's still open (Coolify app provisioning + DNS cutover — a
+  separate decision from this config change, since the live Vercel deployment is not being
+  touched).
 - **Engine + DB + embeds** → one VPS via [`infra/docker-compose.yml`](infra/docker-compose.yml) (Postgres+pgvector, Redis, api, worker, NocoDB, Metabase, Caddy).
 - Env inventory: [`.env.example`](.env.example).
 - **Auth on `/api/0pt/*` is fail-closed**: with `AUTH_ENFORCE` unset the middleware

docs/architecture/ARCHITECTURE.md

@@ -206,7 +206,7 @@ inget sådant jobb, ingen TTL, ingen `DELETE`-väg och ingen radering finns i ko
 | Fält | Verifierat läge |
 |---|---|
 | **Nod** | Ingen SIAX-nod. *(live-verifierat 2026-08-07: `https://0pt.app/api/health` → `Server: Vercel`, `X-Vercel-Id: arn1::iad1::…`)* Frontenden körs alltså på **Vercel**, inte på flottan. |
-| **Coolify-app** | Ingen verifierad. `Dockerfile` är skriven för Coolify (node:24-alpine, multistage, `HEALTHCHECK` mot `/api/health`, kör som `node`-användare) men **OKÄNT** om någon Coolify-app pekar på repot. |
+| **Coolify-app** | Ingen verifierad — fortfarande **OKÄNT** om någon Coolify-app pekar på repot (2026-08-09: `git.siax.io/sax3l/0pt` genomsökt, ingen egen fleet-åtkomst att fråga Coolify API direkt denna pass). `Dockerfile` är skriven för Coolify (node:24-alpine, multistage, `HEALTHCHECK` mot `/api/health`, kör som `node`-användare). `siax.config.json` deklarerar nu `deploy.target: "coolify"` (ändrat från `"vercel"` 2026-08-09, PR i `fix/remove-vercel-deploy-target`) och ett nytt `.gitea/workflows/deploy.yml` finns, ported från n0d/st0re-mönstret — men appens UUID i den filen är en medveten platshållare som får jobbet att faila högljutt tills en riktig Coolify-app skapats och tokens/uuid fyllts i. Config-flippen ändrar alltså **avsikt**, inte trafik. |
 | **Domän** | `0pt.app` (live). Docs nämner även `api.0pt.app`, `data.0pt.app`, `dash.0pt.app` via Caddy — **ej verifierade**. |
 | **Bygg** | `next build` via pnpm@9. `next.config.mjs` sätter `typescript.ignoreBuildErrors: true` — bygget typkontrollerar alltså **inte** `app/`, `components/`, `lib/` eller `middleware.ts`. |
 | **Engine-deploy** | `infra/docker-compose.yml` (postgres, redis, api, worker, nocodb, metabase, caddy) och `services/infra/docker-compose.data-stack.yml` (clickhouse, trino, flaresolverr, tor-proxy, superset, postgres). **Ingen av dem är verifierad som körande.** |
@@ -386,11 +386,17 @@ bindning till en användarpost. Kommentaren erkänner att det är ett scaffold;
    `CLAUDE.md` säger uttryckligen "remove or disable it". Commit `4a164c5` gick
    åt motsatt håll. Detta är ett Simon-beslut med både juridisk och
    marknadsföringsmässig innebörd — inte något en session ska avgöra ensidigt.
-3. **Vercel eller flottan?** 0pt:s enda körande instans ligger på Vercel medan
-   estate-projektet *GCP/Vercel-exit* pekar bort därifrån. `Dockerfile` är redan
-   Coolify-anpassad men ingen nod är tilldelad. `siax.config.json` i det här
-   repot deklarerar därför `target: "vercel"`, `node: null` — det är dagens
-   sanning, inte målbilden.
+3. **Vercel eller flottan?** *(config-delen löst 2026-08-09, trafik-delen kvarstår.)*
+   0pt:s enda **körande** instans ligger fortfarande på Vercel — den ändringen är
+   medvetet INTE gjord här (skulle kräva en egen cutover-plan: verifiera att inget
+   riktigt kunddata/trafik ligger bakom `0pt.app` — vilket är fallet idag, se §5/§6:
+   `/api/health` visar `db/queue: not_configured`, ordrar lever bara in-memory —
+   provisionera en Coolify-app, peka DNS om, och avveckla Vercel-projektet, i den
+   ordningen). Det som ÄR gjort: `siax.config.json` deklarerar nu `target: "coolify"`
+   (matchar varje annat SIAX Cloud OS-repo) och `.gitea/workflows/deploy.yml` finns
+   med en medveten platshållar-UUID som failar tills en riktig Coolify-app skapats.
+   Ingen nod är tilldelad (`node: null`, matchar st0re/aud0:s mönster). Se README
+   "Deploy" för samma sammanfattning.
 4. **Ska capability-lagret vara i drift alls?** Det är exponerat publikt men helt
    in-memory och utan delad state mellan routemoduler (§4.2). Antingen backas det
    av Postgres, eller så bör routes stängas tills dess.

siax.config.json

@@ -6,7 +6,7 @@
   "packageName": "@siax/0pt",
   "capabilityPrefix": "0pt",
   "deploy": {
-    "target": "vercel",
+    "target": "coolify",
     "node": null,
     "domain": "0pt.app",
     "healthPath": "/api/health"