Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/azahel79/Spartans-gym/llms.txt

Use this file to discover all available pages before exploring further.

Deploying Spartans Gym to production involves four independent concerns: provisioning a MySQL database, deploying the Node.js backend, publishing the static frontend, and wiring the two together through environment variables and CORS configuration. This guide walks through each concern in sequence, ending with a full production checklist and backup recommendations sourced directly from the project’s PRODUCTION_DEPLOY.md.

Required Services

Before you write a single environment variable, confirm you have access to the following infrastructure:

MySQL 8+ Database

A managed MySQL instance. Railway, PlanetScale, and AWS RDS are all supported. The user in DATABASE_URL must have CREATE, ALTER, and DROP privileges for Prisma migrations.

Node.js Hosting

Any platform that can run a Node.js 20+ process or a Docker container. Railway (with its built-in Docker support) is the recommended choice.

Static Hosting

Netlify, Vercel, or Cloudflare Pages for the compiled dist/ output. All three support the SPA fallback rewrite required for client-side routing.

HTTPS Domain

A domain with TLS termination. Never serve Spartans Gym over plain HTTP in production — JWT cookies and API requests must travel over HTTPS.
A Cloudinary account is required only if you intend to use logo or product image uploads. The rest of the application works without it.

Environment Variables

Backend (backend/.env)

Set these variables in your hosting provider’s environment dashboard — never in a committed file.
VariableRequiredDescription
NODE_ENVMust be production
PORTPort the Express server listens on (default 3000)
DATABASE_URLFull MySQL connection string: mysql://USER:PASSWORD@HOST:3306/DATABASE
JWT_SECRETRandom string of at least 32 characters. Rotate immediately if ever exposed.
JWT_EXPIRES_INToken lifetime, e.g. 7d
FRONTEND_URLPrimary public frontend URL, e.g. https://your-domain.com
ALLOWED_ORIGINSComma-separated list of all allowed frontend origins
CLOUDINARY_CLOUD_NAMEOptionalRequired for image uploads
CLOUDINARY_API_KEYOptionalRequired for image uploads
CLOUDINARY_API_SECRETOptionalRequired for image uploads
SEED_ADMIN_EMAILOptionalEmail for the seeded admin (default: admin@spartansgym.com)
SEED_ADMIN_PASSWORDOptionalPassword for the seeded admin (default: ChangeMe123!)
Set SEED_ADMIN_PASSWORD to a strong, unique value before running the seed in production. The default ChangeMe123! is public knowledge — any system seeded with it is immediately vulnerable.

Frontend (frontend-spartans-gym/.env)

The frontend only needs one variable at build time:
VITE_API_URL=https://YOUR_BACKEND_DOMAIN/api
Vite inlines this value at build time. If you change the backend URL later you must rebuild and redeploy the frontend.

Database Setup & Backend Deploy

1

Install dependencies and generate the Prisma Client

From the backend/ directory (or your CI/CD pipeline):
npm install
npm run prisma:generate
2

Apply migrations to the production database

Use migrate deploy — not migrate dev — in production. It applies pending migrations without prompting and never resets data:
npx prisma migrate deploy
3

Seed the initial admin and default plans

npm run seed
This creates (or upserts) the admin user defined by SEED_ADMIN_EMAIL / SEED_ADMIN_PASSWORD and four default membership plans. It is safe to run multiple times.
4

Change the seeded admin password

Log in immediately after the first deploy and update the admin password from the Configuration module. Do not leave the default ChangeMe123! active.
5

Build and start the backend

Most hosting platforms let you specify a build command and a start command separately:
npm install && npm run prisma:generate && npx prisma migrate deploy && npm run build
The Docker container handles migrations automatically on startup via the CMD in the Dockerfile:
CMD ["sh", "-c", "npx prisma migrate deploy && npm start"]
6

Confirm the health check endpoint

After the backend is live, verify it is responding correctly:
curl https://YOUR_BACKEND_DOMAIN/api/health
A healthy response looks like:
{ "success": true }

Frontend Deploy

1

Set the build-time environment variable

In your static hosting provider’s dashboard, add:
VITE_API_URL=https://YOUR_BACKEND_DOMAIN/api
2

Build the frontend

cd frontend-spartans-gym
npm install
npm run build
This runs tsc -b && vite build and outputs the compiled SPA into frontend-spartans-gym/dist/.
3

Publish the dist/ directory

Configure your static host to serve frontend-spartans-gym/dist/ as the web root.
Set Publish directory to frontend-spartans-gym/dist and add a _redirects file:
/*  /index.html  200
4

Configure the SPA fallback rewrite

Spartans Gym uses React Router for client-side navigation. Your static host must rewrite all unmatched paths to index.html, otherwise direct URL access and browser refreshes will return a 404.

CORS Configuration

The backend’s CORS middleware reads the ALLOWED_ORIGINS variable at startup. List every frontend origin that must be allowed to send authenticated requests:
ALLOWED_ORIGINS=https://your-domain.com,https://www.your-domain.com
Do not set ALLOWED_ORIGINS=* in production. Wildcard origins are incompatible with credentialed requests (cookies, Authorization headers) and would expose your API to cross-site request forgery.
If you add a new frontend domain (for example a staging subdomain), you must add it to ALLOWED_ORIGINS and restart the backend before requests from that origin will succeed.

Railway — Backend + MySQL

Railway supports Docker deployments natively and provides managed MySQL add-ons. Deploy the backend/ directory with the Docker build pack, attach a MySQL service, and set the environment variables in the Railway dashboard.

Netlify / Vercel / Cloudflare Pages — Frontend

All three services build and publish static sites automatically from your Git repository. Connect the repo, set VITE_API_URL, configure the dist/ output directory, and enable SPA fallback rewrites.

Production Checklist

Work through this checklist after every new production deployment to confirm the system is functioning correctly end to end.
Functional verification
  • Login works with the seeded admin account
  • A receptionist user can be created from Configuration
  • Membership plans can be created and edited
  • A new client can be registered
  • Attendance can be recorded for a client
  • Membership renewal flow completes successfully
  • POS sale works with Efectivo (cash) payment
  • POS sale works with Tarjeta (card) payment
  • Transaction history filters return correct results
  • CSV export downloads a valid file
  • Receipts and tickets open and print correctly
  • Dark mode persists after a page refresh
Cross-device testing
  • Mobile layout verified at 375 × 667
  • Tablet layout verified at 768 × 1024
  • iPad Pro layout verified
  • Desktop layout verified
Infrastructure
  • Cloudinary upload works (if credentials are configured)
  • GET /api/health returns { "success": true }
  • Automatic database backups are enabled
  • Admin password has been changed from the default

Backup Recommendations

Configure automatic MySQL backups on your database provider. The recommended retention schedule from PRODUCTION_DEPLOY.md is:
FrequencyRetention
DailyLast 7 backups
WeeklyLast 4 backups
MonthlyLast 3 backups
Railway’s MySQL add-on supports automatic daily snapshots from the database settings panel. For external providers such as AWS RDS or DigitalOcean Managed Databases, enable automated backups with a retention window that satisfies the schedule above.

Security Notes

  • Never commit .env files to version control — this includes CI/CD secrets files.
  • Rotate JWT_SECRET immediately if it was ever pushed to a public repository.
  • Use HTTPS exclusively; never serve the application or API over plain HTTP.
  • Keep the admin password strong and unique.
  • Restrict database host access by IP allowlist on providers that support it.

Build docs developers (and LLMs) love