← Bosun

Standalone mode (no argus-tty)

Running bosun with no argus-tty installed — the single-operator fallback, the security tradeoff, and switching modes explicitly.

Bosun is built around argus-tty's multi-tenant account model — developer/ deployer/admin tiers, a sudoers whitelist, a dedicated unprivileged webapp-svc service account that secrets are ACL-locked to. If argus-tty isn't installed, bosun no longer refuses to run: it falls back to a standalone mode for a single operator on their own box instead. This doc covers exactly what that mode is, what it isn't, and the tradeoff you're accepting by using it.

When it kicks in

By default (BOSUN_MODE=auto, or nothing set at all): automatically, the moment /usr/lib/argus-tty/lib/common.sh isn't found — no flag to pass, nothing to configure. argus-tty installed takes priority whenever it's present; standalone is purely the fallback for when it isn't. Every bosun subcommand checks for it independently (deployment/lib/common, bin/add.sh, and deployment/bootstrap each do their own check), so there's no scenario where half of bosun thinks argus-tty is installed and half doesn't.

You can also choose explicitly, overriding auto-detection either way — see "Switching modes with bosun mode" below. Both of these are real, supported uses of that:

• Forcing standalone on a box that has argus-tty installed (for other reasons, or temporarily, without uninstalling it).
• Forcing argus-tty strictly, so bosun errors loudly instead of silently degrading to standalone if argus-tty ever goes missing by accident on a host where secret isolation matters.

What actually changes

• No tiers. require_role() always passes — there's no developer/deployer/admin distinction to enforce when there's only one account using bosun at all.
• No separate service account. AT_WEBAPPS_SVC_USER — the account Puma/Sidekiq run as, and the only account with ACL read access to shared/.env — becomes the same account that ran sudo bosun add, not a dedicated unprivileged one. Everywhere bosun normally elevates to that service account (bosun run, the assets:precompile step in do-release.sample) skips the elevation entirely instead, since you're already that account.
• One deploy key copy, not a distribution list. distribute_deploy_key normally scans every admin/deployer account on the host; in standalone mode there's exactly one account to give a copy to.
• A bosun-owned group, bosun-apps, created automatically if it doesn't exist — standing in for argus-tty's webapps group. The standalone account is added to it automatically so it can run install/setup/deploy/run without needing sudo for everything, the same way argus-tty would have put a developer/admin account there.
• AT_RVM_ROOT stays /usr/local/rvm — RVM's multi-user path was never actually argus-tty's to provide; bosun bootstrap installs it either way.

The tradeoff — read this before you rely on it

This is the actual thing argus-tty mode gives you that standalone mode doesn't: secrets stop being isolated from the deploying account. There's no second, unprivileged identity for shared/.env to be locked away from — the one account that can run bosun deploy can also just read DATABASE_URL/SECRET_KEY_BASE directly, because it's the same account Puma/Sidekiq run as. If you add a second human to this box later, they either share full access to the same account, or you're back to needing argus-tty's tier model — standalone mode is for exactly one operator, not a lighter-weight multi-user mode.

Quick start

Nothing different from the normal walkthrough — just skip installing argus-tty:

sudo apt install ./bosun_1.0.0_all.deb   # argus-tty not installed — standalone mode
  # or: sudo add-apt-repository ppa:yadavramlaxman/bosun && sudo apt update && sudo apt install bosun
  sudo bosun bootstrap                     # RVM multi-user, same as always

  sudo bosun add myapp
  #  [WARN] Added 'you' to 'bosun-apps' — log out and back in to pick it up...
  # log out, log back in

  vi /var/www/myapp/shared/deploy.conf
  sudo vi /var/www/myapp/shared/.env
  bosun install myapp
  bosun setup myapp
  bosun deploy myapp main

You only set this once — /etc/bosun.conf

The standalone account defaults to whoever ran sudo ($SUDO_USER). The first standalone command that resolves it this way — normally bosun bootstrap, since that's step one in the walkthrough, or bosun add if bootstrap already ran before argus-tty was removed — saves it to /etc/bosun.conf automatically:

sudo bosun bootstrap
  # [INFO] Saved standalone account 'you' to /etc/bosun.conf — future bosun
  # commands won't need BOSUN_STANDALONE_USER set.

Every bosun command after that — install, setup, deploy, run, version, even run directly as yourself with no sudo at all — reads it from there with nothing to pass:

cat /etc/bosun.conf
  # BOSUN_STANDALONE_USER=you

  bosun install myapp     # just works, no env var needed

/etc/bosun.conf is created once and never overwritten automatically (same idiom as deploy.conf/shared/.env) — edit it by hand if you ever need to change the saved account.

BOSUN_STANDALONE_USER — overriding it, or before it's ever been saved

Two cases need this set explicitly instead of relying on /etc/bosun.conf: a literal root login with no sudo involved at all (no $SUDO_USER to read, and nothing saved yet — bosun errors out clearly rather than guess), or a CI/automation account that should use a different name than whatever ends up in /etc/bosun.conf. An explicit value always wins over the saved one, for that one invocation only:

sudo BOSUN_STANDALONE_USER=deploy bosun add myapp
  BOSUN_STANDALONE_USER=deploy bosun install myapp
  BOSUN_STANDALONE_USER=deploy bosun deploy myapp main

Whatever you pass must already exist as a real system account — bosun checks (id <name>) and errors out immediately if it doesn't, rather than half-provisioning an app around a name that resolves to nothing.

Switching modes with bosun mode

bosun mode                  # show the configured AND effective mode right now
  sudo bosun mode standalone  # force standalone, even if argus-tty IS installed
  sudo bosun mode argus-tty   # require argus-tty — error instead of silently falling back
  sudo bosun mode auto        # back to the default (use argus-tty if present, else standalone)

bosun mode (no argument) is read-only and needs no special privilege — setting one writes to /etc/bosun.conf, so that needs root. It persists the BOSUN_MODE= line in the same file BOSUN_STANDALONE_USER= already lives in, never touching the other — switching modes doesn't lose a standalone account you'd already saved, and saving a standalone account later doesn't lose a mode you'd already chosen.

An explicit BOSUN_MODE=argus-tty bosun install myapp (or standalone) for one command still overrides whatever's persisted, same precedence as BOSUN_STANDALONE_USER above.

Migrating existing apps after a switch — no re-deploy needed

Switching the host-wide mode doesn't touch anything already on disk — your apps' code, releases, and shared/.env content are completely unaffected. What's now stale is who's allowed to read it: file ownership, the ACL grant on shared/.env, and the systemd units' User= were all set up under the OLD mode's service account. For each existing app:

sudo bosun add myapp    # idempotent — re-applies ownership/ACL/unit files
                           # for the mode you just switched to; leaves code,
                           # deploy.conf values, and shared/.env CONTENT alone
  bosun restart myapp     # picks up the new systemd User= for puma/sidekiq

Re-running add here does one thing worth knowing about: it checks every named-user entry on shared/.env's ACL and strips any that aren't the current AT_WEBAPPS_SVC_USER — so moving from argus-tty's webapp-svc to a standalone account's name (or back) actually revokes the old account's standing read access, not just adds the new one alongside it.

One thing switching can't undo: if you were in standalone mode, that one account already had shared/.env readable directly (that's the whole tradeoff — see above). Moving to argus-tty mode locks it down going forward, but doesn't erase the fact that account could already read SECRET_KEY_BASE/DATABASE_URL. Treat a standalone-to-argus-tty move as a signal to rotate those if this box is going from single- to multi-operator.