9 days ago
I need clarification on Railway Public GraphQL API semantics for a volume name-only update. This is a guidance-only question; please do not modify any project.
The current live schema exposes:
Mutation.volumeUpdate(volumeId: String!, input: VolumeUpdateInput!): Volume!
and the current VolumeUpdateInput contains only:
name: String
The target use is a name-only operation such as:
volumeUpdate(volumeId: "", input: { name: "dex-ebw-p0-data" })
The volume would already exist and already be attached to the intended service/environment/mount path. We would not pass any mount-path, service, environment, state, source, variable, or other configuration field.
Could Railway please clarify:
- Does volumeUpdate(volumeId, {name}) trigger or require a build?
- Does it trigger or require a deployment?
- Can it start, restart, replace, or otherwise affect the running service/process?
- Is the volume name change applied immediately, or does it create a staged change / EnvironmentPatch?
- If it creates a staged change, what operation is required to make the name effective?
- Would any commit, Deploy, accept_deploy, redeploy, or other finalization action be required solely to complete the rename?
- Does a name-only volumeUpdate preserve the same volume ID, service attachment, environment binding, mount path, and stored data?
- Can the final renamed state be reached with only the single volumeUpdate(name) operation and no deployment or other resource mutation?
We are specifically trying to distinguish a metadata-only volume rename from operations that modify a volume instance or trigger service deployment.
Please provide the current platform semantics only. No cleanup, deployment, test mutation, or project change is requested.
Pinned Solution
9 days ago
- No.
- No...?
- Immediately
- Answered above
- It only changes the name.
7 Replies
9 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 9 days ago
9 days ago
volumeUpdate doesn't require a redeployment or a build.
Also, the volume ID doesn't change.
9 days ago
Thanks — that confirms two important points: a name-only volumeUpdate does not require a build or redeployment, and the volume ID remains unchanged.
Could you also confirm:
- Does the rename trigger any deployment automatically?
- Can it start, restart, replace, or otherwise affect the running service/process?
- Is the name change applied immediately, or does it create a staged change / EnvironmentPatch?
- If it is staged, is any commit, Deploy, apply, accept_deploy, redeploy, or other finalization action required to make the new name effective?
- Does the name-only update preserve the existing service attachment, environment binding, mount path, and stored volume data?
No project modification is requested; this is only a platform-semantics clarification.
9 days ago
Thanks, that fully answers the rename behavior.
One final related clarification about the preceding volume creation step:
For an empty Railway service with no source, no image, no existing deployment, and no running process, if the Public API volumeCreate creates and attaches a persistent volume using projectId, serviceId, environmentId, and mountPath:
- Does that operation itself trigger or require a build?
- Does it create, trigger, or require a service deployment?
- Can it start, restart, or replace a service process?
- Is the volume create/attachment effective immediately, or does it create a staged change / EnvironmentPatch?
- Is any commit, Deploy, apply, accept_deploy, redeploy, or other finalization required solely to make the volume attachment effective?
This is only a platform-semantics clarification; no project modification is requested.
9 days ago
I have answered 4 of those questions above. You're asking the same thing in different wording.
1/2/3 No
4 Immediately
5 If you're attaching a volume, you'll need to redeploy the target service for it to take effect.
0x5b62656e5d
I have answered 4 of those questions above. You're asking the same thing in different wording. 1/2/3 No 4 Immediately 5 If you're attaching a volume, you'll need to redeploy the target service for it to take effect.
9 days ago
I appreciate your answer.
Thank you!
Status changed to Solved 0x5b62656e5d • 9 days ago
9 days ago
Need more information:
I have one remaining API-semantics question about serviceConnect.
For an existing empty service with no source, no deployment, no build, and no running process, the current serviceInstanceAutoDeployStatus is enabled=false, canEnable=false, reason=NO_REPO.
If I then call serviceConnect(id, { repo: "...", branch: "main" }):
- Does serviceConnect itself create, trigger, or queue any deployment?
- Does it itself create, trigger, or queue any build?
- Does connecting the repo enable or create an autodeploy/deployment trigger?
- Is the pre-connect enabled=false state preserved after the repo is connected, or is autodeploy recomputed/enabled?
- Is there a supported ordering that guarantees the repo can be connected while autodeploy remains disabled and no deployment/build can occur?
I only need the current platform semantics; no project change is requested.
Status changed to Awaiting Conductor Response Railway • 9 days ago