Copy .env.example to .env and fill in your local MariaDB credentials.
Install dependencies: npm install
Export those same DB_HOST/DB_USER/DB_PASSWORD/DB_NAME values from .env into your shell, then apply the schema with Prisma Migrate (creates the conversion_jobs table fresh, since a new local database starts empty): DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate deploy
Run the API: npm start
Run the worker (separate terminal): npm run worker
Run tests: npm test (requires the same MariaDB reachable via your .env vars, exported into the shell)

Deployment on o2switch

Upload the project (excluding node_modules/) via SSH/Git.
Create/adjust .env on the server with production values (STORAGE_DIR pointing to a writable path under your account, MariaDB credentials from cPanel).
npm install --include=dev (never with --ignore-scripts — Puppeteer needs its postinstall step to download Chromium).
Configure the app in cPanel "Setup Node.js App", pointing its entry point at src/server.js. Passenger manages this process (start/stop/restart).
Start the worker independently of Passenger, over SSH: ./node_modules/.bin/pm2 start ecosystem.config.cjs, then pm2 save. Try pm2 startup to survive a server reboot; if that's not permitted without root on this account, fall back to a cPanel cron job every 5 minutes that runs pm2 resurrect (or checks pm2 list and restarts the app if absent) — validate which option this hosting plan actually allows once connected over SSH.
Add a cPanel cron job to run the cleanup script periodically, e.g. every 15 minutes: */15 * * * * cd /home/gaan6043/convert.ombrora.com-node && /home/gaan6043/nodevenv/convert.ombrora.com-node/24/bin/node src/cleanup.js > /dev/null (adjust the path and node binary location to match your actual account — check with which node over SSH).
ONE-TIME, before ever running prisma migrate deploy on this server: the o2switch database already has the conversion_jobs table (created by hand, before this project used Prisma), but no _prisma_migrations tracking table. Running migrate deploy first would try to CREATE TABLE conversion_jobs again and fail with a "table already exists" MySQL error, leaving Prisma's migration history stuck and needing manual recovery. Avoid that by baselining the existing table once, ever, on this server, before step 8's migrate deploy runs for the first time: DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate resolve --applied 0_init Do not repeat this step on later deployments — after this one-time run, migrate deploy (step 8) is the correct command going forward.
On every subsequent deployment: pull changes, npm run deploy