11 days ago
Project ID: d3e04cf4-c19b-42ee-b592-3ce6ec3ad0a7
Environment: prod
Steps:
- Added new services from "Postgres HA" template (created Postgres-1, Postgres-2, Postgres-3, etcd-1, etcd-2, etcd-3, "Postgres HA") https://railway.com/deploy/postgres-ha
- Ran into an unrelated issue with one of the underlying services and decided deleting the cluster and starting fresh would be the cleanest fix
- Deleted each service and associated volume and deployed the changes
- Created "Postgres HA" again, but this time it added a random suffix to each service (e.g. "Postgres-1-ucHt" instead of "Postgres-1")
This led me to the Project Settings -> Danger -> Manage Services list which still shows all the original services even though they have been deleted. I also attempted to delete them from this list multiple times and they still remain (deployed changes each time).
Goal: I would like to use the original names without the suffixes. It messes up the sync between environments (since my staging environment still has the original names, so it tries to create them each time).
I could just create a new environment and delete this "prod" environment if that's the easiest way to get a "clean slate" with service names.
2 Replies
Status changed to Awaiting Railway Response Railway • 11 days ago
7 days ago
Thanks for the detailed writeup — that helped a lot. Here's what's happening:
The mental model: in Railway, a service is a project-level thing, and each environment holds an instance of it. Names are unique at the project level, so the same service can appear in prod and staging under one name. When you deleted Postgres-1/etc. in prod, you removed the prod instance — but staging still had its instances, so the underlying service rows (and their names) stuck around. When the template ran again, it found those names taken and appended a 4-char suffix to avoid the collision.
The Manage Services list in Danger reflects project-level services, so the originals show up there as long as any environment still has an instance — that's why your retries didn't free the names.
Cleanest path to recover the original names (keeps staging intact):
- In
prod, delete the suffixed services + their volumes:Postgres-1-ucHt,Postgres-2-d-UZ,Postgres-3-MH2R,etcd-1-7KmC,etcd-2-JMvz,etcd-3-hily,Postgres HA-VwAN. - Instead of redeploying the template, sync the Postgres HA stack from
staging→prod. That attaches prod instances to the existing service rows, so the names line up and env-sync stops trying to recreate them on every change.
Full reset (if you'd rather start clean): delete the services + volumes in both envs, deploy the changes in each, then redeploy the template once. Destructive to staging, but you get the original names in a single pass.
Let me know how else we can help.
Status changed to Awaiting User Response Railway • 7 days ago
codydearkland
Thanks for the detailed writeup — that helped a lot. Here's what's happening: **The mental model**: in Railway, a *service* is a project-level thing, and each environment holds an *instance* of it. Names are unique at the project level, so the same service can appear in `prod` and `staging` under one name. When you deleted Postgres-1/etc. in `prod`, you removed the prod instance — but `staging` still had its instances, so the underlying service rows (and their names) stuck around. When the template ran again, it found those names taken and appended a 4-char suffix to avoid the collision. The Manage Services list in Danger reflects project-level services, so the originals show up there as long as any environment still has an instance — that's why your retries didn't free the names. **Cleanest path to recover the original names (keeps staging intact):** 1. In `prod`, delete the suffixed services + their volumes: `Postgres-1-ucHt`, `Postgres-2-d-UZ`, `Postgres-3-MH2R`, `etcd-1-7KmC`, `etcd-2-JMvz`, `etcd-3-hily`, `Postgres HA-VwAN`. 2. Instead of redeploying the template, sync the Postgres HA stack from `staging` → `prod`. That attaches prod instances to the existing service rows, so the names line up and env-sync stops trying to recreate them on every change. **Full reset (if you'd rather start clean):** delete the services + volumes in both envs, deploy the changes in each, then redeploy the template once. Destructive to staging, but you get the original names in a single pass. Let me know how else we can help.
6 days ago
Thank you for the service explanation, that makes much more sense now.
I performed your cleanest path suggestion by deleting then syncing from staging and that resolves my issue. Thanks again!
Status changed to Awaiting Railway Response Railway • 6 days ago
Status changed to Solved travtarr • 6 days ago