The error you received was a server-side failure, not a validation rejection. Could you share a generalized example of the GraphQL request you sent (the mutation shape and the EnvironmentCreateInput fields you included, with any project-specific identifiers redacted)? That would help us determine whether a specific input combination triggered an unhandled code path.

Here is the generalized request, with project-specific identifiers redacted.

Endpoint: POST https://backboard.railway.com/graphql/v2

Headers: authorization: Bearer [account token]; content-type: application/json

Mutation: mutation EnvironmentCreate($input: EnvironmentCreateInput!) { environmentCreate(input: $input) { id name } }

Variables: { "input": { "projectId": "[UUID of existing Hobby project]", "name": "[new unique name]" } }

The EnvironmentCreateInput intentionally contained only projectId and name. This was an empty canary designed to exercise Railway's no-source-environment path and isolate environment creation from application provisioning. No sourceEnvironmentId, ephemeral, stageInitialChanges, service overrides, or variable overrides were sent.

If creation had succeeded, the next operation would have staged only the environment-level configuration { "privateNetworkDisabled": true } using merge: true, then verified that the environment still contained zero services. EnvironmentCreate failed first, so that staging operation was never reached.

The generated name matched ^[a-z0-9][a-z0-9-]*$, was 30 characters, and did not collide with an existing environment. The client timeout was 30 seconds. The response arrived within that window with HTTP 200 and extensions.code: INTERNAL_SERVER_ERROR.

If the creation handler assumes sourceEnvironmentId is present, this request would have exercised the unhandled no-source branch.

The request was turned away at the authorization layer, not by a server fault. It came back "Not Authorized" in about three milliseconds, before it reached the environment creation logic.

The token didn't resolve to an account with access to the project. Your CLI authenticated successfully in the same window, so the account itself is healthy. Check what your script sends. An expired account token or a project token scoped to another project would both land here.

The request shape is fine. sourceEnvironmentId is optional, and the path without it is supported. You'd successfully used that path a few hours earlier that morning to create an environment, stage changes, commit, and delete it.

The confusing part is the code. Auth rejections currently return extensions.code INTERNAL_SERVER_ERROR instead of something auth-specific, which is what pointed you toward a server fault. The message body did carry "Not Authorized", so that's the field to key on.