9 days ago
The Problem: I am following the Railway API documentation to trigger a deployment programmatically via GraphQL. Despite receiving a successful response (true), no new deployment appears in the Railway dashboard.
Documentation Followed:
"Deploy a specific service in an environment. Trigger a deployment for a specific service:
mutation environmentTriggersDeploy(...)"
My Setup: We use a GitHub Actions CI to manage a monorepo. The script identifies changed files and hits the Railway API to redeploy only the affected services.
API Request & Response: I am sending the following mutation:
GraphQL
mutation environmentTriggersDeploy($input: EnvironmentTriggersDeployInput!) {
environmentTriggersDeploy(input: $input)
}
Variables:
JSON
{
"input": {
"projectId": "my-project-id",
"serviceId": "my-service-id",
"environmentId": "my-environment-id"
}
}
Response Received:
JSON
{
"data": {
"environmentTriggersDeploy": true
}
}
The Issue: Even though the response is true, the service does not build or redeploy. I have verified that the IDs are correct and the RAILWAY_TOKEN has the necessary permissions.
GitHub Action Snippet:
Bash
PAYLOAD=$(jq -nc \
--arg pid "$PROJECT_ID" \
--arg sid "$SERVICE_ID" \
--arg eid "$ENVIRONMENT_ID" \
'{
query: "mutation TriggerDeploy($input: EnvironmentTriggersDeployInput!) { environmentTriggersDeploy(input: $input) }",
variables: { input: { projectId: $pid, serviceId: $sid, environmentId: $eid } }
}')
RESPONSE=$(curl -fsSL -X POST https://backboard.railway.com/graphql/v2 \
-H "Authorization: Bearer $RAILWAY_TOKEN" \
-H "Content-Type: application/json" \
-d "$PAYLOAD")
echo "Railway response: $RESPONSE"1 Replies
Status changed to Open Railway • 9 days ago
3 days ago
I would check two separate cases here, because `environmentTriggersDeploy` returning `true` only confirms that Railway accepted the trigger request. It does not prove that a new deployment was created or that it was not immediately skipped/waiting.
First, if `RAILWAY_TOKEN` is a Project Token, the header should not be:
```bash
Authorization: Bearer $RAILWAY_TOKEN
```
Project tokens use:
```bash
Project-Access-Token: $RAILWAY_TOKEN
```
`Authorization: Bearer ...` is for account/workspace/OAuth tokens.
Second, if your goal is to redeploy the same already-built/latest commit, I would use the redeploy flow instead of `environmentTriggersDeploy`:
1. Query the latest successful deployment for that service/environment.
2. Call `deploymentRedeploy(id: "...")` with that deployment ID.
3. Query `deployments` immediately afterward and inspect the newest status.
Railway documents both flows separately:
- `deploymentRedeploy` = redeploy an existing deployment.
- `environmentTriggersDeploy` = trigger a deployment for a service/environment.
I would add a post-mutation check like this:
```graphql
query deployments($input: DeploymentListInput!, $first: Int) {
deployments(input: $input, first: $first) {
edges {
node {
id
status
createdAt
url
staticUrl
}
}
}
}
```
with:
```json
{
"input": {
"projectId": "...",
"serviceId": "...",
"environmentId": "..."
},
"first": 5
}
```
If a deployment is created but shows `SKIPPED` or `WAITING`, then check watch paths and Wait for CI settings. Railway's GitHub autodeploy troubleshooting specifically calls out skipped deployments, watch paths, and CI gating as cases where a trigger can happen but the deployment does not proceed.