Detached volumes can't be deleted — CLI and API both report success, neither takes effect

Plan: Hobby · Region: US East · CLI: 5.35.0 (also reproduced on 5.31.0, and directly against the GraphQL API, so it isn't CLI-version-specific)

Summary

A volume with no service attached appears to be unreachable by every interface that could delete it:

• It doesn't render in the dashboard — the UI draws volumes on their service's card, and a detached volume has no card to appear on.
• railway volume delete prints Volume "<name>" deleted, and the volume is still there afterwards.
• The GraphQL mutation volumeDelete(volumeId:) returns {"volumeDelete": true}, and the volume is still there afterwards.

So it's invisible in the UI, unaffected by the CLI and the API, and still billed. I haven't found a supported way to remove it.

How it happened

I migrated a Postgres service to a different region and deleted the old service afterwards. Deleting the service detached its volume instead of removing it, leaving a volume whose volumeInstance has serviceId = null and state = READY.

I suspect anyone who migrates a database service ends up with one of these.

Reproduction

1. Create a service with a volume.
2. Delete the service. The volume survives, detached.
3. railway volume list shows it as Attached to: N/A. The dashboard doesn't show it at all.
4. railway volume delete --volume <id> --yes → prints Volume "<name>" deleted.
5. railway volume list → still present. Same result querying the API directly.

What I tried

| Attempt | Reported | Actual |

| --- | --- | --- |

| railway volume delete while detached (CLI 5.31 and 5.35) | Volume "<name>" deleted | still present |

| GraphQL mutation { volumeDelete(volumeId: "…") } | {"volumeDelete": true} | still present |

| Attach it to a new service, then railway volume delete | Volume "<name>" deleted | still present |

| Attach it to a new service, then delete that service via CLI | service removed | volume detached again, survived |

| Attach it to a new service, then delete that service via the dashboard | service removed | volume detached again, survived |

Each attempt was verified with both railway volume list and a direct GraphQL query of project.volumes. The volume id never changed.

Underlying state

Querying project.volumes { volumeInstances { serviceId state } }:

orphaned volume    volumeInstances = [ { serviceId: null,       state: READY } ]
healthy volume     volumeInstances = [ { serviceId: "<svc-id>", state: READY } ]

The detached volume keeps a volumeInstance with a null serviceId. Schema introspection shows no volumeInstanceDelete mutation, so there's no way to remove that instance — which I'd guess is what stops volumeDelete from completing.

Expected

Either volumeDelete removes a detached volume, or it returns an error saying why it can't — rather than reporting success while the volume persists and keeps billing.

Two smaller things in the same area

1. Deleting a service silently orphans its volume. If that's intentional, the volume should stay visible somewhere in the UI afterwards, otherwise it becomes unreachable the moment the service is gone.
2. The success message is wrong. Volume "<name>" deleted and volumeDelete: true on a no-op is what made this slow to diagnose — the natural read is caching or propagation lag, not failure, so you keep waiting for something that's never going to happen.

Impact

Small in absolute terms — the volume is ~116 MB, about $0.02/month. But it can't be removed or even seen, and it seems like a predictable side effect of a routine database migration.

Happy to share the project, volume and service ids privately if that's useful for reproducing.