-
Notifications
You must be signed in to change notification settings - Fork 1
Command reference
Arnel Robles edited this page Sep 26, 2026
·
2 revisions
Generated from --help on the released binary, so it cannot drift from the flags the code
actually defines. Regenerate it by walking the command tree rather than editing this page by hand.
Every command takes -o json. See The JSON contract before writing anything that
parses the output.
BaryoVM turns provision → install Docker → deploy into one command.
CLI-first: the MAUI app and MCP server drive this same CLI (with -o json).
Usage:
baryovm [command]
Available Commands:
completion Generate the autocompletion script for the specified shell
deploy Deploy a container image to a VM
doctor Check (and with --fix, auto-install) local prerequisites
help Help about any command
stack Manage docker compose stacks on your VMs
up Provision (if new) → install Docker → deploy, in one command
version Print the BaryoVM version
vm Manage the VMs in your fleet
Flags:
-h, --help help for baryovm
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Use "baryovm [command] --help" for more information about a command.
Deploy a container image to a VM
Usage:
baryovm deploy [flags]
Examples:
baryovm deploy --vm web1 --image nginx:alpine --name site -p 80:80
baryovm deploy --vm web1 --image app:latest --name app -p 127.0.0.1:8080:8080 -e KEY=val --pull
Flags:
-e, --env stringArray environment KEY=value (repeatable)
-h, --help help for deploy
--image string container image (required)
--name string container name (required)
-p, --publish stringArray port mapping host:container (repeatable)
--pull pull the image before running
--vm string target VM name (required)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Reports the local tools and cloud credentials BaryoVM uses. With --fix,
a missing tool BaryoVM knows how to install is installed; anything it cannot
install is reported with what to do about it.
Usage:
baryovm doctor [flags]
Flags:
--fix install the missing tools BaryoVM knows how to install
-h, --help help for doctor
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Manage docker compose stacks on your VMs
Usage:
baryovm stack [command]
Available Commands:
add Register a compose stack (a project dir on a VM)
backup Back up the stack's database + config (pg_dump + .env)
backups List the stack's database backups
deploy compose up -d the stack (optionally pull + recreate)
list List registered stacks
logs Show recent logs for the stack
ps Show the stack's containers
pull Pull the stack's images
release Sync source to the VM, build images there, then compose up (config-driven)
remove Remove a stack registration (does not touch the VM)
restore Restore the stack's database from a backup (REPLACES current data)
set-update Set a stack's update policy (autoUpdate, health URL)
update Pull newer images and recreate, only if they come up healthy
Flags:
-h, --help help for stack
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Use "baryovm stack [command] --help" for more information about a command.
Register a compose stack (a project dir on a VM)
Usage:
baryovm stack add <name> [flags]
Flags:
--backup-dir string remote dir for backups (default: ~/<name>-backups)
--db-container string postgres container for backups, e.g. deploy-postgres-1
--db-name string database to back up
--db-user string database user (default: postgres)
--env-file string config file to back up, relative to the project dir (e.g. .env)
--file string compose file name (default: compose's own default)
-h, --help help for add
--keep int backups to retain per kind (default 14)
--path string remote project directory, e.g. /opt/barakocms (required)
--release-file stack release local JSON release manifest for stack release
--sudo run this stack's remote commands via sudo -n, for a stack whose .env or deploy root is root-owned. See USAGE.md for what it covers and the three things that change with it
--vm string VM the stack runs on (required)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Back up the stack's database + config (pg_dump + .env)
Usage:
baryovm stack backup <name> [flags]
Flags:
-h, --help help for backup
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
List the stack's database backups
Usage:
baryovm stack backups <name> [flags]
Flags:
-h, --help help for backups
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
compose up -d the stack (optionally pull + recreate)
Usage:
baryovm stack deploy <name> [flags]
Examples:
baryovm stack deploy barako --force-recreate --service app,admin
baryovm stack deploy barako --pull
Flags:
--force-recreate recreate containers even if unchanged
-h, --help help for deploy
--no-deps don't touch linked services
--pull pull images before recreating
--service strings limit to these services (comma-separated)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
List registered stacks
Usage:
baryovm stack list [flags]
Flags:
-h, --help help for list
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Show recent logs for the stack
Usage:
baryovm stack logs <name> [flags]
Flags:
-h, --help help for logs
--service strings limit to these services (comma-separated)
--tail int lines per service (default 100)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Show the stack's containers
Usage:
baryovm stack ps <name> [flags]
Flags:
-h, --help help for ps
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Pull the stack's images
Usage:
baryovm stack pull <name> [flags]
Flags:
-h, --help help for pull
--service strings limit to these services (comma-separated)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Sync source to the VM, build images there, then compose up (config-driven)
Usage:
baryovm stack release <name> [flags]
Examples:
baryovm stack release baryoclub
baryovm stack release baryoclub --config ./baryovm.release.json --no-backup
Flags:
--config string release manifest path (overrides the stack's --release-file)
-h, --help help for release
--no-backup skip the automatic pre-release DB backup
--no-build skip building images (just sync + compose up)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Remove a stack registration (does not touch the VM)
Usage:
baryovm stack remove <name> [flags]
Flags:
-h, --help help for remove
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Restore the stack's database from a backup (REPLACES current data)
Usage:
baryovm stack restore <name> [flags]
Examples:
baryovm stack restore baryoclub --yes
baryovm stack restore baryoclub --file db-20260717-011514.dump --yes
Flags:
--file string backup to restore (name or path); default: newest
-h, --help help for restore
--yes confirm the destructive restore
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Set a stack's update policy (autoUpdate, health URL)
Usage:
baryovm stack set-update <name> [flags]
Examples:
baryovm stack set-update playground --health-url http://127.0.0.1:5005/health --auto
baryovm stack set-update club --health-url http://127.0.0.1:8091/health --no-auto
Flags:
--auto allow unattended updates (requires --health-url)
--health-url string URL probed from the VM after an update, e.g. http://127.0.0.1:8091/health
-h, --help help for set-update
--no-auto disallow unattended updates
--no-database this stack has no database, so --auto may update it with no backup (--no-database=false to undo)
--service strings limit updates to these services
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Pulls the stack's images and, when any actually changed, backs up the database,
recreates the affected services, and waits for the stack's health URL. If it does not
come back, the previous images are restored and the stack is checked again.
An unchanged stack is left alone: no recreate, no backup, no downtime.
--auto is the form a scheduler runs. It refuses any stack not marked autoUpdate, any stack
with no healthUrl, and any stack with no database backup configured, since an unattended
update that cannot tell a healthy start from a crash loop is worse than no update at all.
A stack that genuinely has no database says so with `stack set-update --no-database`.
--dry-run is exempt from both backup refusals: it recreates nothing, so it has nothing
to go back from.
Usage:
baryovm stack update <name> [flags]
Examples:
baryovm stack update playground --dry-run
baryovm stack update playground
baryovm stack update playground --auto # what cron runs
Flags:
--auto unattended: refuse stacks not marked autoUpdate
--dry-run report what would update, change nothing
--health-attempts int health checks before declaring failure (default 20)
--health-delay duration wait between health checks (default 3s)
-h, --help help for update
--no-backup skip the pre-update database backup
--service strings limit to these services (defaults to the stack's updateServices)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
If <name> is already registered, up just installs Docker and deploys.
If it is new, pass --provider/--key to provision it first.
Usage:
baryovm up <name> [flags]
Examples:
baryovm up web1 --image nginx:alpine --container site -p 80:80
baryovm up web1 --provider lightsail --key ~/.ssh/id_ed25519 --image app:latest --container app -p 80:8080
Flags:
--container string container name (required)
--dry-run print the plan without creating anything
-e, --env stringArray environment KEY=value (repeatable)
-h, --help help for up
--image string container image (required)
--key string private SSH key to authorize + connect with (required)
--provider string cloud provider: lightsail (oci coming) (default "lightsail")
-p, --publish stringArray port mapping host:container (repeatable)
--pull pull the image before running
--region string cloud region (default: from ~/.aws)
--size string instance size / bundle (default: provider's smallest)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Print the BaryoVM version
Usage:
baryovm version [flags]
Flags:
-h, --help help for version
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Manage the VMs in your fleet
Usage:
baryovm vm [command]
Available Commands:
add Register an existing VM by host + SSH key
bootstrap Install Docker on a VM (idempotent)
exec Run a command on a registered VM over SSH
forget-key Forget a VM's recorded SSH host key, so the next connection learns it again
harden Apply the SSH hardening policy to a VM
list List registered VMs
ping SSH in and report host + Docker status
provision Provision a new cloud VM and register it in the fleet
remove Remove a VM from the fleet (does not destroy the machine)
threats Show what a VM is being attacked with
Flags:
-h, --help help for vm
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Use "baryovm vm [command] --help" for more information about a command.
Register an existing VM by host + SSH key
Usage:
baryovm vm add <name> [flags]
Flags:
-h, --help help for add
--host string public IP or hostname (required)
--key string path to the private SSH key (required)
--port int SSH port (default 22)
--user string SSH user (default "ubuntu")
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Install Docker on a VM (idempotent)
Usage:
baryovm vm bootstrap <name> [flags]
Flags:
-h, --help help for bootstrap
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Run an arbitrary command on one registered VM using the same SSH key already
in fleet.json. This is the same authority as opening an interactive SSH
session; the CLI only shortens the path.
There is no --sudo flag: put sudo in the remote command yourself (prefer
sudo -n so -o json does not hang on a password prompt).
A non-zero remote exit becomes a non-zero CLI exit. Under -o json the envelope
keeps stdout, stderr and exitCode as separate fields.
The remote command must follow -- so flags like -h belong to the remote
process rather than this CLI (e.g. baryovm vm exec web1 -- df -h).
Usage:
baryovm vm exec <name> -- <command>... [flags]
Flags:
-h, --help help for exec
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Forget a VM's recorded SSH host key, so the next connection learns it again
Usage:
baryovm vm forget-key <name-or-host> [flags]
Flags:
-h, --help help for forget-key
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Applies an opinionated, idempotent SSH policy: per-source penalties in sshd
where the daemon supports them, fail2ban with escalating bans, and the small
surface reductions that cost nothing.
It never changes the SSH port, never disables public key authentication and
never touches authorized_keys, so it cannot lock you out. The sshd config is
validated before anything is reloaded, and reloaded rather than restarted, so
an open session survives a mistake.
Usage:
baryovm vm harden <name> [flags]
Flags:
--dry-run report what would change and write nothing
-h, --help help for harden
--ignore strings extra CIDRs fail2ban must never ban (loopback is always exempt)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
List registered VMs
Usage:
baryovm vm list [flags]
Flags:
-h, --help help for list
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
SSH in and report host + Docker status
Usage:
baryovm vm ping <name> [flags]
Flags:
-h, --help help for ping
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Provision a new cloud VM and register it in the fleet
Usage:
baryovm vm provision <name> [flags]
Flags:
--dry-run print the plan without creating anything
-h, --help help for provision
--key string private SSH key to authorize + connect with (required)
--provider string cloud provider: lightsail (oci coming) (default "lightsail")
--region string cloud region (default: from ~/.aws)
--size string instance size / bundle (default: provider's smallest)
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Remove a VM from the fleet (does not destroy the machine)
Usage:
baryovm vm remove <name> [flags]
Flags:
-h, --help help for remove
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)
Reads the SSH authentication record and any fail2ban bans, and summarises
who is hitting the machine, what account names they are guessing, and every
login that actually succeeded.
The successful logins are the part worth reading. The rest is volume.
Usage:
baryovm vm threats <name> [flags]
Flags:
-h, --help help for threats
--since string systemd time expression, e.g. "7 days ago" or 2026-09-01 (default "24 hours ago")
Global Flags:
-o, --output string output format: human | json (default "human")
--strict-host-keys refuse an unknown host instead of learning its key (also BARYOVM_STRICT_HOST_KEYS=1)