Artisanal Futures

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

  1. Open a PR and merge it into the development branch. This powers staging: live previews and debugging against a live environment.
  2. When development is ready to ship, merge it into main to 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-products

Suggested 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:

  1. Add any new environment variables to the deployment platform first (a deploy that boots against missing required env vars fails validation).
  2. Deploy the code.
  3. Run prisma db push --schema ./prisma against the target environment's database — staging after merging to development, production after merging to main.

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).

On this page