admin/0pt
5
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix(deploy): declare Coolify as the deploy target, not Vercel #8

Merged
admin merged 1 commits from fix/remove-vercel-deploy-target into main 2026-08-09 12:15:19 +00:00
Conversation 0 Commits 1 Files Changed 4
+69 -8
admin commented 2026-08-09 10:36:31 +00:00
Owner
Copy Link
Copy Source

This flips siax.config.json's deploy.target from "vercel" to "coolify", matching every sibling SIAX Cloud OS repo (n0d, st0re, aud0), and adds the missing .gitea/workflows/deploy.yml.

What was investigated first (per SIAX Cloud platform rule: no Vercel/GCP dependency for platform-owned infra)

Is 0pt.app's Vercel deployment serving real traffic? No, confirmed again live today (2026-08-09):

  • https://0pt.app/ → 200, Server: Vercel, fully-built marketing/catalog/order UI.
  • https://0pt.app/api/health → {"db":"not_configured","queue":"not_configured",...}.
  • POST /api/orders returns a plausible-looking order object, but it is not durably persisted — this repo's own docs/08-infrastructure.md and docs/architecture/ARCHITECTURE.md (independently verified 2026-07-19 and 2026-08-07) already document that lib/db.ts falls back to in-memory stores when DATABASE_URL/POSTGRES_URL are unset, which they are in the live deployment.
  • Net: a real-looking but disconnected demo/placeholder, not a live product surface with real customer data. Safe to change the declared deploy target without a cutover plan.

Does a Dockerfile "for Coolify" already exist? Yes, already committed and already correctly written (node:24-alpine multistage, non-root node user, HEALTHCHECK against /api/health, wget installed for the healthcheck) — no changes made to it.

Does .gitea/workflows/deploy.yml exist? No — added, following the exact pattern used by sax3l/n0d and sax3l/st0re (POST /api/v1/deploy?uuid=<uuid>&force=false with a COOLIFY_TOKEN bearer secret).

Is there already a Coolify app provisioned for 0pt? No — confirmed not found, and this PR does not invent one. This repo's own docs/architecture/ARCHITECTURE.md §5 already stated "Coolify-app: Ingen verifierad" as of 2026-08-07; this session could not reach the Coolify API/fleet directly to double-check (no SSH/API credentials available in this session), so that finding is carried forward rather than re-asserted independently. The new deploy.yml hardcodes a literal placeholder app UUID (TODO-no-coolify-app-provisioned-yet) and a guard step that fails the job loudly with an explicit message if the placeholder or COOLIFY_TOKEN are still unset — it will not silently deploy nowhere or hit a bogus URL.

What this PR does NOT do

  • Does not touch the live Vercel deployment or delete the Vercel project.
  • Does not move any traffic. 0pt.app keeps serving from Vercel until someone provisions a real Coolify app, sets COOLIFY_TOKEN, fills in the real app UUID, and does a DNS cutover — a separate, larger decision (see updated README.md "Deploy" section and docs/architecture/ARCHITECTURE.md §8 open question #3).
  • Does not decide the GitHub-vs-Gitea "authoritative remote" question raised elsewhere in this repo's docs — out of scope here.

Follow-up needed before this actually deploys anywhere

  1. Provision a Coolify app for 0pt on the fleet (Coolify UI at cloud.siax.io).
  2. Set the COOLIFY_TOKEN repo secret.
  3. Replace the placeholder UUID in .gitea/workflows/deploy.yml with the real app UUID.
  4. Verify, then plan the DNS/Vercel-decommission cutover separately.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

This flips `siax.config.json`'s `deploy.target` from `"vercel"` to `"coolify"`, matching every sibling SIAX Cloud OS repo (n0d, st0re, aud0), and adds the missing `.gitea/workflows/deploy.yml`. ## What was investigated first (per SIAX Cloud platform rule: no Vercel/GCP dependency for platform-owned infra) **Is 0pt.app's Vercel deployment serving real traffic?** No, confirmed again live today (2026-08-09): - `https://0pt.app/` → `200`, `Server: Vercel`, fully-built marketing/catalog/order UI. - `https://0pt.app/api/health` → `{"db":"not_configured","queue":"not_configured",...}`. - `POST /api/orders` returns a plausible-looking order object, but it is **not durably persisted** — this repo's own `docs/08-infrastructure.md` and `docs/architecture/ARCHITECTURE.md` (independently verified 2026-07-19 and 2026-08-07) already document that `lib/db.ts` falls back to **in-memory stores** when `DATABASE_URL`/`POSTGRES_URL` are unset, which they are in the live deployment. - Net: a real-looking but disconnected demo/placeholder, not a live product surface with real customer data. Safe to change the *declared* deploy target without a cutover plan. **Does a Dockerfile "for Coolify" already exist?** Yes, already committed and already correctly written (node:24-alpine multistage, non-root `node` user, `HEALTHCHECK` against `/api/health`, `wget` installed for the healthcheck) — no changes made to it. **Does `.gitea/workflows/deploy.yml` exist?** No — added, following the exact pattern used by `sax3l/n0d` and `sax3l/st0re` (`POST /api/v1/deploy?uuid=<uuid>&force=false` with a `COOLIFY_TOKEN` bearer secret). **Is there already a Coolify app provisioned for 0pt?** **No — confirmed not found**, and this PR does not invent one. This repo's own `docs/architecture/ARCHITECTURE.md` §5 already stated "Coolify-app: Ingen verifierad" as of 2026-08-07; this session could not reach the Coolify API/fleet directly to double-check (no SSH/API credentials available in this session), so that finding is carried forward rather than re-asserted independently. The new `deploy.yml` hardcodes a literal placeholder app UUID (`TODO-no-coolify-app-provisioned-yet`) and a guard step that **fails the job loudly** with an explicit message if the placeholder or `COOLIFY_TOKEN` are still unset — it will not silently deploy nowhere or hit a bogus URL. ## What this PR does NOT do - Does **not** touch the live Vercel deployment or delete the Vercel project. - Does **not** move any traffic. `0pt.app` keeps serving from Vercel until someone provisions a real Coolify app, sets `COOLIFY_TOKEN`, fills in the real app UUID, and does a DNS cutover — a separate, larger decision (see updated `README.md` "Deploy" section and `docs/architecture/ARCHITECTURE.md` §8 open question #3). - Does **not** decide the GitHub-vs-Gitea "authoritative remote" question raised elsewhere in this repo's docs — out of scope here. ## Follow-up needed before this actually deploys anywhere 1. Provision a Coolify app for `0pt` on the fleet (Coolify UI at `cloud.siax.io`). 2. Set the `COOLIFY_TOKEN` repo secret. 3. Replace the placeholder UUID in `.gitea/workflows/deploy.yml` with the real app UUID. 4. Verify, then plan the DNS/Vercel-decommission cutover separately. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
admin added 1 commit 2026-08-09 10:36:32 +00:00
fix(deploy): declare Coolify as the deploy target, not Vercel
CI (SIAX Cloud) / security (push) Successful in 18s
Details
CI (SIAX Cloud) / quality (push) Successful in 39s
Details
CI (SIAX Cloud) / quality (pull_request) Successful in 41s
Details
CI (SIAX Cloud) / security (pull_request) Successful in 19s
Details
ad042d825f 
siax.config.json declared deploy.target: "vercel", which conflicts with
the SIAX Cloud platform pattern every sibling OS repo (n0d, st0re, aud0)
follows: a Dockerfile "for Coolify" (already present in this repo) plus a
.gitea/workflows/deploy.yml that POSTs a restart to a Coolify app UUID.

Investigated before changing anything:
- 0pt.app is confirmed live on Vercel (Server: Vercel, 200 OK) but its own
  /api/health reports db/queue "not_configured", and POSTing to /api/orders
  creates an order that is not durably persisted (in-memory store only, per
  this repo's own docs/08-infrastructure.md and docs/architecture/
  ARCHITECTURE.md, both independently verified live 2026-07-19 / 2026-08-07,
  and reconfirmed live again today). It's a fully-built marketing/demo
  surface with no real backend behind it -- not a live product serving real
  customer data. Safe to change deploy config without a cutover plan.
- Dockerfile already exists and is already written "for Coolify" (node:24-
  alpine multistage, non-root, /api/health healthcheck) -- no changes needed
  there.
- No .gitea/workflows/deploy.yml existed. Added one following the exact
  pattern used by n0d and st0re (POST /api/v1/deploy?uuid=...&force=false
  with COOLIFY_TOKEN). No Coolify app has been provisioned for 0pt yet, so
  the app UUID is a literal placeholder and the workflow fails loudly by
  design until a real app + token are in place -- this does not silently
  ship a broken deploy config.

This changes only this repo's declared *intent*. It does NOT touch the live
Vercel deployment, delete the Vercel project, or move any traffic --
that cutover (provision Coolify app -> verify -> DNS -> decommission
Vercel) is a separate, larger decision. README and ARCHITECTURE.md updated
to state this plainly rather than let them contradict the new config.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
admin merged commit into main 2026-08-09 12:15:19 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
siax-bot siax-ci siax-healer (siax-healer (CI self-healing agent)) admin (Simon Axelsson)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/0pt#8