deploy-app

Deploy a Kickoff app

One command does the whole release. This skill is mostly about verifying it and knowing which failures matter — a deploy that prints a success line is not the same as a deploy that worked.

Before anything: establish the target

Never assume. Confirm these from the project's own docs (docs/04-deployment/), its CLAUDE.md, or by asking:

If the project keeps this in a deployment doc, read it once and cache it in your answer — do not re-derive it every deploy.

Deploy

Check what would move first, then deploy:

ssh <user>@<host> 'cd <path> && git fetch origin <branch> --quiet \
  && echo "origin: $(git log --oneline -1 origin/<branch>)" \
  && echo "server: $(git log --oneline -1 HEAD)"'

ssh <user>@<host> 'cd <path> && ./bin/deploy -b <branch> 2>&1 | tail -60'

tail is deliberate: composer/npm output is long and the last 60 lines contain every decision point.

Gotcha: Always pass -b <branch>. With no -b, bin/deploy falls back to "latest tag" and git describe fails outright on a repository that has never been tagged.

What bin/deploy does, in order: pre-deploy database dump → artisan down → checked git checkout/pull → composer install --no-dev → npm ci && npm run build → clear config/route/view caches → migrate --force → operations --isolated → optimize → horizon:terminate → chown to the web user → reload PHP-FPM → artisan up → health check, with an automatic rollback to the previous commit if the health check does not pass.

Verify

Always run this afterwards. The script's own success line is not the whole story.

ssh <user>@<host> 'cd <path> && git rev-parse --short HEAD \
  && php artisan horizon:status \
  && curl -s -o /dev/null -w "login=%{http_code}\n" https://<domain>/login'