Server operations

List apps#

shis list

Shows domain, app ID, repository, loopback upstream, checkout, Caddy ownership, and current health result for every app.

Latest status#

shis status example-com

Machine-readable status:

shis status example-com --commit <full-sha> --json

Status is the latest snapshot for one app. History keeps the latest 100 durable records.

App environment#

printf 'RESEND_API_KEY=re_xxx\n' | shis env set example-com
shis env list example-com

Per-app values injected at deploy. Values arrive on stdin and are stored in a mode-0600 file; list prints names only. Details in Environment and secrets.

Update#

shis update

User-run commands check npm with a short timeout and suggest an update when a newer stable release exists. Registry failures do not block the command. Update installs the reported version, keeps config and secrets, moves the local release link, and reloads the service.

Remove an app#

shis remove example.com

Removes Shibumi config, webhook secret, deployment status, history, managed Caddy route, and app containers. Keeps checkout, volumes, images, and GitHub webhook, and the outro states exactly what stayed. --yes skips confirmation; sudo still asks separately. Re-registering the same domain under a different repository reuses that checkout, so delete it first if you mean to start clean; use shis set-repository when you don't.

Repoint an app's repository#

shis set-repository example.com github:owner/new-repository

Moves the app's existing checkout to <checkout>.bak, clones the new repository in its place, and updates the registration, all without touching Caddy or re-registering the app. Confirms first; --yes skips the prompt. Refuses only when <checkout>.bak already exists, since that's the one case Shibumi won't overwrite silently.

The Compose file path is re-detected in the new repository rather than carried over from the old one, the same way shis add detects it for a fresh checkout. This is deliberate: set-repository exists to swap in an unrelated repository, so assuming its layout matches the old one isn't safe. If detection fails partway (for example, the new repository has no Compose file where expected), Shibumi restores the original checkout from <checkout>.bak and leaves the registration untouched.

shis add offers the same move when it finds an existing checkout whose Git origin doesn't match the repository you're adding.

Uninstall#

shis uninstall

Asks for confirmation, then removes the service, launchers, and installed releases. Config, secrets, checkouts, containers, Caddy routes, and GitHub settings stay. Automation can pass --yes.

shis uninstall --purge

Purge asks a stronger confirmation and also removes config and webhook secrets. Automation must pass --purge --yes explicitly.

Service logs#

journalctl --user -u shibumi-server -f

Logs include deployment stages and results. They do not include raw webhook payloads or secrets.