Deployment Plan

Toodle is deployed as separate frontend, backend, database, authentication and documentation services. Keeping these components separate makes the system easier to maintain, update and deploy independently.

Deployment Architecture

flowchart LR
    U[User Browser]
    F[React Frontend - Vercel]
    A[Express API - Render]
    DB[(PostgreSQL - Supabase)]
    AUTH[Auth0]
    DOCS[MkDocs - Cloudflare Pages]

    U --> F
    F --> AUTH
    F --> A
    A --> DB
    U --> DOCS

Deployment Components

Component	Technology	Hosting	Status
Frontend	React + Vite	Vercel	✅ Deployed
Backend API	Node.js + Express	Render	🟡 Verify production deployment
Database	PostgreSQL	Supabase	✅ Established
Authentication	Auth0 + Google Sign-In	Auth0	✅ Working
Documentation	MkDocs Material	Cloudflare Pages	✅ Deployed

The backend deployment on Render should be confirmed against the team's current production configuration before being marked as fully deployed.

Application Deployment

The Toodle application is separated into several services:

• the React frontend is deployed on Vercel;
• the Express REST API is intended to be hosted on Render;
• the PostgreSQL database is hosted through Supabase;
• authentication is provided by Auth0; and
• the documentation site is hosted on Cloudflare Pages.

This separation allows the frontend, API and database to be updated independently.

Frontend Deployment

The React frontend is deployed on Vercel.

The deployed application is currently accessible online and has been successfully used to authenticate through Auth0 using Google Sign-In.

This confirms that the deployed frontend and authentication service are communicating successfully.

Documentation Deployment

The documentation site is deployed publicly using Cloudflare Pages.

The deployment process is automated through the documentation repository:

1. documentation changes are reviewed and merged;
2. stable documentation is merged into main;
3. the deployment workflow runs;
4. MkDocs builds the static documentation site; and
5. the generated site is deployed to Cloudflare Pages.

Before deployment, the documentation must successfully pass:

python -m mkdocs build --strict

This helps detect configuration, navigation and documentation build errors before they reach the live site.

Database Deployment

Toodle uses a hosted PostgreSQL database through Supabase.

The database stores the main information required by the system, including:

• users;
• courses;
• tutor marks;
• availability;
• allocations;
• course sessions;
• timesheets;
• excusals;
• overflow work;
• notifications; and
• audit records.

The backend communicates with the database through Prisma.

Authentication Deployment

Authentication is provided through Auth0, with Google Sign-In available to users.

The deployed Vercel frontend has been successfully tested with Google authentication through Auth0.

After login, the application is able to recognise the authenticated user's role. A student account has been successfully identified with the STUDENT role.

Authentication credentials and other sensitive configuration values are stored using environment variables rather than directly in the source code.

Environment Configuration

Different deployment environments require configuration values such as:

• database connection details;
• Auth0 configuration;
• API URLs;
• frontend URLs; and
• deployment credentials.

These values must be stored as environment variables or platform secrets.

Sensitive .env files must not be committed to Git.

Deployment Checks

Before a production deployment, the team should verify that:

• the application builds successfully;
• configured automated tests pass;
• required environment variables are available;
• authentication works;
• frontend requests reach the deployed API;
• the API can communicate with the database;
• role-based access works correctly; and
• no secrets have been committed to the repository.

Deployment Failure Handling

If a deployment fails:

1. review the deployment logs;
2. identify the failing build, configuration or environment variable;
3. correct the issue on an appropriate branch;
4. repeat local validation;
5. review the fix through a Pull Request; and
6. deploy the corrected version.

Where supported by the hosting platform, a previous stable deployment can be used while the problem is resolved.

Why This Approach?

Toodle uses a separated deployment architecture because the frontend, API, database and authentication service have different responsibilities.

Deploying them independently:

• avoids tightly coupling the entire system;
• makes failures easier to isolate;
• allows individual services to be updated separately; and
• supports a clearer development and deployment workflow.

Automated validation and review before deployment also reduce the risk of broken changes reaching users.