2 days ago
We are building a deterministic deployment automation workflow for an isolated Hobby test environment. We need the official supported contract for setting, reading back and reconciling per-service CPU/RAM limits before any resource changes. This is a technical clarification request; please do not change any resources.
The provider-maintained CLI schema exposes serviceInstanceLimitsUpdate(input: ServiceInstanceLimitsUpdateInput!): Boolean!, with serviceId, environmentId, vCPUs: Float and memoryGB: Float. Please confirm whether this is a supported integration contract and provide an official schema/type/reference for the following:
-
CPU write: supported API/CLI/config mechanism; exact field/property, request/config shape and type, unit, accepted value type, minimum/maximum and granularity/precision; whether fractional vCPU is supported; meanings of zero, null, omission and unset, and invalid-value behavior.
-
RAM write: supported API/CLI/config mechanism; exact field/property, request/config shape and type, unit, accepted value type, minimum/maximum and granularity/precision; whether fractional GB/MB is supported; meanings of zero, null, omission and unset, and invalid-value behavior.
-
Hobby: are these configurable limits officially supported on Hobby? Please identify the Hobby-specific contract if plans differ, including whether 1 vCPU and 1 GB are valid.
-
Authority: supported credential types and minimum scope and workspace/project/environment role. Please distinguish account/user, workspace and environment-scoped project tokens, and CLI session credentials. No role or permission changes are requested.
-
Apply/deployment: do changes alter the current container immediately, restart it, create a deployment, require a staged apply, or apply only on the next deploy? Are CPU and RAM updated atomically? Can old/new deployments overlap, and what determines that overlap's lifecycle? We need deterministic cost and concurrency accounting.
-
Readback: official API/CLI/config-read path and exact response fields/JSON shape, numeric types, units and unset representation. In particular, please document serviceInstanceLimitOverride and serviceInstanceLimits, explicit overrides versus merged defaults, and whether returned values are configured/enforced maxima rather than observed usage.
-
Idempotency: does repeating identical values trigger another restart/deployment or billing effect? Is there a native idempotency key or revision/version mechanism?
-
Unknown outcome: if an update may have reached Railway but its response is lost, what official readback/match criteria establish that the desired limits were applied before retrying? Is request/trace correlation available, and does a matching read settle the original update?
The founder requested this inquiry because reviewed public documentation did not establish the complete integration contract, especially the custom-scalar readback and update effects. We need supported behavior, not reverse-engineered GraphQL/browser requests. No private resource identifiers are needed to answer these contract questions.
Prepared with Railway's support template (v1).
1 Replies
2 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 2 days ago
a day ago
Not Railway staff, so I can't confirm any of this as "supported contract" — that word is doing real work in your request and only Railway can supply it. But your eight questions split cleanly into ones you can settle yourself in minutes and ones that genuinely need staff.
1, 2, 6 and half of 7 are introspectable right now
serviceInstanceLimitsUpdate being in the CLI schema means the API is introspectable, so types, nullability and defaults are available as fact:
curl -s https://backboard.railway.app/graphql/v2 \
-H "Authorization: Bearer $RAILWAY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query":"{ __type(name:"ServiceInstanceLimitsUpdateInput"){ inputFields { name defaultValue type { kind name ofType { kind name } } } } }"}'
That gives you, per field: exact type (Float vs Int answers fractional support directly) and whether it's NonNull. Note that omission and explicit null are different operations in GraphQL — an omitted field is absent from the input map, a null field is present with a null value. If the field is nullable, those likely mean different things to the resolver (probably "leave alone" vs "clear the override"), and one test write confirms which.
For readback (q6):
curl -s https://backboard.railway.app/graphql/v2 \
-H "Authorization: Bearer $RAILWAY_TOKEN" -H "Content-Type: application/json" \
-d '{"query":"{ __type(name:"ServiceInstance"){ fields { name type { kind name ofType { kind name } } } } }"}'
Check whether serviceInstanceLimitOverride and serviceInstanceLimits are separate fields and what each returns. The naming suggests override = what you explicitly set, limits = effective values after defaults merge — but that's the shape of the question, not the answer. Set an override on a test service, read both, clear it, read both again. Two writes gets you full semantics including the unset representation.
Introspection won't give you min/max or granularity — those are resolver-side validation, invisible to the schema. Bisect on a throwaway service; the error messages usually name the bound.
3, 4, 5, 8 and the billing half of 7 need staff
3 (Hobby limits): plan policy, changes over time. A community answer goes stale.
4 (credential scope): which token types carry authority and the minimum role. Guessing at auth scope is how people over-provision tokens — take only Railway's word here.
5 (apply semantics): immediate vs restart vs next-deploy, CPU/RAM atomicity, deployment overlap. This is what actually determines whether your workflow is deterministic. You could observe it on a test service, but observed behavior isn't a contract — it can change silently, which is the exact problem you're avoiding.
7 (billing): whether a repeat identical write triggers another deployment or billing event.
8 (lost response): without a server-side idempotency key, readback is your only reconciliation primitive — read current, compare to desired, retry on mismatch. That's safe here because the write sets absolute values rather than incrementing, so a replay is harmless. But whether a matching read proves your update landed rather than a concurrent one needs a revision/version field, and whether one exists is for Railway to say.