Running your app - Meridian

meridian dev is the everyday command. It starts the Cloud SQL Auth Proxy against your managed developer database and your app’s dev server together, and stops both together, so quitting your server takes the tunnel with it.

meridian dev
meridian dev -- npm run dev:custom

The command it runs is resolved in order: whatever you pass after --, then dev_command in .meridian/project.json, then npm run dev.

Flag	Effect
`--port <port>`	Preferred local port for the proxy
`--env-file <file>`	The `.env` file to patch, relative to the project root. Defaults to `.env`
`--no-env`	Don’t touch any `.env` file; just print the `DATABASE_URL` for manual use

--port is a preference. If the port is busy the CLI picks another one, so nothing fails because you left yesterday’s tunnel running.

The database URL

Before starting your dev command, the CLI writes two lines into .env:

DATABASE_URL="mysql://devu_88_15:<password>@127.0.0.1:3307/devdb_88_u15"
SHADOW_DATABASE_URL="mysql://devu_88_15:<password>@127.0.0.1:3307/devdb_88_u15_shadow"

SHADOW_DATABASE_URL is a second database prisma migrate dev needs; it’s dropped with your developer database.
Every other line in the file (comments, order, quoting) is preserved, and the first change saves a one-time .env.backup.
Credentials are short-lived and rotate, and the port changes when the preferred one is busy, so treat the line as a cache rather than a secret to share, and keep .env out of git.
Your dev command gets both variables in its environment either way, so --no-env still works for a process that reads the environment rather than the file.

Use --env-file when your framework reads something other than .env, such as .env.local or .env.development. The path is relative to the project root, not to your shell.

The same --port and --env-file flags work on meridian migrate and every meridian db command, so a project that needs a non-default env file needs it everywhere, not just here.

​The database URL

The database URL