It’s November, and while your inbox is starting to be quieter, the Railway dashboard just got a lot more helpful. This week we're bringing dashboard notifications to Priority Boarding so the important stuff finds you right where you're working — no more tab-hopping to figure out what's happening with your deploys. We also made it possible to include Buckets directly in templates, which means you can ship storage-backed templates that deploy cleanly in one click.

And there's more: we're expanding role-based access control (RBAC) capabilities on Railway, and we'd love your input. 

 to let us know which access controls matter most to you — your feedback will directly shape what we build.

Previously, the only way to get notified about activity on Railway was via email. Now, you'll see a real‑time notifications stream in the dashboard for critical issues and usage alerts.

What you'll see in your notification feed:

Build & deployment failures — failed builds, crashed deployments, and out‑of‑memory errors

PR environment alerts — build and deploy failures in ephemeral environments

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

The notification center organizes everything into tabs — Project, Workspace, and All — so you can quickly filter down to what matters. When you're in a project, you can narrow further to just the current environment or see notifications across all environments.

Default filters cover critical issues (build failures, deploy crashes, PR environments, usage alerts, and high‑severity events). 

Each notification type can be configured

 with four delivery options: Email & In‑App, Email Only, In‑App Only, or None.

You can create project‑specific overrides to fine‑tune notifications for individual projects — perfect for adjusting alerts on your busiest repos without changing global settings.

Notifications arrive in real time and include contextual details like service names and environment info, with smart links that navigate directly to the relevant resource.

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

let us know in this Central Station thread.

shipped Object Storage a couple of weeks back

. One gap: you couldn’t package a Bucket into a template — which meant anyone deploying your template had manual setup work to do.

Now you can add Buckets directly to templates. When someone deploys your template, Railway will:

Wire up credentials as variables to the services that need them

This makes storage‑backed templates truly one‑click. See it in action with this example template: 

 for users on the Hobby or Pro plans (currently not part of the free plan to prevent abuse). In terms of limits, workspaces can store up to 1 TB across all workspace buckets. Buckets are free during the preview period.

To get started, you can right-click in your project canvas and choose the “Bucket” option.

As always, we’d love your input — share feedback or requests on 

Invite members to your workspace and assign them the appropriate role

Not everyone on your team needs full admin access, and Railway gives you the granular control to match permissions with responsibilities.

There’s currently three distinct roles for workspace members: Admin, Member, and Deployer. Each role is designed for specific use cases and comes with carefully scoped permissions.

Admin — Full administration of the workspace and all projects. Admins can modify service settings, delete projects, manage billing, add or remove members, and change member roles. This is the role for team leads, engineering managers, and anyone who needs complete control over the workspace.

Member — Access to all workspace projects with the ability to create and configure services, manage variables, create volumes, and create new projects. Members can do everything needed to build and deploy applications, but they can't delete services, volumes, or projects, and they can't manage workspace members or billing. This is the role for most developers on your team.

Deployer — View projects and trigger deployments through commits to repositories via the GitHub integration. Deployers can't use the CLI to deploy, can't modify variables or service settings, and can't view logs. This role is designed for automated systems, CI/CD pipelines, or team members who need to trigger deployments but shouldn't have access to production data or configuration.

We're actively working on bringing even more granular controls in the future. What would you like to see? Let us know in 

We improved Central Station threads by adding an “OP” label on the thread author, making it easier to identify who started the discussion when multiple people are participating. Previously, this wasn’t obvious in long threads and you had to infer it from context

We improved the project switcher to only show the deleted projects divider when you actually have deleted projects. Previously, the divider would appear even when you had no deleted projects, which added unnecessary visual clutter and made the interface feel a bit messy

We fixed a bug where the deploy template page would infinitely load when you weren't logged in. Instead of showing a helpful prompt, the page would just spin forever, leaving users confused about what was happening. Now, you'll see the login prompt banner right away so you know exactly what to do

We fixed a bug where opening the raw editor for project-level shared variables would crash the frontend. Now you can edit away without issues

https://res.cloudinary.com/railway/image/upload/v1762540076/2025-11-07_qmzz9j.png

Notifications, Buckets in Templates, Better RBAC

Changelog #0263