# Admin & Maintenance

Three commands you run against a deployment rather than against a config: create the account that can sign in, produce the secrets the environment needs, and upgrade the binary in place.

## `sovrium admin create`

Provision an admin user directly in the database. This is the bootstrap path — it needs no running server and no full config.

```bash
# Prompt for the password (echo disabled, like sudo)
sovrium admin create me@example.com

# Supply it non-interactively (CI, provisioning scripts)
sovrium admin create me@example.com --password 's3cret-pass'

# Resolve auth settings from a specific config
sovrium admin create me@example.com --config app.yaml
```

The auth configuration is resolved in order: an explicit `--config <path>`, then `APP_SCHEMA`, then a minimal built-in default — so the bare form works with no config file at all. Migrations run first, so this also works against an empty database.

Two things to know before scripting it:

- **No TTY and no `--password` is an error.** In a non-interactive shell you must pass `--password`, or the command exits `1` rather than hanging on a prompt.
- **It is idempotent.** If the email already has an account, nothing is changed.

If the resolved config has no `auth` block, the command refuses and tells you to add one.

## `sovrium secret generate`

Print freshly generated, cryptographically random secrets as paste-ready `.env` lines. Each is 256 bits, rendered as 64 hexadecimal characters.

| Scope        | Prints                                   |
| ------------ | ---------------------------------------- |
| _(none)_     | `AUTH_SECRET` + `SOVRIUM_ENCRYPTION_KEY` |
| `all`        | Both (explicit)                          |
| `auth`       | `AUTH_SECRET` only                       |
| `encryption` | `SOVRIUM_ENCRYPTION_KEY` only            |

```bash
sovrium secret generate                  # both
sovrium secret generate auth >> .env     # append one to your .env
sovrium secret generate encryption       # encryption key only
```

:::callout
**Nothing is written to disk.** The `.env` lines go to stdout — so redirection works cleanly — and the explanatory notes go to stderr. Sovrium never silently persists a credential somewhere it might get committed.
:::

## `sovrium update`

Update Sovrium to the latest release. What actually happens depends on how it was installed, which the command detects for you:

| Install method | Behavior                                                 |
| -------------- | -------------------------------------------------------- |
| `binary`       | Self-replaces from GitHub Releases (Unix)                |
| `homebrew`     | Delegates to `brew upgrade sovrium/tap/sovrium`          |
| `scoop`        | Delegates to `scoop update sovrium`                      |
| `docker`       | Prints the `docker pull` instruction                     |
| `npm`          | Prints a deprecation notice (the npm package is retired) |

```bash
sovrium update
sovrium update --help
```

Delegating to Homebrew and Scoop rather than self-replacing is deliberate: it keeps the package manager's own version ledger correct. Docker containers cannot self-update, so that path prints the pull command instead.

## Related Pages

- [CLI Overview](/en/docs/cli) — the full command surface.
- [Environment Variables](/en/docs/env-vars) — where the generated secrets go.
- [User Management](/en/docs/user-management) — managing accounts after the first admin.
- [Security Hardening](/en/docs/security-hardening) — secret rotation and deployment posture.