diff --git a/.gitea/workflows/deploy.yml b/.gitea/workflows/deploy.yml new file mode 100644 index 0000000..89d12d1 --- /dev/null +++ b/.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' diff --git a/README.md b/README.md index 9608f26..355eca4 100644 --- a/README.md +++ b/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 diff --git a/docs/architecture/ARCHITECTURE.md b/docs/architecture/ARCHITECTURE.md index 851173a..f201717 100644 --- a/docs/architecture/ARCHITECTURE.md +++ b/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. diff --git a/siax.config.json b/siax.config.json index e2c1b55..0d92ed7 100644 --- a/siax.config.json +++ b/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"