Skip to main content
Connect your Railway account in the Squasher dashboard so Squasher can inspect Railway deployments, read runtime logs, configure a Railway webhook, and restart or redeploy services for the bound Railway project.
Railway’s OAuth and GraphQL surfaces are still evolving. If Railway changes consent copy, project selection, or log labels, use Railway’s latest UI wording and keep the Squasher callback URL exactly as configured.

​
Connect Railway to Squasher

1

Open Integrations in Squasher

In the dashboard, open your project, go to Integrations, and choose Railway.
2

Connect Railway

Click Connect Railway and finish the Railway consent flow. Squasher requests the Railway project access it needs to inspect deployments and logs on your behalf.
3

Bind the correct Railway project

After the OAuth flow finishes, choose the Railway project that matches your Squasher project and save the binding.
4

Verify telemetry

Select a service and environment, then run the opt-in verification. Squasher reads a small log and metric window before continuous collection starts.
5

Use Railway inside Squasher

Once bound, Squasher can answer questions about recent Railway deployments, inspect Railway runtime logs, restart or redeploy Railway services, and ingest Railway deployment failure webhooks for alerting and automation. If the Railway project has multiple services or environments, Squasher will ask which one you want.

​
What the Railway connection is for

  • Deployment status and recent deploy history for the bound Railway project.
  • Continuous runtime logs and metrics for the selected Railway service and environment.
  • Deployment webhooks from the bound Railway project, stored as first-class deployment records and matched to telemetry when service/version metadata is present.
  • Restarting the latest active deployment.
  • Redeploying the latest Railway deployment.

​
Railway runtime logs

Railway does not expose a native stdout log drain. After OAuth project binding, Squasher reads logs and metrics through Railway’s API and advances its cursor only after Squasher accepts the batch. Collection obeys Railway rate-limit and retry responses. The optional Railway webhook remains useful for immediate deployment failure events. Railway OAuth must be enabled for the Squasher application. Squasher requests project member access and offline access so collection can continue after the browser session ends. The Railway plan sets the API rate limit, so large projects can need a narrower service or environment scope. See Railway’s OAuth guide and Public API limits.

​
Detection behavior for forwarded logs

Squasher creates error groups from severity fields and message patterns commonly used for crashes, exceptions, and fatal failures.

​
Agent handoff

Use this prompt for safe Railway operations:
Use squasher providers railway-*, squasher integrations connect railway, or MCP search("providerCapabilities.railway") followed by execute.
  • Use Node.js SDK for richer in-app context inside the service itself.
  • Use alerts so production failures notify your team.
  • Use OpenTelemetry if you want application traces and logs in addition to Railway platform data.