This week is all about staying ahead of issues: Notifications graduate from Priority Boarding to General Availability, giving everyone a real-time view of what’s happening across projects and environments. There’s also a new way for our community Conductors to triage questions faster. We’ve also shipped a couple of quality-of-life fixes, and a bunch of larger features are still in the oven that should be ready next week.

Stay on top of deploy failures, PR environments, and usage alerts with real‑time notifications and fine‑grained rules.

Previously, the only way to hear from Railway was via email. With Notifications now GA, every workspace gets a real‑time notifications feed right in the dashboard so you can see critical issues as they happen, without digging through logs or inbox folders.

Here’s what now shows up in your notification feed:

Build & deployment failures: failed builds, crashed deployments, and out‑of‑memory kills.

PR environment alerts: build and deploy failures in ephemeral environments, so preview branches don’t silently break.

Usage & billing alerts: trial usage warnings, soft and hard limit notifications, and volume storage alerts.

The notification center is organized into Project, Workspace, and All tabs, so you can zoom into a single project or scan everything at once. When you’re inside a project, you can further narrow to just the current environment or expand to all environments for that project.

By default, Railway focuses on high‑signal events: build failures, deploy crashes, PR environment issues, usage alerts, and other high‑severity events. Every notification type can be tuned with four delivery options:

For noisy repos or particularly sensitive services, you can now create project‑specific overrides to fine‑tune behavior. Keep global rules conservative, then dial up (or down) alerts for individual projects, perfect for your busiest monorepos or production‑critical services without affecting everything else.

Notifications are delivered in real time with rich context: service names, environments, and smart links that jump you straight to the relevant resource so you can go from alert to fix in a single click.

If you run into any issues or want to share feedback, drop by 

Central Station and let us know how Notifications are working for you

Conductors now get a dedicated queue of questions to help more users, faster - station.railway.com

, there’s a good chance you’ve already met a Railway Conductor. They’re Railway experts who keep things friendly, helpful, and unblocked. The 

 brings together the folks who answer questions, moderate channels and templates, contribute to open source, and keep a direct feedback loop open between the community and the Railway team.

This week, we’re making their lives a bit easier with a dedicated Conductor queue view.

Behind the scenes, Conductors now see a stream of questions that have been handed off to them, prioritized for where they can help most. 

This is especially useful as the volume of questions grows: the Railway Support team continues to focus on platform-specific issues, while Conductors can concentrate on application‑level questions, best practices, and “how would you architect this?” discussions

Route questions to the right people, so fewer threads fall through the cracks.

Reward helpful answers, by giving Conductors better visibility into where they can have the most impact.

Scale community support, as more users join and more projects land on Railway.

Being a Conductor also comes with a set of benefits that make it worth their time: the Railway Hobby plan for free, cash payouts for complex issues and OSS contributions, early access to 

, recommendation letters, moderation status in Discord and Central Station, a shared team workspace, a private channel with the Railway team, and of course, 

If you love helping others and want to get more involved, you can 

We shipped support for automatically creating pull request environments when a PR is opened by GitHub Copilot, so you no longer need to manually approve those deployments.

We fixed an issue where restoring from a volume backup could report the wrong size in the API and UI. Previously, if you had a 5 GB volume, took a backup, resized the volume to 10 GB, and then restored from the backup, the underlying volume would correctly be 5 GB again, but the system still thought it was 10 GB and displayed it that way. Restores now preserve and report the original volume size at the time of backup, keeping the API and UI in sync with reality.

We shipped support for a restart policy setting in the Template generator. The default value is pulled from the primary service instance’s deploy config, and template authors can now set any max‑restart value, regardless of their current plan, so shared and published templates remain plan‑agnostic and behave consistently across different workspaces.

https://res.cloudinary.com/railway/image/upload/v1763762098/2025-11-21_fgsn9z.png

Changelog #0265