Deploy from CI — fly.toml was a file that did nothing - #3
Merged
Conversation
Deploy automation was deferred so a human could watch the first-ever
deploy of new infrastructure, with a note to automate once phase 1 was
stable. Phase 1 is stable, and leaving it deferred turned out worse than
what it avoided: fly.toml only took effect if someone remembered to run
`fly deploy` by hand.
That failed silently on 2026-09-09. A scale-to-zero change merged with
CI fully green and never reached Fly — the app kept running always-on,
and the config looked applied because the commit was on master. It was
only caught by checking the machine state directly. Config that silently
doesn't apply is more dangerous than no config, because it reads as done.
Deploy runs on push to master only, after BOTH matrix legs (sqlite and
postgres) pass — this service runs one codebase against either dialect,
so a green sqlite leg alone is not evidence a deploy is safe.
Two flags, each for a concrete reason:
--strategy immediate this app mounts sentinel_license_data, and the
default rolling strategy stands up a parallel
machine first, which errors on the volume's
single attachment slot.
--ha=false Fly otherwise provisions two machines. It did
exactly that on the manual deploy of the sibling
Sync service and the extra had to be scaled away
by hand; the volume could not serve two anyway.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deploy automation was deferred here so a human could watch the first-ever deploy, with a note to "automate once phase 1 is stable". Phase 1 is stable, and leaving it deferred turned out worse than what it avoided.
It failed silently on 2026-09-09. A scale-to-zero change merged with CI fully green and never reached Fly — the app kept running always-on, and it looked applied because the commit was on master. It was only caught by checking the machine state directly with
fly machines list.Config that silently doesn't apply is more dangerous than no config, because it reads as done.
Deploy runs on push to master only, after both matrix legs (sqlite and postgres) pass — this service runs one codebase against either dialect, so a green sqlite leg alone isn't evidence a deploy is safe.
Two flags, each for a concrete reason:
--strategy immediatesentinel_license_data; the default rolling strategy stands up a parallel machine first and errors on the volume's single attachment slot--ha=falseUses the existing
FLY_API_TOKENrepo secret, already scoped tosentinel-license.🤖 Generated with Claude Code