Skip to content

Lower the stack

$ grim down

The end of a working day, or the moment another project needs the memory. grim down stops the containers of the project you are standing in and removes them. Nothing you would miss goes with them: what a container needs to keep lives in a volume, and volumes are left alone.

It works on one project. The Traefik that routes every .test domain on the machine belongs to all of them, so it keeps running while another project still uses it. When you take down the last one, Traefik goes too and :80/:443 are free again; the next grim up starts it. On a vps-dev box Traefik belongs to the server and stays.

Usage

$ grim down               # stop this project, keep its volumes
$ grim down --volumes     # stop it and delete what the volumes held
$ grim down --purge       # that, and forget the project on this machine

Run it from the project directory. Anywhere else it has no grim.json to go by and says so.

Arguments and options

Stop Docker services

Usage

grim down [--volumes] [--purge]

Options

Option Description
--volumes Remove volumes (docker compose down -v)
--purge Also forget the project on this machine: volumes, its certificate in ~/.grim/traefik, and behind Herd its two proxies

What it actually does

Three things, in this order.

  1. Stops Vite. The dev server grim up started runs on your machine, not in a container, so Docker would never stop it. Left alone it keeps its port and the next grim up finds it taken.
  2. Removes public/hot. That file tells the app to load assets from the dev server. With Vite gone it would point every page at nothing.
  3. Runs docker compose down. Containers and the project network are removed. With --volumes it is docker compose down -v.
  4. Forgets the project on the machine, with --purge only. That implies --volumes, and then removes what grim up put outside the project: the mkcert certificate and Traefik's TLS file for it in ~/.grim/traefik, or, on a machine in behind-herd mode (see grim config), the two Herd proxies <name>.test and mail.<name>.test. Without --purge those stay: behind Herd the names answer 502 until the next grim up.

What --volumes takes with it

That depends on where the project runs, because the database does not live in the same place everywhere.

Where In a volume --volumes costs you
Your machine Redis Cache, sessions and queued jobs. The database runs on the machine itself, outside the stack, and is not touched.
A shared dev box MySQL and Redis The project's whole database, for everyone who works on that box.

There is no prompt and no way back except a dump made earlier. On a dev box, ask before you run it. It is a way to a clean slate on purpose, not a fix for a container that will not start.

After it finishes

Nothing of the project is running and nothing is lost. grim up brings it back as it was. After --volumes the same grim up starts the stack with empty volumes. After --purge it also mints the certificate or writes the Herd proxies again.

grim up

Raise the stack

Start the project's containers and its Vite dev server, with a trusted certificate and a working address, and say where to open it.

grim reload

Apply a changed .env

Recreate every container of the project and clear the config cache, so the app reads the .env as it is now.

grim logs

Read the logs

Show what the containers have been printing, for one service or all of them, on your machine or on a deployed server.