--- title: "Railway for iOS, CLI metrics, Postgres PITR" date: 2026-05-15 number: 0290 url: https://railway.com/changelog/2026-05-15-railway-for-ios --- # Railway for iOS, CLI metrics, Postgres PITR This week, the Railway iOS app [landed in TestFlight](https://railway.com/mobile)! 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 [Video: 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](https://railway.com/templates). - 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](https://station.railway.com/feedback/railway-mobile-app-for-androi-aca54c32) to let us know you're interested, and we'll keep you posted. Read the full announcement on the [blog](https://blog.railway.com/p/ios-app-testflight), join the TestFlight at [railway.com/mobile](http://railway.com/mobile), and tell us what to ship next on [this Central Station thread](https://station.railway.com/feedback/railway-mobile-app-for-i-os-9b705df1). ## 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. [Video: 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` [Video: View metrics of all services in your project] Check out the [docs](https://docs.railway.com/cli/metrics) and let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## Postgres PITR for Priority Boarding [Video: Enable PITR for you Postgres database] New in Priority Boarding: [Point-in-time recovery for Postgres](https://railway.com/account/feature-flags) 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](https://station.railway.com/new?type=feedback). ## Fixes and improvements - We shipped `railway agent --list` to list prior agent runs, and `railway agent --thread-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](https://mcp.railway.com/) so agents can pull the current state of a Railway deployment in a single call.