Static sites (no containers)

Not everything on a VM is a container. A built static site is files the host's own web server serves, and it needs three things a compose stack does not: a root-owned destination, no compose up, and a command or two afterwards.

{
  "localRoot": "~/repos/baryo-web",
  "remoteRoot": "/var/www/baryo-web",
  "sync": ["out/"],
  "builds": [],
  "sudo": true,
  "noCompose": true,
  "postDeploy": [
    "restorecon -R /var/www/baryo-web || true",
    "nginx -t",
    "systemctl reload nginx"
  ]
}

baryovm stack add baryo-web --vm oracle --path /var/www/baryo-web \
  --release-file ~/repos/baryo-web/baryovm.release.json

npm run build          # or whatever produces out/
baryovm stack release baryo-web

Three notes worth having before you run it:

sudo elevates the remote side, not the local one. The rsync becomes --rsync-path="sudo -n rsync", because it is the copy of rsync running on the VM that needs to write into a root-owned path, and the image builds, both hook lists and the closing compose up run as root on the VM for the same reason. The account you SSH as needs passwordless sudo for it. A stack registered with stack add --sudo gets all of this for its release even if the manifest says nothing, and the fold is one way: "sudo": false in the manifest cannot turn it off again.

The -n matters. Without it, a host that does want a password writes the prompt into rsync's data channel, which corrupts the protocol stream, so the transfer hangs or dies with something opaque instead of telling you sudo needs a password. With -n it fails at once and says so.

Three things change when you turn it on.

The receiving rsync is root, so -a starts honouring -o and -g, which it cannot do as an ordinary user: files arrive with the local source's ownership rather than owned by the account you SSH as.

Hooks run under sudo -n "${SHELL:-/bin/sh}" -c, so sudo's env_reset and secure_path apply: $PATH is root's secure_path and $HOME is /root, so a hook calling a per-user tool (a dotnet under your home directory, nvm's node) needs its absolute path. The shell is the one your login shell would have been, not sh, so a hook written in bash keeps working.

And the SSH user needs sudo rights to run a shell, not only the individual programs. A sudoers line granting NOPASSWD: /usr/bin/systemctl on its own refuses the whole hook with "a password is required", which reads like a password problem and is a permissions one. If that is your host, grant the shell or drop --sudo and keep the elevation inside each command.

postDeploy runs in order and stops at the first failure. Putting nginx -t before the reload means a broken config fails the release loudly instead of reloading nothing and reporting success.

No backup runs for a static stack, because there is no database registered. The previous release is not kept, so the rollback is to rebuild the previous commit and release again.