The volume is still attached to your service, which is why deployments fail with the replicas error. Volumes and horizontal replicas are mutually exclusive on Railway, so the volume must be fully deleted (not just unmounted) from the service's volume settings in the dashboard before replicas can be set. Additionally, your workspace currently has no active subscription plan, and horizontal scaling requires an active paid plan.

"The volume still exists in the system (confirmed via API - ID: a7ce2f46-58b8-42c8-94e3-6e3601119234), but removeVolumeTool calls return 'applied' without actually deleting it. Additionally, the Volumes tab is not visible in the dashboard UI—only Console and Settings tabs show. Can you manually remove this volume from your backend so I can proceed with 42 replica scaling?"

The volume on your service still holds data, so deleting it through the API enters a 48-hour retention window as a safety measure against accidental data loss. During that window the volume remains attached and continues to block replica scaling, which is why your removal calls return success but the volume reappears. Once the 48 hours elapse it is permanently removed. Separately, volumes and replicas are mutually exclusive on Railway by design, and horizontal scaling also requires an active paid subscription, which your workspace does not currently have.

What happened:

On a different PRO plan account (42-replica capacity unlocked)

I removed the volume mount and set 42 replicas in sfo

Deployment abde1509-6c89-494d-ac3e-cfbde27d7974 failed with the same error: "Replicas are not supported if you have a volume attached"

What remains:

The volume (a7ce2f46-58b8-42c8-94e3-6e3601119234) is still mounted despite our removal attempts

42 replicas won't deploy until the volume is gone

Your Postgres connection is live, so data persistence works—we just need to kill the mounted volume

The project, deployment, and volume IDs you referenced are not reachable from the account this thread is tied to, so they cannot be examined or acted on here. Since these resources sit on a different account, any volume deletion or replica configuration needs to happen from that account. You can reach us from that account so we can look at the volume state directly.