Deployment
How the Artisanal Futures site and its docs deploy.
Coolify
Deployment runs through Coolify (our self-hosted deployment platform) — there is no GitHub Actions CI in the artisanal-futures-site repo. Coolify redeploys the branch it watches whenever it's merged into.
Branch flow
- Open a PR and merge it into the
developmentbranch. This powers staging: live previews and debugging against a live environment. - When
developmentis ready to ship, merge it intomainto deploy to production.
Environment variables
All environment variables for both the staging and production environments are managed directly in the deployment platform — not in CI, and not in any repo file. See Setup for how to get local .env values.
Scheduled product sync
Weekly product sync is driven by a Coolify Scheduled Task on the app resource — not by anything in this repo — that POSTs to the app's own cron endpoint:
curl -fsS --max-time 900 -X POST \
-H "Authorization: Bearer $CRON_SECRET" \
http://localhost:3000/api/cron/sync-productsSuggested schedule: 0 4 * * 1 (Mondays at 4am). Set CRON_SECRET as an environment variable in the deployment platform, at least 32 characters — generate one with openssl rand -hex 32. If CRON_SECRET is unset, the endpoint returns 503 and scheduled sync is simply off; the request is rate-limited before the bearer token is even checked. The endpoint only plans sync runs (runScheduledSync) — it never writes to the catalog, so a misconfigured or duplicated schedule can't do more than queue extra review work for an admin.
As with everything else here, the Scheduled Task itself lives in Coolify, not in this repo — see the infrastructure doc on the team Google Drive for hosting-panel specifics.
Deploying schema changes
The staging and production databases are push-managed — schema changes are applied with prisma db push, not prisma migrate deploy (the migration history can't replay cleanly there; migration files in prisma/migrations/ document intent only — see Database).
When a deploy includes Prisma schema changes, the database step is manual and ordered:
- Add any new environment variables to the deployment platform first (a deploy that boots against missing required env vars fails validation).
- Deploy the code.
- Run
prisma db push --schema ./prismaagainst the target environment's database — staging after merging todevelopment, production after merging tomain.
Never run db:migrate / prisma migrate deploy against the staging or production databases, and never migrate reset or db push --force-reset anywhere shared. db push is additive here by convention — review its warnings before accepting.
The same rule applies locally to the docs pipeline's af_docs database: after pulling schema-changing commits, re-push before running pnpm docs:seed / pnpm docs:shots (see the runbook in e2e/README.md).
The docs site deploys separately
This documentation site (af-documentation repo) is a separate Next.js app with its own deploy: merging to its main branch builds and publishes to docs.artisanalfutures.org. It is not deployed by, or coupled to, the main site's Coolify project.
For infrastructure specifics — hosting panel access, server details, DNS — see the infrastructure doc on the team Google Drive (ask the senior software dev for access).