Skip to main content
This page covers getting the jethings-database repo running locally so you can generate, test, and apply Prisma migrations against the right database depending on your role (dev-responsible, prod-responsible, or general contributor).

​
1. Clone the repo

​
2. Install dependencies

​
3. Create your environment file

If you’re a developer working locally, create .env.local:
.env.local
.env.local always points at your local Postgres instance (or a tunneled dev DB — see below). This is the file every *:local script in package.json reads via dotenv -e .env.local.

​
Which env files you need, by role

You need both:
  • .env.local — points at your local DB for writing/testing migrations
  • .env.dev — points at the dev VPS DB, used to actually apply migrations there once approved
.env.dev
You only need .env.prod:
.env.prod
Production migrations are never run against a tunneled local session — they’re run directly on the VPS (see the Production Migration page).
You only need .env.local. You don’t apply anything to dev or prod yourself — that’s handled by whoever owns that environment, per the Developer and Reviewer workflow pages.

​
Connecting to the VPS to run migrations directly

If you’re the one responsible for dev or prod, migrations on the VPS itself are run by:
  1. SSH-ing into the VPS
  2. cd-ing into the Database repo location on the server
  3. Running the relevant db:bootstrap:prod command there (covered on the following pages)

​
Tip: tunnel the dev DB to your machine instead of editing .env.dev remotely

If you’re the dev-responsible person and want to handle migration dev on your local side for better handling the workflow or want to inspect/query the dev DB from your own machine (e.g. via Prisma Studio or a GUI client) without SSHing in every time, open an SSH tunnel:
Breaking this down:
  • -L 5435:localhost:5432 — the core of the tunnel. Forwards your local port 5435 to localhost:5432 as seen from the VPS (i.e. the VPS’s own Postgres, listening only on its own loopback). Anything you send to localhost:5435 on your machine actually reaches Postgres on the remote server.
  • -f — puts SSH in the background immediately after authentication, so it doesn’t block your terminal. You get your prompt back while the tunnel stays alive.
  • -N — tells SSH not to execute any remote command or open a shell — you only want the port forward, not an interactive session.
  • user@address — the SSH user and host of the VPS, same credentials you’d use to SSH in normally.
After running it, you’ll be prompted for the SSH password (or it’ll use your key if configured).
Once the tunnel is up, set .env.dev to point at the local end of the tunnel, not the VPS’s real address:
.env.dev
This lets you run db:bootstrap:dev, prisma:studio:dev or inspect the dev schema directly from your machine, safely, without opening Postgres to the internet or needing a new firewall rule. Kill the tunnel when done: find the process with ps aux | grep 5435 and kill it, or just close the terminal session if you didn’t use -f.

​
4. Generate the Prisma client

Run the Prisma generator for the environment you’re targeting:

​
The “1000x faster” tip

When you run pnpm prisma:generate:prod, you may see a message saying you can make queries “1000x faster” with Prisma Accelerate. That is marketing math.
  • The claim compares a heavy, unindexed database query to a pre-cached response from an edge CDN.
  • Prisma Accelerate is a paid SaaS that adds a global edge cache and a connection pooler.
For a VPS deployment, you usually do not need it. The server keeps a persistent connection to PostgreSQL, and properly indexed queries already run in milliseconds. If you need caching, use Redis, BullMQ, or Next.js unstable_cache instead of routing database traffic through a third-party proxy.

​
5. Seed the database

If your repo has seed data, run it for the target environment: