Declare the SQLite volume mount in fly.toml - #28
Merged
Merged
Conversation
The app now reads its database from the path in the SQLITE_PATH secret, which points into /data. That directory only exists because a volume is mounted there, and the mount was applied by hand rather than through config -- so a deploy from a clean checkout would come up with no /data, fail to open the database, and exit. There is no longer a Postgres instance to fall back to, so that failure would be a full outage. Also correct primary_region, which said sea while the machine and its volume are both in sjc. Volumes cannot attach across regions, so the stale value is the same trap: it would place a machine where no volume exists. 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.
Why
SQLITE_PATHis set on the app and points into/data. That directory exists only because a volume is mounted there — and that mount was applied by hand during the migration rather than through config.So a
fly deployfrom a clean checkout would produce a machine with no/data, fail to open the database, and exit. With the Postgres cluster now gone there is nothing to fall back to, which makes that a full outage rather than a degraded start.What
links_datamount at/data.primary_region, which saidseawhile the machine and its volume are both insjc. Volumes cannot attach across regions, so the stale value is the same trap in a different form: it would place a machine where no volume exists.This matches the state the app is actually running in today — it's config catching up to reality, not a behavior change.
🤖 Generated with Claude Code