CLI reference - `supply-drop-bbs`

Complete reference for every subcommand and flag.

Synopsis

supply-drop-bbs [OPTIONS] [SUBCOMMAND]

Omitting the subcommand is the same as supply-drop-bbs run.

Global options

These options are accepted by every subcommand.

Flag	Env override	Default	Description
`--config <PATH>`	-	see below	Path to the TOML config file
`--data-dir <PATH>`	`SUPPLY_DROP__BBS__DATA_DIR`	`<config data_dir>`	Override the data directory (database, logs, backups)
`--log-level <LEVEL>`	`SUPPLY_DROP__LOGGING__LEVEL`	`INFO`	Log verbosity: `TRACE` `DEBUG` `INFO` `WARN` `ERROR`
`--version`	-	-	Print version and exit
`--help` / `-h`	-	-	Print help and exit

Config file search order

When --config is not given the BBS looks for a config file in this order, stopping at the first one found:

./config.toml
/etc/supply-drop-bbs/config.toml
~/.config/supply-drop-bbs/config.toml

If none exists, compiled-in defaults are used. An empty or missing config file is always valid.

`--data-dir` behaviour

Setting --data-dir clears any database path, log file path, and backup directory that were set in the config file - they are re-derived under the new data directory. If you need an explicit database path alongside a different data directory, set both data_dir and database.path in the TOML file instead.

Subcommands

`run`

supply-drop-bbs run [OPTIONS]

Start the BBS. This is the default when no subcommand is given - the following two commands are equivalent:

supply-drop-bbs
supply-drop-bbs run

What it does:

Loads and resolves configuration
Initialises tracing / logging
Creates the data directory if it does not exist
Opens (and migrates) the SQLite database
Constructs the BBS host
Starts compiled-in transport plugins (mesh, CLI, web admin)
Blocks until Ctrl-C or SIGTERM
Stops plugins in reverse order and exits cleanly

Examples:

# Systemd service - normal production invocation
supply-drop-bbs run --config /etc/supply-drop-bbs/config.toml

# Development - verbose logging, local data directory
supply-drop-bbs run --data-dir ./dev-data --log-level debug

# Override log level via environment
SUPPLY_DROP__LOGGING__LEVEL=trace supply-drop-bbs run

`setup`

supply-drop-bbs setup [OPTIONS]

Run the interactive first-run setup wizard. Detects your radio device, asks configuration questions, and writes a config.toml. Safe to run on an existing installation - answers are pre-populated from the current config.

The wizard asks:

Radio connection type — USB serial or Pi HAT
Serial port (USB only) — auto-detected; you confirm or enter manually
Radio parameters (USB serial only) — choose a named region preset or enter custom values (frequency, bandwidth, spreading factor, coding rate, TX power); stored in [plugins.mesh.radio] and applied to the device; can be re-applied later with node set-radio
BBS name — shown to users on connect
Data directory — defaults to /var/lib/supply-drop-bbs
Web admin UI — whether to enable it, bind address, and backup directory

After the wizard completes, restart the service to apply:

sudo systemctl restart supply-drop-bbs

Example:

sudo supply-drop-bbs setup --config /etc/supply-drop-bbs/config.toml

`config check`

supply-drop-bbs config check [OPTIONS]

Validate the config file and exit. Exit code 0 means the config is valid; non-zero means it is not.

supply-drop-bbs config check
# config OK

supply-drop-bbs config check --config /etc/supply-drop-bbs/config.toml
# config OK

Use this before restarting the service after an edit:

supply-drop-bbs config check && sudo systemctl restart supply-drop-bbs

`config show`

supply-drop-bbs config show [OPTIONS]

Print the effective configuration as TOML - compiled-in defaults, config file values, and environment overrides all merged and displayed together. Useful for verifying that overrides are applied correctly.

supply-drop-bbs config show
supply-drop-bbs config show --config /etc/supply-drop-bbs/config.toml
SUPPLY_DROP__BBS__DATA_DIR=/tmp/test supply-drop-bbs config show

`config require-verify`

supply-drop-bbs config require-verify <on|off> [OPTIONS]

Enable or disable sysop verification for new registrations. Writes require_verify to the [bbs] section of the config file. Takes effect on the next BBS restart.

Argument	Meaning
`on`	New accounts must be verified by an aide or sysop before they can access rooms (default)
`off`	New accounts are treated as `User` immediately — no verification step required (SHTF mode)

# Disable verification for emergency / SHTF deployments
sudo supply-drop-bbs config require-verify off \
  --config /etc/supply-drop-bbs/config.toml

# Restore normal verification
sudo supply-drop-bbs config require-verify on \
  --config /etc/supply-drop-bbs/config.toml

Tip: Use the in-BBS sysop command OPENACCESS / CLOSEACCESS instead if you need the change to take effect immediately without a restart.

`config guest-room`

supply-drop-bbs config guest-room <name|off> [OPTIONS]

Set or clear the guest room. Writes (or removes) guest_room in the [bbs] section of the config file. Takes effect on the next BBS restart.

When a guest room is configured, unverified users are placed in that room after registration and can only read and post there. All other rooms and mail are invisible until a sysop verifies them. The room is created automatically on startup if it does not already exist.

Argument	Meaning
`<name>`	Room name to use as the guest room (e.g. `Guests`)
`off`	Disable the guest room feature

# Set a guest room
sudo supply-drop-bbs config guest-room Guests \
  --config /etc/supply-drop-bbs/config.toml

# Disable
sudo supply-drop-bbs config guest-room off \
  --config /etc/supply-drop-bbs/config.toml

Tip: Use the in-BBS sysop command GUESTROOM <name> / GUESTROOM OFF for an immediate live change without a restart.

`config location`

supply-drop-bbs config location <latitude> <longitude> [OPTIONS]
supply-drop-bbs config location off [OPTIONS]

Set or clear this node's GPS coordinates. Writes latitude/longitude to the [location] section of the config file. Radio transports push these coordinates to the device on connect. Takes effect on the next BBS restart.

Setting coordinates alone does not make the node appear on public mesh maps — see config share-position below.

If share_in_advert is already on, setting coordinates here is what actually starts putting lat/lon in the advert — this command checks [bbs].name against the tighter 23-byte with-location limit ([location]) and refuses to write an over-length combination.

Argument	Meaning
`<latitude> <longitude>`	WGS-84 decimal degrees, e.g. `37.7749 -122.4194`
`off`	Clear both coordinates

sudo supply-drop-bbs config location 37.7749 -122.4194 \
  --config /etc/supply-drop-bbs/config.toml

sudo supply-drop-bbs config location off \
  --config /etc/supply-drop-bbs/config.toml

Tip: The web admin's Settings page can apply the same change live, without a restart.

`config share-position`

supply-drop-bbs config share-position <on|off> [OPTIONS]

Enable or disable broadcasting the configured GPS coordinates in mesh self-adverts — mirrors the official MeshCore app's "Share Position in Advert" checkbox. Writes share_in_advert to the [location] section. Has no effect until coordinates are also set via config location. Takes effect on the next BBS restart.

Turning this on while a location is already configured checks [bbs].name against the tighter 23-byte with-location limit ([location]) and refuses to write the change if the current name is too long — shorten it first.

Argument	Meaning
`on`	Broadcast coordinates in mesh self-adverts — this is what makes the node appear on MeshCore maps (default)
`off`	Keep the BBS aware of its own coordinates without publishing them

# Stop broadcasting position (coordinates stay configured)
sudo supply-drop-bbs config share-position off \
  --config /etc/supply-drop-bbs/config.toml

# Resume broadcasting
sudo supply-drop-bbs config share-position on \
  --config /etc/supply-drop-bbs/config.toml

Tip: The web admin's Settings page can apply the same change live, without a restart.

`config advert-scope`

supply-drop-bbs config advert-scope [VALUE] [OPTIONS]

Show, set or clear the MeshCore region the BBS's adverts are scoped to ([plugins.mesh].advert_scope; see Advert scope). With no argument it prints the current setting and the region key. With a region name (usa, or '#usa', which a shell needs quoted) it writes the setting; the name is checked the same way as when the config loads, and an invalid one is refused. off removes the setting. Takes effect on the next BBS restart. Like the other config commands it needs a config file that loads, so a value that was hand-edited to something invalid has to be fixed in the file.

At connect the BBS sets the radio's default flood scope to the region, before the on-connect advert. The scope also applies to the floods the radio starts when it has no path to someone (the first reply to a new user, logins), and a repeater passes a scoped flood on only if it carries that exact region, so pick one that every repeater between the BBS and your users carries (see Choosing a region). off does not clear a scope already on the radio; use the MeshCore app for that.

Argument	Meaning
(none)	Print the current setting
`<region>`	Set the region, with or without a leading `#` (at most 30 bytes; case matters)
`off`	Stop managing the scope (a region actually called `off` can be set as `'#off'`)

# Show what is set
supply-drop-bbs config advert-scope --config /etc/supply-drop-bbs/config.toml

# Scope adverts to the "usa" region
sudo supply-drop-bbs config advert-scope usa \
  --config /etc/supply-drop-bbs/config.toml

# Stop managing it
sudo supply-drop-bbs config advert-scope off \
  --config /etc/supply-drop-bbs/config.toml

Tip: The setup wizard and the web admin's Settings page (MeshCore radio) can set the same value.

`migrate`

supply-drop-bbs migrate [OPTIONS]

Apply any pending database migrations and exit. The run subcommand always migrates on startup, so this is only needed if you want to migrate without starting the BBS (e.g. as a pre-flight step in a deployment script).

exit 0   migrations applied (or already up to date)
exit 1   database could not be opened or a migration failed

Example deployment sequence:

supply-drop-bbs migrate --config /etc/supply-drop-bbs/config.toml
supply-drop-bbs run    --config /etc/supply-drop-bbs/config.toml

`backup` / `backup list` / `backup delete`

supply-drop-bbs backup [create]
supply-drop-bbs backup list
supply-drop-bbs backup delete <NAME> [--yes]

backup on its own is the same as backup create.

Trigger an immediate backup and exit. The backup lands in <data_dir>/backups/ (or the configured [backup] directory) as a timestamped .zip holding the database (VACUUM INTO, non-blocking and consistent, so the running BBS service does not need to be stopped) and the config.toml it loaded, so a restore can bring the settings back too. If no config file is found the zip holds the database only, and the command says so.

On success, prints the filename, size in bytes, and destination directory:

Backup created: backup_20260511_142301.zip
  size:     2097152 bytes
  settings: config.toml included
  location: /var/lib/supply-drop-bbs/backups

The automatic backups and the web UI's "create backup" button make the same bundle. Older backups are bare .db files; restore stage below accepts either.

`backup list`

Lists the backups in the backup directory, newest first, with their size, creation time (UTC) and whether they include the settings (config.toml):

name                              size  created (UTC)        settings
backup_20260920_101500.zip       2.0MB  2026-09-20 10:15:00  yes
backup_20260101_000000.db         512B  2026-01-01 00:00:00  no
2 backup(s) in /var/lib/supply-drop-bbs/backups

It only reads the directory, so it works when the database is broken.

`backup delete`

Deletes one backup by the name backup list shows, after a confirmation prompt (--yes skips it; without a terminal to ask on the command fails unless you pass it). A legacy .db backup's _config.toml sidecar goes with it. Names that are not a plain .db or .zip file name in the backup directory are refused. Like backup list it needs no working database. Automatic pruning ([backup] keep_daily / keep_weekly) is separate and, like this command, leaves the restore's own files (pending_restore*, pre-restore-safety-*) alone.

`restore stage` / `restore apply`

supply-drop-bbs restore stage <PATH|NAME>
supply-drop-bbs restore apply [--yes] [--no-config]

stage takes a file path, or just a backup name as backup list shows it. A bare name (no directory part) is the backup of that name in the backup directory, even if a file with the same name sits in the current directory; use ./name to mean that file instead.

Validate and apply a database restore from a backup file — the CLI equivalent of the web UI's Backups page restore flow. Works directly against the local database and data directory; no running BBS instance is required (unlike contacts). Staging and confirming are deliberately two separate steps, as with a web UI upload: staging alone never changes anything, and confirming only takes effect the next time the BBS process starts.

stage accepts either a raw .db file or the .zip bundle backup/the web UI produce, and runs the same validation the web upload endpoint does: a SQLite-format check, a check that the file has this application's own migration history, migrating it in place if it's an older schema, and a room-structure check, then SQLite's integrity check. A file that fails any of these is rejected and nothing is staged. Your file is copied into the data directory first and is never modified, so the disk needs room for a second copy; the copy becomes the staged file, or is removed if staging fails. Unlike the web UI, stage has no 2 GiB size limit (a database over 4 GiB, raw or in a zip, is still refused).

supply-drop-bbs restore stage /var/lib/supply-drop-bbs/backups/backup_20260511_142301.db
# Restore staged from /var/lib/supply-drop-bbs/backups/backup_20260511_142301.db.
# Run `supply-drop-bbs restore apply` to confirm it, then restart the BBS to apply it.

supply-drop-bbs restore apply
# This will replace the live database the next time the BBS starts. A safety
# snapshot of the current database is taken first, but this is still a
# destructive operation. Continue? [y/N] y
# Restore confirmed.
# Restart the BBS to apply it, e.g.: sudo systemctl restart supply-drop-bbs

By default a .zip backup's config.toml (the settings) is restored with the database, apart from the parts that belong to this machine (paths, the web and CLI plugins, the database, backup and security sections, the radios' connection, settings, on or off switch and node names); see Restoring from a backup. Pass --no-config to restore the database only.

Pass --yes to apply to skip the interactive confirmation prompt for scripted/non-interactive use. Without --yes and without a terminal to ask on, the command exits with an error instead of confirming anything:

supply-drop-bbs restore apply --yes

apply only promotes a previously staged file to the name the BBS's startup check looks for — it does not restart the service itself. The actual database swap happens the next time the BBS process starts, after a safety snapshot of the current database is taken automatically.

Exit codes: 0 on success (including a user-declined confirmation prompt, which prints "Aborted" rather than treating it as an error); non-zero if the source path in stage isn't a file, the file fails validation, or apply is run with nothing staged.

Web admin: The same validate/stage/confirm flow is available in the web UI under Backups: each backup in the list has a restore button, and a backup from another system can be uploaded there instead.

`node show-key`

supply-drop-bbs node show-key [OPTIONS]

Connect to the MeshCore companion device via USB serial, perform the handshake, and print the node's 32-byte public key as a 64-character hex string. This is the key other mesh nodes use to contact your BBS.

The BBS service must not be running on the same serial port when you run this.

supply-drop-bbs node show-key
# ab12cd34ef56...  (64 hex chars)

supply-drop-bbs node show-key --port /dev/ttyACM0

Flag	Description
`--port <PATH>`	Serial port (e.g. `/dev/ttyACM0`, `COM3`). Defaults to the port in `config.toml`.
`--baud <N>`	Baud rate. Defaults to `config.toml` value or `115200`.

`node export-key`

supply-drop-bbs node export-key [OPTIONS]

Export the companion device's 32-byte private key as a 64-character hex string. Back up this value before a firmware flash or hardware migration — it is the only way to restore your node's mesh identity.

Keep the output secret. Anyone with the private key can impersonate your node.

The BBS service must not be running on the same serial port.

supply-drop-bbs node export-key
# 7f3a1b... (64 hex chars — keep secret)

`node import-key`

supply-drop-bbs node import-key <KEY> [OPTIONS]

Import a 64-character hex key into the companion device as its new private key. The device's mesh identity changes immediately. The corresponding public key (shown by node show-key) will change to match.

Use this to:

Restore a backed-up key after a firmware flash
Migrate an identity from one device to another
Set a specific node key when deploying pre-provisioned hardware

Argument	Description
`<KEY>`	64 hex characters (32 bytes). Must be valid hexadecimal.

supply-drop-bbs node import-key ab12cd34ef56...
# key imported — node identity updated

Exit codes: 0 on success; 1 if the key is invalid, the port cannot be opened, or the device does not confirm the import.

Web admin: The same operation is available in the Settings page → Node identity → click the ✏️ icon next to the public key.

`node set-radio`

supply-drop-bbs node set-radio [OPTIONS]

Push radio parameters (frequency, bandwidth, spreading factor, coding rate, TX power) to the companion device over USB serial. The device persists these settings in its own flash; you only need to run this command when you want to change them.

The BBS service must not be running on the same serial port when you run this command.

Flag	Description
`--preset <NAME>`	Named region preset (e.g. `"USA/Canada"`). Overrides `config.toml` preset.
`--frequency-hz <N>`	Carrier frequency in Hz. Overrides preset.
`--bandwidth-hz <N>`	Channel bandwidth in Hz. Overrides preset.
`--spreading-factor <N>`	LoRa spreading factor 7–12. Overrides preset.
`--coding-rate <N>`	Coding rate denominator 5–8. Overrides preset.
`--tx-power-dbm <N>`	Transmit power in dBm. Overrides preset.
`--save`	Write the resolved parameters back to `config.toml`.
`--list-presets`	Print all available preset names and exit (does not open the port).
`--port <PATH>`	Serial port (e.g. `/dev/ttyACM0`, `COM3`). Defaults to the port in `config.toml`.
`--baud <N>`	Baud rate. Defaults to `config.toml` value or `115200`.

Examples:

# List available region presets
supply-drop-bbs node set-radio --list-presets

# Apply the preset stored in config.toml (no flags needed)
supply-drop-bbs node set-radio \
  --config /etc/supply-drop-bbs/config.toml

# Apply a specific preset and save it to config.toml
supply-drop-bbs node set-radio --preset "USA/Canada" --save \
  --config /etc/supply-drop-bbs/config.toml

# Apply fully custom parameters without using a preset
supply-drop-bbs node set-radio \
  --frequency-hz 910525000 --bandwidth-hz 62500 \
  --spreading-factor 7 --coding-rate 5 --tx-power-dbm 20 \
  --save --config /etc/supply-drop-bbs/config.toml

Exit codes: 0 on success; 1 if a parameter is out of range, the port cannot be opened, or the device does not confirm the command.

Config reference: Radio parameters are stored in [plugins.mesh.radio] in config.toml. Saving them there allows node set-radio (with no flags) to re-apply the same settings after a firmware flash.

`user promote`

supply-drop-bbs user promote <USERNAME> [OPTIONS]

Promote a user account to Sysop (permission level 100). The BBS service does not need to be restarted - the change takes effect the next time the user logs in or issues a command.

Argument	Description
`<USERNAME>`	BBS username to promote (case-sensitive)

supply-drop-bbs user promote alice
# alice promoted to sysop (level 100)

sudo supply-drop-bbs user promote alice \
  --config /etc/supply-drop-bbs/config.toml

Exit codes: 0 on success; 1 if the user is not found or the database cannot be opened.

Aide level: There is currently no --aide flag. To promote to Aide (level 50) instead of Sysop, use the in-BBS .EU <username> command as a Sysop, or update the database directly:
sh
sudo sqlite3 /var/lib/supply-drop-bbs/bbs.sqlite \
  "UPDATE users SET permission_level = 50 WHERE username = 'alice';"

`user demote`

supply-drop-bbs user demote <USERNAME> [OPTIONS]

Demote a user account back to User (permission level 10). Removes Sysop or Aide privileges. The change takes effect the next time the user issues a command.

Argument	Description
`<USERNAME>`	BBS username to demote (case-sensitive)

supply-drop-bbs user demote alice
# alice demoted to user (level 10)

Exit codes: 0 on success; 1 if the user is not found or the database cannot be opened.

`user set-password`

supply-drop-bbs user set-password <USERNAME> [OPTIONS]

Reset a user's password without requiring the old password. Prompts for the new password interactively (input is hidden) and asks for confirmation. The BBS service does not need to be stopped.

Argument	Description
`<USERNAME>`	BBS username whose password will be reset (case-sensitive)

sudo supply-drop-bbs user set-password alice \
  --config /etc/supply-drop-bbs/config.toml
# New password for alice: ••••••••
# Confirm password:       ••••••••
# password reset for alice

The new password must be at least 6 characters. The same operation is available in the web admin UI — open the user's detail drawer on the Users page and click reset password (sysop-only; requires the BBS to be running).

Exit codes: 0 on success; 1 if the user is not found, the password is too short, or the database cannot be opened.

`user ban` / `user unban`

supply-drop-bbs user ban <USERNAME> [OPTIONS]
supply-drop-bbs user unban <USERNAME> [OPTIONS]

Disable (ban) or re-enable (unban) a user account. A disabled account can't log in, and a session it already has open ends the next time it sends a command, with a message saying the account was banned. The account and its authored messages are preserved. This is a softer action than deletion: deleting additionally reserves the username so no-one else can register it, and isn't currently exposed as a CLI command.

Argument	Description
`<USERNAME>`	BBS username to disable/re-enable (case-sensitive)

supply-drop-bbs user ban alice
# disabled: alice (login rejected; a live session ends on its next command)

supply-drop-bbs user unban alice
# re-enabled: alice

Exit codes: 0 on success; 1 if the user is not found or the database cannot be opened.

Equivalent to the in-BBS BAN <username> (Aide+) / UNBAN <username> (Sysop) commands, and to the ban/unban buttons on the web admin's Users page. Those run inside the server and end a live session at once; the CLI runs as a separate process, which is why its ban lands on the session's next command instead.

`user timeout`

supply-drop-bbs user timeout <USERNAME> <DAYS> [OPTIONS]

Suspend a user account for a fixed number of days, distinct from a permanent ban: login is rejected and a live session ends on its next command, same as ban, but the account reactivates automatically once the timeout elapses rather than staying disabled until an explicit unban. A login attempt during the timeout is told how many days remain. unban lifts a timeout early.

Argument	Description
`<USERNAME>`	BBS username to suspend (case-sensitive)
`<DAYS>`	Suspension length, `1`-`5`

As with user ban, the CLI runs as a separate process and can't reach the server's sessions, so the suspension lands on a live session's next command.

supply-drop-bbs user timeout alice 3
# suspended: alice for 3 day(s)

Exit codes: 0 on success; 1 if the user is not found, <DAYS> is outside 1-5, or the database cannot be opened.

Equivalent to the in-BBS TIMEOUT <username> <days> (Aide+) command, and to the timeout button on the web admin's Users page.

`contacts list` / `contacts discovered` / `contacts delete`

supply-drop-bbs contacts <list|discovered|delete> [OPTIONS]

Manage protected mesh contacts against a running BBS's web admin API. Unlike every other subcommand, contacts does not touch the local database or config file directly — it requires a reachable BBS instance with the admin-web feature enabled, and logs in exactly like the web UI (a session cookie, not a separate mechanism). Mirrors the web UI's Contacts and Discovered Contacts pages, including the same permission requirements.

Flag	Env override	Default	Description
`--url <URL>`	`SUPPLY_DROP_BBS_URL`	`http://127.0.0.1:8080`	Base URL of the running BBS's web admin API
`--username <NAME>`	`SUPPLY_DROP_BBS_USERNAME`	-	BBS account to authenticate as
`--password <PASSWORD>`	`SUPPLY_DROP_BBS_PASSWORD`	-	Password to authenticate with. Prompted interactively (hidden input) if omitted

Login itself requires Aide or Sysop (level 50+) — the web admin API rejects a plain User account before a session can even exist, with the same "invalid credentials" error a wrong password would give. This applies to list and discovered too, not just delete.

Action	Description
`list`	Protected contacts only (mirrors the Contacts page)
`discovered`	Every discovered contact, protected or not (mirrors the Discovered Contacts page)
`delete <PUBKEY>`	Remove a single protected contact by its 64-character hex public key, as shown by `list`. A pubkey that only appears in `discovered` (never protected) has nothing to delete and the server responds 404.

Flag order: --url/--username/--password belong to contacts itself, not to list/discovered/delete — put them before the action, e.g. contacts --username alice delete <PUBKEY>.

supply-drop-bbs contacts --username alice list
# Password for alice: ••••••••
# PROTECTED  NAME                     TRANSPORT    TYPE       LAST SEEN            PUBKEY
# ----------------------------------------------------------------------------------------------------
# yes        basecamp-node            meshtastic   client     2026-09-01T12:03:11Z ab12cd34ef56...

supply-drop-bbs contacts \
  --url http://192.168.1.50:8080 --username alice --password hunter2 discovered

supply-drop-bbs contacts --username alice --password hunter2 \
  delete ab12cd34ef56...
# deleted: ab12cd34ef56...

Non-loopback HTTP: the session cookie the CLI relies on is marked Secure by default (cookie_secure = true, see below), and a compliant cookie jar only sends a Secure cookie back over https:// or a loopback address (127.0.0.1/localhost). A --url pointing at a LAN address like http://192.168.1.50:8080 — as in the discovered example above — will log in successfully but then silently fail every following request with 401 Unauthorized, since the cookie never gets sent back. Either set cookie_secure = false under [plugins.web] (see CONFIG.md, local/dev deployments only) on the server, or put the web admin behind TLS before using contacts against a non-loopback --url.

For scripted/non-interactive use, set SUPPLY_DROP_BBS_USERNAME and SUPPLY_DROP_BBS_PASSWORD instead of passing --password on the command line (which would otherwise be visible in shell history and ps):

export SUPPLY_DROP_BBS_URL=http://127.0.0.1:8080
export SUPPLY_DROP_BBS_USERNAME=alice
export SUPPLY_DROP_BBS_PASSWORD=hunter2
supply-drop-bbs contacts list

Exit codes: 0 on success; non-zero on any failure — the BBS not being reachable, a failed or under-privileged login, an invalid --password prompt, a malformed pubkey passed to delete, or the pubkey not matching any protected contact.

Web admin: The same data and delete action are available in the web UI under Contacts (protected) and Discovered Contacts (all).

Permission levels

Level	Value	How to set
Unvalidated	0	Assigned on registration; cannot log into BBS features until validated
User	10	`user demote` or in-BBS `.EU`
Aide	50	In-BBS `.EU` as Sysop, or direct DB update
Sysop	100	`user promote` or in-BBS `.EU` as Sysop

The first account registered on a fresh installation is automatically promoted to Sysop.

Common workflows

Bootstrap a new installation

# First user self-promotes to Sysop automatically on registration.
# If you need to promote a second sysop:
sudo supply-drop-bbs user promote alice \
  --config /etc/supply-drop-bbs/config.toml

Recover lost sysop access

sudo systemctl stop supply-drop-bbs
sudo supply-drop-bbs user promote alice \
  --config /etc/supply-drop-bbs/config.toml
sudo systemctl start supply-drop-bbs

Reset a user's password

If the BBS is running and you are logged into the web admin as a sysop, open the Users page, click the username to open the detail drawer, and use the reset password form.

If the web UI is unavailable, use the CLI (the BBS does not need to be stopped):

sudo supply-drop-bbs user set-password alice \
  --config /etc/supply-drop-bbs/config.toml

Verify config before restarting

supply-drop-bbs config check --config /etc/supply-drop-bbs/config.toml \
  && sudo systemctl restart supply-drop-bbs

Run a local dev instance

cargo build
mkdir -p dev-data
./target/debug/supply-drop-bbs run \
  --config dev-config.toml \
  --data-dir dev-data \
  --log-level debug

CLI reference - supply-drop-bbs ​

Synopsis ​

Global options ​

Config file search order ​

--data-dir behaviour ​

Subcommands ​

run ​

setup ​

config check ​

config show ​

config require-verify ​

config guest-room ​

config location ​

config share-position ​

config advert-scope ​

migrate ​

backup / backup list / backup delete ​

backup list ​

backup delete ​

restore stage / restore apply ​

node show-key ​

node export-key ​

node import-key ​

node set-radio ​

user promote ​

user demote ​

user set-password ​

user ban / user unban ​

user timeout ​

contacts list / contacts discovered / contacts delete ​

Permission levels ​

Common workflows ​

Bootstrap a new installation ​

Recover lost sysop access ​

Reset a user's password ​

Verify config before restarting ​

Run a local dev instance ​

CLI reference - `supply-drop-bbs`

Synopsis

Global options

Config file search order

`--data-dir` behaviour

Subcommands

`run`

`setup`

`config check`

`config show`

`config require-verify`

`config guest-room`

`config location`

`config share-position`

`config advert-scope`

`migrate`

`backup` / `backup list` / `backup delete`

`backup list`

`backup delete`

`restore stage` / `restore apply`

`node show-key`

`node export-key`

`node import-key`

`node set-radio`

`user promote`

`user demote`

`user set-password`

`user ban` / `user unban`

`user timeout`

`contacts list` / `contacts discovered` / `contacts delete`

Permission levels

Common workflows

Bootstrap a new installation

Recover lost sysop access

Reset a user's password

Verify config before restarting

Run a local dev instance