Create an admin user
$ grim user admin@example.comA fresh database has nobody in it, and the login page is the first thing the app shows. grim user creates an administrator so you can get in: on a new clone, after you dropped the database, or on a server that was deployed a minute ago and has never seen a user.
Usage
$ grim user admin@example.com # random password, printed once
$ grim user anna.novak@example.com --name="Anna Novak"
$ grim user admin@example.com --password='long-and-secret'
$ grim user admin@example.com --remote=production # on the deployed appRun it from the project directory. Locally the stack has to be up and the database migrated.
Arguments and options
Create an admin user in the application
Usage
grim user [--name NAME] [--password PASSWORD] [--remote REMOTE] [--] <email>Arguments
| Argument | Description |
|---|---|
email |
User email address (required) |
Options
| Option | Description |
|---|---|
--name=NAME |
User display name (defaults to email prefix) |
--password=PASSWORD |
User password (defaults to random 16 chars) |
--remote=REMOTE |
Run on remote server (environment name, e.g. production) |
What it actually does
- Fills in what you left out. The name is made from the part of the email before the
@: dots, dashes and underscores become spaces and each word is capitalised, soanna.novak@example.combecomesAnna Novak. The password is 16 random hexadecimal characters. - Runs
php artisan users:adminwith the name, email and password. Locally that happens in the app container. With--remoteit happens over SSH as thedeployuser, in the project's directory on the server, which falls back to/opt/<project>. - Prints a summary. Email, name, password and target. This is the only place a generated password is ever shown.
The password is printed in plain text, and one given with --password also stays in your shell history. On a shared screen or a recorded session, let grim generate it and change it after the first login.
Pitfalls
--remote does not choose the environment
The value only switches the command to remote mode. The server is always the project's default environment in ~/.grim/servers.json, normally production, whatever name you pass. grim user admin@example.com --remote=staging creates the account on the default one and still prints remote (staging). For any other environment, log in to that server as deploy and run docker compose exec app php artisan users:admin "Anna Novak" anna.novak@example.com <password> in the project's directory.
The exit code is always zero
A failure shows in the title of the summary, User (check output above) instead of User created, and locally in the line Warning: Could not create user. Database may not be ready. Do not rely on the exit code in a script. Migrate the database with grim artisan and run it again.
No server is registered for the project
No deploy host configured for this project. means ~/.grim/servers.json on this machine has no entry for it. The host is not read from grim.json here. Register the project with grim server:add-project.
After it finishes
Log in with the email and the password from the summary, then store the password where you keep the others. grim does not save it anywhere.
Related spells
grim artisan
Run artisan in the container
Run an artisan command inside the app container, where the app's PHP, extensions and environment are.
grim create-project
Conjure a project
Create a project directory with a grim.json on the current train and install it, or write the grim.json for an application that already runs.
grim remote:artisan
Run artisan on the server
Run one artisan command inside the app container of the deployed project, from your own terminal.
grim server:add-project
Give a project a home
Prepare one environment of a project on a production server, with its database, nginx vhost, certificate, compose stack and .env.