README: this service is deployed, deploys from CI, and scales to zero - #7
Merged
Conversation
Deploy automation was deferred so a human could watch the first-ever deploy of new infrastructure, including this family's first Postgres instance. That rationale expired once the service went live, 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 the tests pass. --ha=false because Fly provisions TWO machines by default. It did exactly that on this service's manual deploy and the extra machine had to be scaled away by hand. No --strategy override: this app has no volume, so the default rolling strategy is fine. The sibling License service needs `immediate` because it mounts one. Needed a repo secret that did not exist — this repo had NO secrets at all, so a deploy job would have failed on its first run. FLY_API_TOKEN is now set, scoped to sentinel-sync only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
No Dependabot config existed here. That is the same gap that produced the Sentinel AI agent's three production breakages in two days: mcp 2.x renaming a symbol, Starlette removing on_startup, and a ceiling added to stop the second one silently pinning the service to a Starlette line carrying 7 advisories. All three surfaced on a rebuild of a repo nobody had rebuilt since June. `pip-audit --strict` in CI catches a known advisory against what is already pinned. It does nothing about a lockfile quietly ageing out of support, which is the failure that actually happened. No auto-merge workflow, deliberately. This repo now deploys to Fly on push to master, and GitHub does not trigger `on: push` workflows for commits pushed with GITHUB_TOKEN — so an auto-merge would land a bump on master WITHOUT deploying it, and nothing would report an error. That is an observed bug in Sentinel-Command, where four frontend bumps merged and never shipped. A human merge triggers the deploy normally. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Status section said "Not yet deployed — no Postgres instance or Fly app provisioned yet". It has been live since 2026-09-07, on the shared sentinel-postgres cluster in its own role-isolated database. A README that says a running production service doesn't exist is the worst kind of stale, because it reads as authoritative. The Deploy section was likewise pre-CI, and told the reader that provisioning Postgres was still their decision to make. Adds what wasn't documented anywhere: that the service now sleeps between its 30-minute pushes, why that's safe (~3s boot inside Fly's ~8s proxy window, and a fail-soft push whose cursors only advance on confirmed success, so a missed cycle loses nothing), and why it deliberately has no dump job. 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.
Documentation only — no code changes.
The Status section said "Not yet deployed — no Postgres instance or Fly app provisioned yet." It has been live since 2026-09-07, on the shared
sentinel-postgrescluster in its own role-isolated database. A README that says a running production service doesn't exist is the worst kind of stale, because it reads as authoritative.The Deploy section was likewise pre-CI and told the reader that provisioning Postgres was still their decision to make.
Adds what wasn't documented anywhere: that the service sleeps between its 30-minute pushes, why that's safe (~3s boot inside Fly's ~8s proxy window, and a fail-soft push whose cursors only advance on confirmed success — so a missed cycle loses nothing), and why it deliberately has no dump job.
🤖 Generated with Claude Code