Railway
← All Updates
CHANGELOG

Changelog #0290

Follow us on X

This week, the Railway iOS app landed in TestFlight! You can spin up services, get notified if anything goes wrong, read logs, view metrics, and deploy fixes, all from your pocket. No more keeping a laptop within arm's reach every weekend. We also shipped railway metrics so CPU, memory, and network land in your terminal, and Postgres point-in-time recovery is live for Priority Boarding with one toggle to start archiving WAL to a bucket.

Let's get into it! 🚄

Railway for iOS in preview

 Railway for iOS is now in preview on TestFlight

The app is built around the same primitives as the web dashboard, so you can operate a project end-to-end without leaving the app.

In the preview, you can:

  • Ask the Railway Agent to spin up a project from any of the 3,000+ templates on the marketplace.
  • Stage and apply changes with the same patch-and-deploy flow as the web dashboard.
  • View per-service metrics.
  • Filter logs at the service level.
  • Receive and respond to notifications at the project and service level.

The app isn't at parity with the web dashboard yet, but it's the foundation for a mobile experience that puts you in full control of your stack from anywhere.

On Android? Don't worry, we haven't forgotten about you. Drop a note on this Central Station thread to let us know you're interested, and we'll keep you posted.

Read the full announcement on the blog, join the TestFlight at railway.com/mobile, and tell us what to ship next on this Central Station thread.

Metrics in the Railway CLI

railway metrics prints a summary of CPU, memory, network, and volume usage for the linked service or database, plus HTTP request volume, status breakdown, and latency percentiles when the service serves traffic, all without opening the dashboard. The default window is the last hour, and --since 6h or --since 7d opens it up to any range.

Pass flags to focus the view:

  • railway metrics --cpu --memory to scope down to specific resource metrics.
  • railway metrics --http --method POST --path /api/users to drill into HTTP traffic for a specific route.
  • railway metrics --all to print a compact table across every service in the project.
  • railway metrics --json to pipe a structured summary into scripts or agents, or --raw --json for the full time series.

The command output was designed in a way so that an agent investigating a hot service or a regression can read metrics on its own and correlate them with logs and recent deploys, instead of asking you to paste a screenshot.

If you operate Railway from a terminal, run railway metrics --watch (or -w) to spin up a live TUI dashboard with the same charts the web dashboard renders: CPU, memory, ingress and egress, volume usage, response time percentiles, and HTTP status breakdowns, all colored to match and refreshed in place.

View CPU, Memory, Network, volume and HTTP metrics form the Railway CLI

You can also view metrics across all services and databases by passing the ``railway metrics --watch --all`

View metrics of all services in your project

Check out the docs and let us know what you think on Central Station.

Postgres PITR for Priority Boarding

 Enable PITR for you Postgres database

New in Priority Boarding: Point-in-time recovery for Postgres

Toggle it on and Railway starts async-archiving WAL to a bucket. From there, you can restore to any point inside the archive window, and every restore lands as a new service, so the source database is never overwritten.

Every PITR action stages a patch, so you control when (and whether) it applies. PITR works on both standalone Postgres and Postgres HA out of the box, no extra setup required.

One thing to keep in mind: turning PITR on for the first time triggers a Postgres redeploy and a brief downtime. PITR is still in beta. Pair it with scheduled volume snapshots if you're enabling it on a production database.

Enable the feature flag, open the Backups tab in your Postgres service, and toggle PITR on. Let us know what you think on Central Station.

Fixes and improvements
  • We shipped railway agent --list to list prior agent runs, and railway agent --thread-id <id> to resume one and continue the session. Previously, every CLI agent invocation started a fresh conversation with no way to pick up a prior thread.
  • We shipped a get-status tool in the Remote MCP server so agents can pull the current state of a Railway deployment in a single call.