← Bosun

Customizing deploy for one app

Overriding do-release with a full script instead of a hook DSL — for one app, with a safe built-in fallback.

The built-in deploy (do-release) manages exactly puma + sidekiq for every app, unconditionally — no config knob to learn for the common case. If one specific app needs something different (a different background worker like sneakers instead of Sidekiq, extra build steps, a health check, whatever), override the whole script instead of configuring around the edges:

cp /usr/lib/bosun/deploy/do-release.sample /var/www/myapp/shared/do-release
  chmod +x /var/www/myapp/shared/do-release
  vi /var/www/myapp/shared/do-release        # it's your script now, edit freely

bosun deploy myapp <branch> checks for shared/do-release first and, if it's present and executable, runs that instead of the built-in default — for myapp only, every other app on the box keeps using the default untouched. Copied-and-unedited it behaves identically to the built-in default, so the first useful step after copying it is deploying once with no changes, to confirm the override wiring itself works before customizing.

If an app has no override at all (or one that exists but isn't executable — e.g. someone forgot the chmod +x above), deploy doesn't fail or block: it prints a one-line, non-blocking warning to that effect and proceeds with the built-in puma+sidekiq default. This is just a safety net so a missing/mistyped override is visible in the deploy's own output instead of silently falling back with no trace — most apps are expected to never need an override at all. See custom-service.md for adding a third service this way.

This is a full script replacement, not a hook, so it can do anything a whitelisted developer/admin already can — different systemctl units, or run a worker via docker instead of systemd entirely (already fully whitelisted, and sidesteps the fact that developers have no way to create new unit files themselves). do-release.sample's comments walk through both options for the "swap Sidekiq for a sneakers worker" example. What it can't do is grant new privileges — every sudo call in your override is still checked against the exact same developer/admin sudoers whitelist as everything else in argus-tty; writing your own script doesn't add to it.