a month ago
Hello Support team I'm curious about these security update processes you've been running through. Since seeing these notices I'm seeing quiet a few of my projects now not displaying the PITR via PostGres.
Has any of these updates affected this function in the database builders. I'm VERY frustrated right now as one project in specific is broken and there's no cause for it.
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
I would separate two things here: PITR not being displayed and the database/service itself being broken. There is not enough evidence yet to conclude that Railway's security updates disabled PITR.
Railway PITR depends on the Postgres service configuration and WAL archiving state. When PITR is enabled, Railway creates a Postgres-PITR bucket, adds the WAL_ARCHIVE_* variables, redeploys Postgres, and the restore picker only appears once archiving/base-backup initialization is healthy.
First check the affected Postgres service:
Backups tab: does it show PITR disabled, unavailable, or simply no restore window?
Account feature flags: confirm the PITR feature flag is enabled. Railway has had cases where the PITR controls disappeared until this flag was enabled.
Image: confirm the service is using the official Railway Postgres image on a supported major tag such as ghcr.io/railwayapp-templates/postgres-ssl:17.
Variables: check whether the WAL_ARCHIVE_* variables that PITR created are still present.
Postgres deploy logs: look for pgBackRest/archive errors or a failed restart after the security update.
Volume health/free space: make sure the database is not failing for an unrelated storage/WAL reason.
If PITR was previously working and the WAL_ARCHIVE_* configuration and PITR bucket are still present, but the UI stopped exposing PITR immediately after a Railway-managed image/security rollout, I would not disable/re-enable PITR yet, because that can complicate the existing recovery history.
Instead, provide Railway with the project/service ID and the last timestamp where PITR was visible, and ask them to verify:
current archive health;
PITR bucket/base-backup state;
whether the Postgres image update changed the archiver initialization state;
whether the service still has a valid PITR restore range server-side even if the dashboard is not showing it.
If you can share the affected Postgres service's image tag, current deployment status/logs, and what exactly appears in the Backups tab, we can narrow this down without risking the existing recovery chain.