Railway
← All Updates
CHANGELOG

Changelog #0300

Follow us on X

They say it's always DNS. This week it actually is: DNS logs land in the dashboard, so you can watch every lookup your services make. The CLI also picks up railway api, an escape hatch for running any Railway API operation from your terminal. And one more thing: this is our 300th changelog! Three hundred Fridays of ships, fixes, and the occasional bad pun. Thanks for reading along, whether this is your first edition or you've been here since number one. Here's to the next 300 🥂

Let's get into it! 🚄

DNS logs

 Network logs > DNS

Every deployment's Network tab now includes DNS logs. Open a deployment, click Network, and switch to DNS to see every lookup your service makes: the name queried, the record type, the response code, and whether the query targeted the private network or the public internet.

The filter bar understands DNS attributes. Narrow to failures with @status:failed, catch misspelled hostnames with @rcode:NXDOMAIN, isolate private networking with @zone:internal, or follow a single dependency with @domain:example.com, subdomains included.

Until now, DNS failures were invisible on Railway. Whether the cause was a missing record, a flaky upstream resolver, or a mistyped .internal hostname, your app reported the same generic connection error and left you guessing. The logs show each lookup and its response code, so you know right away whether the domain doesn't exist or the resolver timed out.

Logging is on by default for every service, with nothing to configure. The Network tab also brings HTTP logs, DNS queries, and network flow logs together in one place. HTTP and Network Flow previously lived in separate tabs, and DNS queries weren't visible anywhere.

Try it on your services, and let us know what you think on Central Station.

Query the Railway API from the CLI

 Query the Railway API from your terminal

The CLI picks up an escape hatch. The railway api command lets you explore Railway's public GraphQL schema and execute authenticated operations without leaving the terminal:

  • railway api search <term> searches the live schema, ranking executable operations first, so search deployment surfaces the deployment query and mutations before loosely related types.

  • railway api describe <name> inspects a field or type, including its arguments, return type, and union members.

  • railway api schema prints the full schema.

  • railway api 'query { me { id name } }' executes an operation with your CLI credentials. Pass documents inline, over stdin, or with --file, and supply variables with --variables or --var.

Discovery is backed by live introspection of the API, so results reflect what Railway supports right now rather than whatever shipped with your CLI version.

The dashboard and the CLI cover the common paths, but the public API has always been able to do more than either. Reaching it meant hand-writing GraphQL against the endpoint with an auth header and the docs open in another tab. The workflow is discovery-first now: search for a capability, describe it, and run it. That suits quick one-offs, scripts, and agents that need an operation before it has a first-class CLI command.

Update with railway upgrade, run railway api --help, and let us know what you think on Central Station.

Fixes and improvements

  • We shipped a --tunnel-only flag for railway connect. It opens the tunnel without dropping you into a database shell, so you can point an external GUI client at your database. Previously the command always launched the bundled client.

  • We fixed the workspace command palette suggesting services from deleted projects.