Deployment

The project deploys to two platforms simultaneously: Cloudflare (primary, production) and optionally cPanel (legacy fallback).

Cloudflare (primary)

Service	What
Cloudflare Pages	Frontend (React/Vite build)
Cloudflare Workers	Backend (Express via serverless-http)
Cloudflare D1	Database (SQLite)
Cloudflare R2	File storage

Frontend deployment

cd frontend
npm run build       # outputs to frontend/dist/
# Deploy dist/ to Cloudflare Pages
# Or connect the repo to Cloudflare Pages for automatic deploys on push

The frontend/public/_redirects and frontend/public/.htaccess files handle SPA routing (all paths → index.html).

Backend deployment

cd backend
npx wrangler deploy

wrangler.toml defines the Worker configuration:

• Entry point: worker.js (wraps Express via serverless-http)
• D1 binding: DB → database shanvi-db
• R2 binding: BUCKET → bucket shanvi-uploads
• nodejs_compat flag: required for Node.js globals in Workers

⚠️ Critical: Rotate hardcoded secrets immediately

wrangler.toml currently has JWT_SECRET and REFRESH_SECRET_KEY committed in plaintext. These values are compromised. To fix:

# Remove the [vars] entries for JWT_SECRET and REFRESH_SECRET_KEY from wrangler.toml
# Then set them as proper Cloudflare secrets:
npx wrangler secret put JWT_SECRET
npx wrangler secret put REFRESH_SECRET_KEY

Secrets set via wrangler secret put are encrypted at rest and never appear in the dashboard or source control.

Environment variables in wrangler.toml

Non-sensitive vars (like NODE_ENV, FRONTEND_URL) can stay in [vars]. Sensitive values must be Cloudflare secrets.

D1 database migrations

To apply schema changes to the production D1 database:

# Apply a SQL file to production D1
npx wrangler d1 execute shanvi-db --file=./your-migration.sql

# Apply to local D1 (for testing)
npx wrangler d1 execute shanvi-db --local --file=./your-migration.sql

The current codebase uses runtime ALTER TABLE guards instead of explicit migration files. This is a known issue — see Known Issues for context and the recommended migration approach.

cPanel (legacy / fallback)

The .cpanel.yml and backend/.htaccess files support deploying the Express server to a cPanel host as a traditional Node.js app with a MySQL database.

cPanel backend

1. Upload backend/ to the server
2. Set environment variables in the Node.js app settings in cPanel
3. Run npm install and set server.js as the entry point
4. Point cPanel’s MySQL database credentials to .env

cPanel frontend

1. Run npm run build locally
2. Upload frontend/dist/ to the public_html directory
3. The frontend/public/.htaccess handles SPA routing

Staging environment

There is currently no dedicated staging environment. The apist.shanvitravel.com.np domain (referenced in frontend/src/config/api.ts) appears to be used as a staging API, but this is not formally documented.

Recommendation: Set up a proper staging Worker (wrangler.toml environments) and Cloudflare Pages preview branch so new features can be tested before hitting production.

# Add to wrangler.toml
[env.staging]
name = "shanvi-travels-backend-staging"
vars = { NODE_ENV = "staging", FRONTEND_URL = "https://staging.shanvitravels.pages.dev" }

[[env.staging.d1_databases]]
binding = "DB"
database_name = "shanvi-db-staging"
database_id = "<staging-db-id>"