17 days ago
Description of the issue:
We need to rotate WAL_ARCHIVE_KEY / WAL_ARCHIVE_SECRET on a production Postgres service (credentials were exposed via a CLI misuse on our end, not a Railway issue). There's no documented in-place rotation for these two variables, so we're trying to confirm the safest path before touching production backup infrastructure.
What we've pieced together so far (please correct anything wrong):
- Disabling PITR stages a patch that deletes the Postgres-PITR bucket by default, but that step can apparently be edited out of the staged patch before deploying, preserving the old bucket/backup history under the old credentials.
- Re-enabling PITR creates a new bucket + new credentials + a fresh base backup, and does not extend the old backup chain — so you end up with two separate, non-continuous restore histories rather than one continuous one.
Questions:
- Is there any in-place way to rotate WAL_ARCHIVE_KEY/WAL_ARCHIVE_SECRET without a full disable/re-enable of PITR? Or is disable → edit staged patch to keep the old bucket → re-enable → verify → delete old bucket genuinely the only supported path?
- WAL uploads go to t3.storageapi.dev and are billed as network egress — is there any way to route WAL archiving over Railway's private network instead of the public internet, the way Postgres/Redis service-to-service traffic uses *.railway.internal? If not currently possible, is it planned?
Appreciate any confirmation or correction — trying to avoid guessing on anything backup-related.
Service: Postgres (PITR / backups feature)
1 Replies
17 days ago
There is no in-place rotation for WAL_ARCHIVE_KEY/WAL_ARCHIVE_SECRET. The supported path is: disable PITR, edit the staged patch to remove the bucket-deletion step (preserving the old bucket and its restore history), deploy, then re-enable PITR. Re-enabling creates a new bucket with fresh credentials and a new base backup, so you end up with two separate, non-continuous backup chains. The old bucket stays restorable until you delete it. For the private networking question, buckets are currently only accessible via public networking, so WAL uploads will continue to go over the public internet and count as service egress. All WAL and base backup data is zstd-compressed before transit, so egress is billed on the compressed size.
Status changed to Awaiting User Response Railway • 17 days ago
10 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 10 days ago