Running a development database

lyrid keeps everything except the database on the host: only PostgreSQL runs in a container, and only for development.

Bring it up

docker compose up -d db

The compose file publishes 5432 and creates the lyrid database, user, and password — matching the DATABASE_URL in .env.example. Wait for the health check to pass before starting the server:

docker compose ps

Point the server at it

cp .env.example .env
cargo run

Migrations in migrations/ are applied on start, so a fresh container becomes a usable database the first time the server runs. There is no separate migration command to remember.

Read the health endpoint

/health answers two different questions in one response:

curl -i http://127.0.0.1:8080/health

Response	Meaning
200 with "status": "ok"	The process is alive and a round-trip to the database succeeded.
503 with "status": "degraded"	The process is alive, the database is not reachable.
No response at all	The server is not running or not bound where you are looking.

The distinction matters for deployment: a degraded server should be pulled out of a load balancer without being restarted, because restarting it will not fix a database that is down.

Start over

To throw away the data and begin from an empty database:

docker compose down -v
docker compose up -d db

The -v is the point — without it the volume survives and the old data comes back.

Connect by hand

docker compose exec db psql -U lyrid -d lyrid

Using a database you already have

Nothing binds lyrid to the compose file: point DATABASE_URL anywhere and the server will use it.

DATABASE_URL=postgres://user:password@host:5432/database cargo run

Keep real credentials in .env, which is not committed — never in .env.example, a config file, or a test fixture.