The course and backend deploy separately
The course is a Docusaurus site. Its production build produces HTML, JavaScript, CSS, and static source-reference data. A visitor can read the lessons without connecting to Taskboard's API.
Cloudflare Pages can build and serve that output. Its Docusaurus guide uses a build command and a static output directory. In this monorepo, the course's build output is course/build, relative to the repository root. Cloudflare's Docusaurus deployment guide.
Static hosting has a different job
Publishing the course does not start Express, execute job polling, or provision Postgres. The backend needs an environment that runs Node processes, maintains database connectivity, supports the intended realtime transport, and supplies secrets.
Cloudflare Pages: built course files
API runtime: Express and Socket.IO process
Worker runtime: durable job polling process
Database service: Postgres and persistent storage
External providers: production SMTP and configured Stripe
The course's build-time source browser must exclude runtime secrets. API keys never belong in browser bundles or public deployment environment variables used to generate client assets.
Deploy schema changes deliberately
A release includes code and database migrations. Running migrations once as a release step prevents several replicas from independently racing through schema changes. A failed migration should stop rollout rather than leave new code serving against an incompatible schema.
During a rolling deploy, old and new API processes can overlap. Renaming or deleting a column immediately may break the old process. An expand-and-contract migration adds a compatible structure, moves readers and writers, and removes obsolete structures in a later release.
Code rollback is not automatically database rollback. Data written under a new schema may be incompatible with old code, and destructive migrations may be irreversible without restoration. A rollback plan must describe both code compatibility and data consequences.
Production config validates required secrets and origins at startup. Missing configuration should fail visibly before the service accepts traffic. Development defaults support local reading and verification; they must not silently become production credentials.
Read configuration in Read api/src/config.ts and migration handling in Read api/src/migrate.ts.
Deploy the static course independently. Backend releases need running services, private configuration, and a schema migration plan.
Will a successful Docusaurus build prove the API can accept payments?
No. It proves the course compiled. Payment acceptance also requires backend hosting, Stripe configuration, endpoint registration, and provider-side verification.