Recreate a dev stack

$ grim server:dev:reload shop

Someone changed a value in the project's .env on the box and the app behaves as if nothing happened. Containers read .env when they are created, and grim up does not recreate a container that is already running. grim server:dev:reload does, without you opening a session on the box first.

If you are already attached to the box, grim reload in the project directory is the same thing.

Usage

$ grim server:dev:reload shop        # recreate the stack of shop on its box
$ grim server:dev:reload shop -v     # the same, with the remote output as it comes

Run it from anywhere. The project must be in your ~/.grim/servers.json as a dev environment, which means you added it with grim server:dev:add-project from this machine.

Arguments and options

Recreate a dev project stack on its VPS to apply .env changes

Usage

grim server:dev:reload <project>

Arguments

Argument	Description
`project`	Project name (required)

What it actually does

Finds the box and the path in servers.json and prints Reloading shop on 203.0.113.10….
Runs grim reload on the box, as dev, in the project directory. It waits up to five minutes.
The reload there renders docker-compose.yml again from the template, so a change to grim.json such as a new service or another theme lands as well.
Recreates every container with docker compose up -d --force-recreate.
Clears the config cache with php artisan config:clear in the app container.
Prints what the box printed, step by step with timings. Without -v it arrives in one piece once the reload is over.

Pitfalls

Everyone on the project feels it

The stack is shared. Recreating it cuts every open page, hot-reload socket and running queue job for whoever is working on that project. The database and Redis data sit in volumes and survive. Say a word in the team channel first.

It does not pull code

Reload works with the files that are on the box. New commits arrive there by git pull in the project directory, and most code changes need no reload at all, since the source is mounted into the containers.

A colleague's machine does not know the project

No dev environment registered for project "shop". means this machine never added it. Attach to the box and run grim reload there instead.

After it finishes

The containers are new and read the current .env. Check them on the card.

$ grim server:dev:info shop

grim server:dev:info

Show a project's dev card

Print the URLs, SSH and VS Code commands, database credentials and container states of a project on a dev box.

grim server:dev:add-project

Settle a project on the box

Clone a repository onto a shared dev box, give it a dev .env and domains, and start its stack there.

grim server:dev:remove

Take a project off the box

Stop a project's stack on a dev box and delete its volumes, its directory and its registration, keeping what you ask to keep.

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.

Recipes that use it

Set up a dev box for a client

Raise a shared development server, give it a registry token, put the first project on it, let developers in by key, hand over the access card, and later take a developer or a project off again.

Work on a client's dev box

Send your public key to the operator, paste the SSH block they send back, attach your editor to the project on the box, reload the stack after a change to .env, and open the database from there.