Skip to content

Command reference

Arnel Robles edited this page Sep 26, 2026 · 2 revisions

Command reference

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

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.

baryovm deploy

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)

baryovm doctor

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)

baryovm stack

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.

baryovm stack add

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)

baryovm stack backup

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)

baryovm stack backups

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)

baryovm stack deploy

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)

baryovm stack list

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)

baryovm stack logs

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)

baryovm stack ps

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)

baryovm stack pull

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)

baryovm stack release

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)

baryovm stack remove

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)

baryovm stack restore

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)

baryovm stack set-update

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)

baryovm stack update

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)

baryovm up

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)

baryovm version

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)

baryovm vm

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.

baryovm vm add

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)

baryovm vm bootstrap

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)

baryovm vm exec

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)

baryovm vm forget-key

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)

baryovm vm harden

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)

baryovm vm list

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)

baryovm vm ping

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)

baryovm vm provision

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)

baryovm vm remove

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)

baryovm vm threats

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)