Try clicking on your database, press Ctrl/Cmd + K, and redeploy source image.

If that doesn't work, you'll need to create a new Postgres service, delete the old service (not the volume), and drag the old volume over the new Postgres service to swap volumes.

AWESOME....we are back. Thank you for the amazingly fast response and will note that for future reference.

Is this possible? 1. Ask Railway to clear the stale source.repo permanently. This is the one I'd actually prioritize, because it's a latent landmine. "Redeploy source image" worked around the conflict — it forced the image this once. But if the stale source.repo/source.branch fields are still set on the Postgres service, a future ordinary redeploy (or an auto-deploy triggered by something) could rebuild your app onto Postgres again and drop you right back into this outage. So reply on the thread: confirm the source-image redeploy fixed it, thank them, and explicitly ask them to clear the stale source.repo/source.branch fields so only source.image remains — otherwise this recurs. That closes the actual root cause, not just the symptom.

Update: "Redeploy source image" (via Cmd+K) worked — the Postgres service

booted the postgres-ssl:17 image against the existing volume, and all my data

is intact. Thank you.

One concern before I consider this closed: I believe the underlying cause —

the stale source.repo / source.branch fields conflicting with source.image —

is still present on the service. "Redeploy source image" worked around it by

forcing the image this time, but if those repo/branch fields are still set,

I'm worried a future ordinary redeploy (or an auto-deploy) could rebuild my app

onto the Postgres service again and repeat this outage.

Could you please clear the stale source.repo / source.branch fields on the

Postgres service (service ID 74856220-35d1-4200-9a1c-0452182d333d) so that only

source.image remains? I'd like to make sure this can't recur on the next

redeploy.

Thanks again for the quick help.

It's possible that you ran railway up via CLI into the Postgres service.

If this happens again, then I'd recommend creating a new Postgres service and migrating the old volume over.

Sorry, I have Claude working with me right now and it is 'contingency planning' My database is back up and running just fine

Glad you're back up! The stale repo binding is worth clearing so this can't recur. On the Postgres service, go to Settings > Service Source, disconnect the current source, then reconnect it by selecting the Docker image (postgres-ssl:17). That removes the repo/branch fields permanently.

Thanks, but "redeploy" has now failed three times with the same generic container-creation error and no build or deploy logs, so I'd like to get past the retry loop and have someone look at the actual container spec.

Context: this is a volume-backed Postgres service (postgres-ssl:17). Per your earlier guidance, I disconnected the service source and reconnected it as the Docker image to clear the stale source.repo/branch binding. The failures started immediately after that reconnect. The prior deployment — same image, same config — is still running fine, so the image itself is not the problem.

Because it fails at container creation before any logs, this looks like an infrastructure/spec issue, not my configuration. Can you please:

Confirm the volume is able to detach from the still-running prior deployment so the new container can mount it. If this is a single-attach volume conflict, that would explain a no-logs container-creation failure.

Diff the container spec generated by the source reconnect against my last successful deployment — did the disconnect/reconnect drop or alter the volume mount path (/var/lib/postgresql/data), any Postgres env vars, or a start command?

Confirm there's no platform/scheduler or region capacity issue causing the container creation to fail.

Tell me the safe procedure to apply the corrected image-only source without risking the currently-running deployment — I do not want to lose the deployment that's keeping my database online.

Please do not take any destructive action on the volume — production data lives there. Failed deploy IDs: [FAILED_DEPLOYMENT_ID]; last known-good deployment still serving: [GOOD_DEPLOYMENT_ID].

The failed deployments are trying to pull docker.io/library/postgres-ssl:17 (Docker Hub), which doesn't exist. The correct image is ghcr.io/railwayapp-templates/postgres-ssl:17 (GitHub Container Registry). When you reconnected the source, the image reference was likely saved without the full registry prefix. Your volume and its ~485 MB of data are intact. To fix this, disconnect the source on the Postgres service again and reconnect it using the full image path ghcr.io/railwayapp-templates/postgres-ssl:17. Your currently running deployment will keep serving until a new one succeeds and replaces it.