Railway Release Notes

Classical music overture

Noel Fielding:
It’s UI week at Railway. Where all of the Railway engineers work on delightful experiences for their customers.

Cuts to Engineer JR

JR:
“C’mon c’mon c’mon, CI green, CI green, CI green”

Cuts to Designer (now Engineer) Jitachi

Jitachi:
“I shipped a PR!”

Cuts to Changelog title card

We have a great week of ships to make Railway easier to set-up and deploy. We took the feedback from the
domain connect feature
so we took it up another notch where you can
buy and attach domains directly in Railway
. We also heard that finding settings is… well, can be improved, so we are cleaning that up for new and our new friends.

More of you are joining the train with a record number of new passengers so our goal here is to make it even easier for you to ship. Welcome! 🚄

Domains on Railway

We’re just going to copy straight from
JR’s blog post
. Take it away JR.

Railway’s primary objective is to reduce friction. Friction all the way from development through to deploying and sharing your project with the world. Part of that is finding a snazzy domain name. The problem though, is that this process has always been completely outside of Railway and when you finally do find a good domain, bringing it into Railway is a tedious process.

railway.com/domains

We have partnered with a domain registrar to directly bring you domains on Railway. You can now go to
railway.com/domains
and buy the front door to your business on the web, directly on Railway.

For more information:
check out the docs.

Project UI Refresh

Revamped dashboard navigation for the projects page

Less in the way. More room to work.

The navigation has moved to the left.
Jitachi
added a persistent sidebar that stays out of your canvas and lets your infrastructure take up the space it deserves. So now it’s your project, your environment, your services. Front and center.

(Without the IE6 style bars on top.)

Now, at the top you’ll find the activity feed, notifications and the Railway AI Agent Panel.

As always, you can share your feedback on
Central Station
.

AI Agent Panel

AI Agent panel where you can ask about your environment’s status/ resources and troubleshoot issues

The AI Agent Panel is a new panel inside your dashboard where it’s aware of your services, your deployments, your logs. Ask it what's broken. Ask it to ship something new. It knows where it is.

No context switching. No copying error traces into another tab. The thing that knows your stack is the thing you're already talking to.

From
our last Changelog
, we’re moving toward a world where Railway sees the issues that you have and just fixes it just like that. Already we’re seeing thousands of builds get triaged with the AI diagnosis feature (in beta) and this is a new UX pattern that can help our users keep those conversations home.

Over the last three months, we’ve been building internal evals (and not training on your code) to help us make AI actually do the dirty work (read: clicking) on Railway.

Try it out, and
let us know what you think
or if you run into any issues.

Fixes and improvements

• We shipped an improvement to the
  Smart Diagnosis
  loading state. Previously you only saw a loading spinner, now the loading state reflects what the agent is currently doing (e.g. searching build logs, checking environment status, fetching docs, comparing commits, etc.)

• We shipped a round of improvements to our GitHub integration. Repos load faster, refresh automatically, and errors from GitHub are handled more gracefully across the platform. If you've seen a banner asking you to reconnect your GitHub account, that's part of this effort. Performance and resiliency here is an ongoing focus

• We shipped a loading state for deployment logs, giving you clear visual feedback while data is being loaded

• We fixed deployment labels on the metrics graphs. The tooltip that appears when hovering over the vertical dashed lines now displays the correct deployment label

• We fixed environment logs going off the bottom of the screen, and we also fixed an issue where they wouldn’t stream when the scroll position is at the bottom

Original source

Smart Diagnosis to Priority Boarding

Run AI-powered diagnosis on failed deployments and receive suggested fixes

New in Priority Boarding: Smart Diagnosis

Deployments fail. When they do, you're the one sifting through build logs, cross-referencing config, and scrolling through diffs trying to figure out what broke. Most of the time, the answer is in there somewhere. Finding it is the annoying part.

Smart Diagnosis does that for you. Trigger it on a failed deployment, and an AI agent reads through your logs, config, recent code changes, and repo context to figure out what went wrong. It tells you what happened and suggests how to fix it, including config patches you can apply in one click.

From there, you have two options. Copy the fix instructions and hand them to your coding agent of choice, or open a conversation with the canvas agent to dig deeper, ask follow-up questions, and work through the fix interactively.

Diagnose failed deployments by chatting with the canvas agent

Fixes are scoped to config patches for now. Down the line, you can imagine getting a PR with the code fix instead.

Available on paid plans. Let us know what you think on Central Station.

IPv6 support to Priority Boarding

Enable IPv6 for outbound connections on your services

New in Priority Boarding: Outbound IPv6

If you need to connect to external services that only expose IPv6 addresses, your Railway services can now reach them.

Since this changes networking behavior, it's opt-in. Enable it per service in your service settings. This covers outbound connections only, so public inbound connections still use IPv4.

Share your feedback on Central Station.

Revamped Agent Skill

You now get a single installable agent skill to manage everything

We've had agent skills for Railway for a while. They let coding agents like Claude Code, Codex, and Cursor operate your Railway infrastructure through natural language: create projects, deploy services, set variables, troubleshoot failures, all from your editor.

The packaging was the problem. There were 13 separate skills, one for each domain (status, projects, deploy, service, domains, environments, databases, templates, metrics, and more). New users hit a wall of options before they knew what any of them did. For agents, evaluating 13 skill descriptions on every request wasn't efficient either.

Now there's one skill: use-railway. Install it once and it covers everything. The skill matches your intent to the right reference (setup, deploy, configure, operate, or API) and loads only what it needs. Multi-step workflows like "create a project, add a Postgres database, deploy my app, and check if it's healthy" compose into a single response without you invoking each step separately. You can install or update by running the following command:

curl -fsSL http://railway.com/skills.sh | bash

Alternatively, you can also install via skills.sh by running

npx skills add railwayapp/railway-skills

Check out the repo and share your feedback on Central Station.

Fixes and improvements

• We shipped a new railway telemetry <enable | disable | status> command, making it easy to opt in or out of usage telemetry collection. The Railway CLI collects anonymous usage telemetry to help us improve the developer experience. Learn more in the Railway docs
• We improved the project usage page and you can now see a detailed cost breakdown, similar to the workspace page

Original source

DDoS protection

Global DDoS mitigation powered by Fastly

In the past we would recommend customers to bring their own DDoS protection. Over time were a number of factors that made this a untenable proposition. Customers just joining us on this journey would then need to go to an external site, juggle name servers and overall it was an unintuitive experience.

We asked: what if we can improve this for our customers? Well- we did just that.

Everyone on Railway gets DDoS protection by default. We've partnered with Fastly to provide DDoS mitigation and global traffic termination across their 100+ points of presence.

All public traffic to your services now routes through Fastly's network, where malicious traffic gets filtered before it reaches your infrastructure.

There's nothing to configure. No proxy to set up, no plan to upgrade, no feature flag to enable. If your service has a public domain, it's protected.

We're also building CDN caching on top of this partnership. More on that soon. Let us know what you think on Central Station.

Buy domains on Railway to Priority Boarding

Search, purchase, and manage domains without leaving Railway

New in Priority Boarding: Railway Domains

Setting up a domain for your Railway service has always meant a trip to your registrar. Buy the domain there, come back to Railway, add it, copy the DNS records, switch to your DNS provider, paste them, wait for propagation, switch back to verify. It works, but it's a lot of context-switching for something that should take a few seconds.

Not anymore. Railway handles the entire thing. Search for what you want at railway.com/domains or from a service's networking settings. Pick from over 250 TLDs. Not sure what to name your project? Describe what you're building and get AI-powered suggestions.

When you purchase a domain from a service's networking settings, Railway attaches it and configures DNS automatically. No records to copy, no propagation to wait for. You can also buy a domain on its own and connect it to a service later.

Privacy and renewal are handled out of the box. Every domain comes with WHOIS privacy and auto-renewal turned on. Pricing is at cost, rounded up to the nearest dollar. You get a heads-up before renewals, and if payment fails, Railway retries a few times before letting the domain expire.

Manage everything at railway.com/workspace/domains: expiry dates, attached services, and payment status in one place.

Check out the documentation for the full details.

Better canvas state across environments

Canvas state is now scoped per environment

Canvas state (positions, groups, edge anchors) used to live at the project level, shared across every environment and every team member. One project, one layout.

That works when your project has five services and one environment. It falls apart when it doesn't. A project with production (10 services) and staging (14 services, four of them test-only) would render all 14 positions in both environments. Phantom nodes showed up where services didn't exist. Two people rearranging the canvas at the same time meant one layout wins and the other disappears. Template deployments dropped nodes into positions that only made sense in the source environment.

Canvas state is now per-environment. Create a new environment, and the layout copies over, but the two are independent from that point forward. Rearrange staging without touching production. Organize by dependency chain in one environment and by team ownership in another. If you want to pull a layout from another environment, import it from the canvas settings in the floating left menu.

Fixes and improvements

• We shipped template UI improvements: variable autocompletion when deploying into an existing project, markdown support in variable descriptions, and better handling of optional variables
• We improved the canvas to center services when the right panel is open. Previously, opening a panel shifted your view off-center
• We fixed an issue where missing GitHub installation errors weren't surfaced. If your GitHub org's repos weren't showing up, Railway now tells you why
• We fixed a bug in the domain configuration modal where the TXT host value included the zone, making it easy to accidentally paste a malformed record into your DNS provider
• We shipped the ability to paste a GitHub URL in the command palette's GitHub Repos sublist. Previously, this only worked at the palette root

Original source

Chat with your canvas to Priority Boarding

Tomorrow's Valentine's Day. Our gift to you? You can now chat with your canvas. Ask your Railway environment what's running, debug failing deploys, and stage changes through a new AI agent that understands your infrastructure. We're also shipping Postgres metrics and network flows to GA after battle-testing them in Priority Boarding.

Let's get into it! 🚄

dev.new - Talk to your Railway environments through the new canvas agent

Ask about your environment’s status and resources

New in Priority Boarding: Canvas Chat

Starting now, you can talk to your Railway environments through our new agent. Think of it as a Clippy, but it actually understands your infrastructure.
Here's what it can do:

• Stage changes in your environment.
  Tell the agent what you want to change, and it'll stage the updates for you to review before applying
• Report live environment status.
  Ask what's running, what's healthy, and what needs attention
• Debug failing deploys and builds.
  Instead of digging through logs yourself, ask the agent what went wrong and get a clear answer
• Diagnose application issues.
  The agent checks your metrics and logs to help pinpoint problems, so you spend less time investigating and more time fixing
• Suggest updates to Railway Functions.
  Get recommendations for improving your serverless functions
• Search approved developer resources.
  Ask questions about Railway and get answers backed by our documentation

After enabling the feature flag in your account settings, you can head to dev.new and tell it what you want to build. Already have a project? Click the chat icon in the navbar to open the agent as a side panel.
This is our first step toward making the canvas conversational. Instead of clicking around to find what you need, just ask. We're shipping this to Priority Boarding first so we can iterate on your feedback before it hits GA.
Give it a try and tell us how to make it better on Central Station.

Postgres metrics

View database metrics for your Postgres database

Your Postgres databases now have their own dedicated metrics view in the dashboard. You can see connection breakdowns (active, idle, idle in transaction), cache hit ratios, and table-level stats like row counts, data sizes, and index usage.
The best part is the Query Statistics panel. It surfaces your most expensive queries with call counts, rows returned, and timing percentiles, so you can find the slow ones before your users do. If you're running Postgres on Railway, this gives you several database observability features so you don’t immediately need to reach for external tools.
As always, you can drop your feedback on Central Station.

Network flows

Network flows between services + network flow logs

Your canvas now shows live network traffic between services — also graduating from Priority Boarding this week.
Connections between services appear as animated lines, with thickness proportional to throughput. You can flip between this view and reference variables using the controls in the top left corner of your canvas.
What you're looking at is layer 4 network data, aggregated every 5 seconds. Each flow tells you where traffic is coming from, where it's going, how fast, and whether anything got dropped along the way. For the full picture, check the new Network Flow Logs tab in any service's logs — it has everything: protocol, addresses, volume, latency, and status.
Let us know what you think on Central Station.

Fixes and improvements

• We shipped telemetry in the Railway CLI to help us improve the developer experience. No project source code or environment variable values are collected. You can opt out by setting DO_NOT_TRACK=1 or RAILWAY_NO_TELEMETRY=1. Check out the docs for more details
• We shipped the ability to see the scope level for your API tokens, so you can quickly tell what each token has access to

Original source

Railway raises $100M Series B to unburden the builders.

Back-to-back model drops from two frontier AI labs, on the same day this week. And it wasn't just about the releases. One of them even took shots at the other in a series of ads. What a time to be alive.

Speaking of AI, we just dropped an Agents Directory. It's a single place to find guides for getting all of the popular coding agents to seamlessly work with Railway. You’ll find installation instructions, example prompts, tips and more.

Of course, agents are only as good as where they deploy to. Here's what else we shipped this week to make that even better: One-click DNS setup for Cloudflare users, verify trusted domains via TXT for automatic workspace onboarding, deploy-less horizontal scaling so you can spin up replicas without waiting for a deployment, and the Railway docs got a complete overhaul.

Let's get into it! 🚄

One-click DNS setup on Cloudflare

One-click DNS configuration for Cloudflare-managed domains

Setting up a custom domain on Railway has always required a trip to your DNS provider. You'd add a domain in Railway, copy the CNAME record, switch tabs to your DNS dashboard, paste in the values, wait for propagation, and come back to verify. It works, but it's a lot of context-switching for something that should take five seconds.

If your domain is managed by Cloudflare, that entire process is now a single click. Railway integrates directly with Cloudflare to configure your DNS records automatically. Add your domain, authorize Cloudflare, and Railway handles the rest.

No more copying records and no more switching tabs. Getting a custom domain on your Railway service should now be as fast as everything else on the platform. If you hit any snags, reach out to us on Central Station.

Deploy-less horizontal scaling

Scale horizontally without triggering a new deployment

To scale your service on Railway, you can deploy replicas. This lets you scale horizontally by distributing the workload across multiple instances of your service. You can also deploy replicas in multiple regions to scale globally, getting your services closer to your users.

Previously, spinning up or scaling down replicas required a new deployment. Railway would trigger a full deploy cycle and then start the new instances. For quick scaling decisions, like spinning up extra replicas ahead of a traffic spike, waiting for a deployment was unnecessarily slow.

Not anymore. Scaling replicas now happens without triggering a deployment. Add a replica, and it starts. Remove one, and it's gone. No build step, no deploy wait. You stay focused on shipping while Railway handles the rest.

This applies to both adding replicas within a region and scaling across multiple regions. Whether you're going from 1 to 3 instances or expanding into a new region, the scaling is immediate.

Got feedback? Let us know on Central Station if you run into any issues.

TXT verification for trusted domains

Trusted domain verification via TXT

It's always been possible to configure trusted domains in your workspace settings (e.g. @yourcompany.com). When a new Railway user signs up with a matching email address, they're automatically added to your workspace with the role you've assigned. No manual invites needed.

There was one caveat though. You could only use domains that were attached to a Railway service. So if your company domain wasn't actually deployed on Railway, say you're deploying greenfield projects on completely different domains, but you still want @yourcompany.com users to auto-join, you'd have to spin up a throwaway service, add a subdomain like verify.yourcompany.com, set up the CNAME, verify the trusted domain, then tear the whole thing down. It worked, but it was janky. That changes today. You can now verify domain ownership by setting a TXT record. No temporary services, no cleanup.

Check out the documentation for more details on setting up trusted domains.

New Railway documentation

A fresh coat of paint for the Railway docs

The Railway docs got a major overhaul. They've been around for many years and were in need of some love. To give you an idea of how overdue this was, the old docs were built with CSS-in-JS. Yes, that was a thing. The new docs should be much easier to navigate and the overall experience should feel a lot more polished. If you find something that can be improved, the docs are open-source and contributions are welcome. You can also share your feedback in this Central Station thread, we’d love to hear from you.

Fixes and improvements

• We shipped Focused PRs as the default for all new projects. Railway will now only create PR environments for PRs that affect the services in your project
• We shipped support for verifying domains with both CNAME and TXT DNS records, giving you stronger proof of domain ownership and better protection against subdomain takeover
• We fixed a bug that prevented users from removing their registry credentials
• We shipped the ability to configure templates with cron schedules
• We fixed a bug where regions weren't displayed for legacy buckets, and fixed a related issue where, in rare cases, you couldn't delete a legacy bucket

Original source

What’s New

In case you missed it, an open-source personal AI assistant went viral this week. It runs on your own machine and you can connect it to WhatsApp, Telegram, Discord, or whatever chat app you already use. The project crossed 100k+ stars on GitHub, went through two name changes, and sparked a wave of community excitement.

Of course, giving AI full access to your machine is not the greatest idea, so several folks have already created Railway templates to make it possible to run it remotely instead. We also put together a quick video showing how to deploy your own and configure it (we went with this template). Give it a try. It's pretty fun.

Now for the stuff we built. It's a big one this week. Priority Boarding gets Postgres metrics and network flow visualization (pretty orbs and purple pipes on your canvas). Login with Railway brings proper OAuth to the platform. Volumes can resize without restarts. And templates can now pull from private Docker registries.

Let's get into it! 🚄

Postgres metrics to Priority Boarding

View database metrics for your Postgres database

New in Priority Boarding: Postgres database metrics.

You can now view detailed metrics for your Postgres databases directly in the Railway dashboard. See connection counts (active, idle, idle in transaction), cache hit ratios, query statistics with timing breakdowns, and table-level information including row counts, data sizes, and index usage.

The Query Statistics panel surfaces your most expensive queries with call counts, rows returned, and timing percentiles. The Tables view shows you exactly where your data lives and how it's being accessed. If you're running Postgres on Railway, this gives you the observability you need without reaching for external monitoring tools. Let us know what you think on Central Station.

Network flows to Priority Boarding

View network flows and their logs

New in Priority Boarding: Network flow visualization.

Your canvas now shows live network traffic between services. Animated flows visualize the actual packets moving through your infrastructure, with the thickness indicating throughput.

Toggle between network flows and reference variables using the canvas controls in the top left.

Under the hood, this is layer 4 network observability. Each flow is aggregated by source IP, source port, destination IP, and destination port every 5 seconds. You can inspect latency, see which peers are connected, and find out why packets were dropped.

Head to a service's logs and you'll find a new Network Flow Logs tab where you can dig into the raw data: protocol, source and destination addresses, connected peers, traffic volume, latency, and status.

Drop your feedback on Central Station.

Login with Railway

Platforms can now authenticate users with their Railway account

We want to make it easier to extend Railway, both for developers building tools and for platforms building integrations.

Until now, platforms integrating with Railway had to ask users to manually provide an API key. That meant users had to navigate to their account settings, create a token with the right scope, copy it, paste it into the integrating platform, and hope they didn't mess up the permissions. If the token got invalidated? Back to step one.

Login with Railway changes this. It's a proper OAuth 2.0 implementation with OpenID Connect. Users click a button, approve the permissions they want to grant, and they're done. The platform gets secure, scoped access without ever touching raw API keys.

Here's what the flow looks like:

• Create an OAuth app in your workspace settings under Developer → New OAuth App
• Redirect users to the authorization endpoint
• Exchange the authorization code for tokens
• Use the access token to make API requests on behalf of the user

The system supports both web apps (confidential clients with client secrets) and native apps (public clients using PKCE). Refresh tokens are available for long-lived access, and users can select exactly which workspaces or projects to share.

For developers already building Railway integrations, this is the path forward. For users, it means fewer API keys floating around and more granular control over what third-party tools can access.

Check out the OAuth quickstart, and share your feedback on Central Station.

Resize volumes without restarting your service

Resize volumes without restarting your service

This feature is in beta

Previously, resizing a volume meant restarting your service. For most workloads that's fine, but for long-running processes or services where uptime matters, it was a pain point.

Live Volume Resizing attempts to resize your volume without any restart. If the live resize fails (which can happen depending on the underlying filesystem state), a restart will be required as a fallback. Either way, you're in control.

To try it out, head to your volume settings and look for the Live resize option. You'll be asked to type a confirmation phrase before proceeding. This is a one-way operation, after all.

Let us know how it goes on Central Station.

Templates can deploy from private Docker images

Templates can now deploy services from private Docker images

Template authors, this one's for you. You can now include private Docker images in your Railway templates by securely sharing registry credentials.

When someone deploys your template, the services built from private images will work seamlessly. The user never sees or accesses the underlying credentials. For added security, SSH access is blocked for these services, keeping your credentials and container internals protected.

This opens up new possibilities for distributing proprietary software, internal tools, or commercial applications while benefiting from Railway's template kickback program.

Fixes and improvements

• We shipped an improvement for deployment messages with railway up. You can now pass --message "text" or -m "text" to set a deployment message that shows up in the UI the same way a commit message would
• We improved the Service Settings page with a new "Scale" section that brings together regions, replicas, and replica limits all in one place

Original source

We Raised a $100M Series B

Railway closed $100 million in Series B funding
Over 2 million developers have shipped on Railway. Tens of thousands of companies, from weekend projects to enterprises, run production with us. Thank you for being part of this journey.
So what are we building? We want infrastructure to disappear. You should only have to think about making something great, or closing your laptop and going outside.
We call it an Intelligent Cloud, and if you've tried the Railway Agent Skill or the latest CLI updates we shipped earlier this month, you've already felt pieces of it: your coding agent deploying to Railway without you leaving your editor, pulling logs/metrics from your running services and working with environments.
We want Railway to feel calm, and if we do our job right, you get more time. Time to build, time to live, time to do things worth doing. And when you come back to the keyboard, you bring all of that with you.
Jake Cooper, Railway's CEO, talked about this on TBPN if you want the full vision. We also made a short video about what shipping peacefully feels like.
Read the full announcement on the Railway blog.

Architecture View

See your project's deployed services at a glance
The projects page now has an architecture view. Think of it as a minimap for your infrastructure, giving you a quick mental model of what's deployed where.

Focused PR Environments

Only what changed in your pull request gets deployed
If you're working with a monorepo or multi-service project, you've probably felt the pain of opening a small PR and watching Railway deploy everything. Changed one file in your frontend? Here comes the backend, the workers and the databases.
Focused PR Environments bring some intelligence to this. Railway now checks which files changed in your PR and matches them against each service's watch paths and root directory. Only the services that actually care about those changes get deployed. If service A changed and service B references it (say, via ${{serviceA.URL}}), service B comes along for the ride. Everything else sits tight.
You get full visibility into what's happening: the canvas shows which services were skipped, and the GitHub PR comment gives you the full breakdown. If you need to spin up a skipped service anyway, you can do it manually with one click.
To try it out:

• Go to Project Settings → Environments
• Make sure PR Environments are enabled
• Toggle Enable Focused PR Environments
  This feature is in beta, so we’d love to know your feedback. Give it a spin and let us know what you think on Central Station.

Fixes and Improvements

• We shipped autocomplete for the raw variable editor, making it easier to reference other services and variables
• We shipped service config editing from the CLI. You can now set source branches, PR environment settings, and more without touching the dashboard. Great for automating PR environments with GitHub Actions. Example:

  -service-config $SERVICE_ID "source.branch" "$BRANCH_NAME". Shout-out Milo123459 to for the PR
  

• We shipped audit log events for workspace member changes. Previously only project member changes were tracked. Now Member.added, Member.invited, and Member.removed fire for workspace members too
• We shipped numeric comparison operators for log filtering. You can now filter HTTP and deploy logs by things like "latency > 500ms" to find slow requests, or "status >= 400" to surface errors
• We fixed the "View in Context" button in logs. Previously, clicking it would cause the log display to flash and fail to scroll to the right place due to a conflict with autoscroll. That's now resolved
• We shipped flattened display for nested JSON in logs. Nested objects and arrays are now expanded and clickable for filtering, instead of showing as raw JSON
• We improved error messaging for invalid domains. Instead of getting a generic "problem processing request" error, we now tell you when the domain is unsupported

Original source

Follow along with updates and improvements made to Railway

Last week we wrapped our planning for Q1 2026, so we're officially back to our regularly scheduled programming. This week: a major security upgrade for Pro workspaces, a structural overhaul of the CLI, Object Storage now available in Singapore, smoother database workflows in the dashboard, and Editable Canvas Arrows graduating to GA. Let's get into it! 🚄

2FA Enforcement

Require 2FA for your entire workspace

Security-conscious teams, this one's for you. Pro workspace admins can now require two-factor authentication for all workspace members.

Once enabled, every member of your workspace must have 2FA turned on before they can access workspace resources. Members without 2FA can still be invited and join via Trusted Domains, but they'll need to enable it before they can do anything else. API tokens remain unaffected and will continue to work as expected.

This gives you peace of mind that everyone with access to your infrastructure has that extra layer of protection. No more hoping your teammates remembered to turn it on.

📖 Read the docs

New CLI Command Structure

The Railway CLI is getting a structural overhaul. Commands now follow an object action subcommand pattern. Instead of verb-first commands, you'll use patterns like railway volume list and railway variable set.

This makes the CLI more consistent and predictable as it grows. If you're scripting with the CLI or building on top of it, the new structure should feel more intuitive. Don't worry about your existing scripts though. The old commands still work, so nothing breaks.

If you have any feedback about the Railway CLI, let us know in this Central Station thread.

Singapore Buckets

Object Storage now available in Singapore

Railway's Object Storage continues its global expansion. Buckets are now available in Singapore, bringing low-latency storage to teams and users in Southeast Asia.

If you're serving content to users in the region, or just want your data closer to your Singapore-based services, spin up a bucket in the Singapore region and you're set.

Database UI Improvements

Schema picker, expandable SQL results, and more. We've been chipping away at the database experience, and this week a few nice improvements landed:

• Schema Picker for Postgres

If your Postgres database has more than one schema, you'll now see a schema picker in the database tab. No more wondering which schema you're looking at. Just select the one you need.

• Expandable Raw SQL Results

Raw SQL query results can now be expanded into a read-only side panel. Wide tables and complex queries now have more room to breathe.

• Update Rows with Generated Fields

Previously, trying to update a row that had generated fields would throw an error. That's fixed. You can now edit these rows directly in the UI without issues.

Editable Canvas Arrows in GA

Take full control of your canvas layout

Last week we introduced Editable Canvas Arrows in Priority Boarding. This week, they're available to everyone.

If you missed it, you can now manually route the arrows between services on your canvas:

• Double-click an arrow to enter edit mode
• Click anywhere on the arrow to add anchor points
• Drag anchor points to shape the path
• Alt/option-click an anchor point to remove it
• Alt/option-click the arrow itself to reset it entirely

We also fixed how arrow endpoints behave when you drag nodes around. Previously, moving a service would shift the start and end points in unpredictable ways, often resulting in weird paths. Positions are now more predictable, and adding or dragging points results in cleaner layouts.

Fixes and Improvements

• We shipped support for automatically creating pull request environments when a PR is opened by Claude Code, so you no longer need to manually approve those deployments
• We shipped usage breakdown for previous months, so you can now see how your usage has trended over time
• We improved GitHub clone errors. They're now surfaced directly to users instead of showing a generic error message
• We improved observability dashboard errors. You'll now see relevant error messages instead of "problem processing request."
• We fixed the raw variable editor to properly escape quoted variables, including JSON values and private keys
• We also fixed parsing of variable references that have periods in their namespace. This also introduces auto-escaping for namespaces with special characters
• We fixed pagination for HTTP logs. Previously you could only view the most recent 1,500 lines
• We shipped an improvement to the Template Marketplace where the search box now auto-opens when you arrive via a URL with a query parameter. Here’s an example where we search for pocketbase
• We shipped a fix to text selection in railway dev TUI mode. If you've been struggling to copy output from your local dev sessions, that friction is gone

Original source

Follow along with updates and improvements made to Railway

The new year's off to a strong start. This was our planning week, but we couldn't help ourselves and a lot still shipped. Thank you to everyone who dropped ideas in our what should we ship in 2026 thread. The suggestions keep rolling in, and we're reading every single one. If you haven't shared yet, it's not too late.

This week: we're shipping a Railway Agent Skill so your coding agents can deploy to Railway without leaving your editor, the CLI picks up over a dozen new features and flags, and the dashboard gets a handful of quality-of-life improvements. We're also putting out a call to help us make the Railway docs truly world-class.

Let's get into it! 🚄

Railway Agent Skill & Claude Plugin

Making Railway coding-agent-friendly has been a priority for us. We've already shipped the Railway MCP Server, which works well — but now we're adding something new: Agent Skills.

Agent Skills are a simple, open format for giving agents new capabilities. They're folders of instructions, scripts, and resources that agents can discover and use to work more accurately and efficiently. Unlike MCP, there's no server to run — local or remote — and they consume less of the LLM's context window. Think of them as the next evolution in agent tooling.

We've built the Railway Skill so your coding agent can:

• Spin up projects
• Manage services
• Pull metrics
• Manage environments and variables
• …and a lot more

If you’re using Claude Code, you can install the Railway plugin. Make sure you’re on the latest version (you can run claude update) and run the following commands:

claude plugin marketplace add railwayapp/railway-claude-plugin
claude plugin install railway@railway-claude-plugin

The good news is that the Railway skill is not exclusive to Claude Code. Every major coding agent (e.g. Cursor, Codex, OpenCode, etc.) supports the Agent Skills spec. So all you need to do is clone or copy the skill directory into your project, and you're set.

The Railway Agent Skill is still early — expect some rough edges. We're actively improving the Skill and want to hear what's working and what's not. Let us know in this Central Station thread.

CLI Updates

The Railway CLI keeps getting better

Under the hood, the Railway Skill uses the Railway CLI and API to do its work. So naturally, we've been leveling up the CLI to match. The philosophy is simple: anything you can do in the dashboard should be doable from the terminal. Here's what shipped over the past couple of releases this week:

New commands:

• railway restart — Restart deployments without triggering a full redeploy
• railway delete — Delete projects directly from the CLI
• railway upgrade — Update the CLI to the latest version (now with Bun support)

New flags:

• --json for railway link — Machine-readable output, perfect for CI pipelines
• --json for railway volume list — Get volume info in JSON format
• --print for railway open — Print the URL instead of opening it in a browser
• --project for railway run and railway up — Run commands against a specific project without linking
• --since and --until for railway logs — Filter logs by time range
• --latest for railway logs — Jump straight to the most recent deployment's logs
• -set-from-stdin for railway variables — Pipe variable values from stdin
• y/--yes for railway unlink — Skip confirmation prompts for scripting
• local alias for railway run — A shorthand that just makes sense

Better error messages:

• Clearer feedback when a deployment can't be redeployed
• Improved SSH error messages for serverless services
• More helpful InvalidRailwayToken error messages

We'd love to hear what's still missing. Drop your CLI feedback in this Central Station thread.

Dashboard Quality of Life Improvements

While agent tooling and CLI work grab the spotlight, the dashboard hasn't been neglected. We've locked in the big projects for this quarter (more on that soon), but in the meantime, here's a batch of polish and fixes that make your day-to-day a little smoother.

Editable Canvas Arrows

Tweak route arrows between services to get the perfect canvas

You know the ritual: drag a service, nudge another, try to get the connection arrows looking clean. Sometimes it works, sometimes it’s just not perfect.

This changes today and you now you can take control. Connection arrows are fully editable:

• Double-click an arrow to enter edit mode
• Drag the start or end points to reposition connections
• Click anywhere on the arrow to add anchor points, then drag them into place
• Alt-click or double-click an anchor point to remove it

Your canvas, your layout. If the feature flag isn't already enabled, head to your feature flag settings and turn on Editable Connection Arrows.

Improved Delete Resource Dialog

See exactly what you're about to delete

When deleting multiple resources at once, you now see all of them listed in the confirmation dialog. Previously, bulk deletes required a bit of faith. Now you can scan the list and make sure you're not about to nuke something important.

Buckets

A couple of small but useful improvements:

• Bucket sizes now display in KB and bytes — not just MB. Previously, a nearly-empty bucket would show "0 MB," leaving you guessing. Now you get the actual size.
• Environment syncing now includes buckets. When you sync environments, buckets will be created or deleted along with everything else. Previously they were left out, which meant manual cleanup. Not anymore.

Friendlier Container Image Errors

Deploying container images can fail for a lot of reasons, and the errors aren't always helpful. We now surface user-friendly messages for the most common issues:

• Missing tag — The tag you specified doesn't exist on the image
• Missing architecture — The image doesn't have a linux/amd64 variant (e.g., arm64v8/nginx won't work on Railway's infrastructure)
• Invalid user — The user specified in your Dockerfile doesn't exist; you'll need to create it before switching to it
• Invalid registry auth — Your registry credentials aren't working

These show up instantly when a container fails to start or an image fails to pull. No more digging through logs for cryptic errors.

Let us know if there’s anything you’d like to see in particular for the dashboard.

Help Us Improve the Railway Docs

Help us make the Railway docs better

All of the above features are only useful if you can find out how to use them. The Railway docs are due for an overhaul, and we want your input before we start.

What's been hard to find? What guides didn't click? What feature did you have to figure out on your own because the docs weren't there?

Whether it's a missing page, a confusing explanation, or just a small nit — we want to hear it. Drop your feedback in this Central Station thread. Everything helps.

Fixes and Improvements

• We fixed an issue where there was UI jank and incorrect patch application when discarding multiple staged changes in rapid succession. The experience is now smooth and reliable.

Original source

New Landing Page

railway.com landing page
If you've ever tried explaining Railway to a friend or colleague, you know it can be tricky. "It's like Heroku, but..." or "It's a cloud platform that..." — none of it quite captures what makes Railway, well, Railway. We wanted the new landing page to do the heavy lifting for you — whether you're sharing it with a skeptical teammate or someone's discovering us for the first time.
If you haven't visited the homepage in a while, go check it out. There might be a few easter eggs hiding in there. And if the new messaging clicks — tell your friends.

railway dev TUI

Terminal UI for the railway dev command
When we shipped railway dev last week, it let you spin up your entire Railway environment locally with a single command. But managing multiple services meant juggling terminal windows — one for your frontend, another for your backend, a third for your worker. Tab back and forth, lose track of which is which, miss important logs.
The new TUI (Terminal User Interface) changes that. Run railway dev and you get a single, unified view of everything running locally:

• Tabbed service logs — Each service gets its own tab. Your frontend, backend, worker, Redis — all in one place. Hit Tab to cycle through them, or press 1-9 to jump directly.
• Service info at a glance — The bottom bar shows you the local URL and the pretty Railway localhost domain for the selected service, plus how many environment variables are loaded.
• Keyboard-driven navigation — Use j/k to scroll through logs, g/G to jump to top or bottom, f to follow new output, and q to quit. No mouse required.
  Previously, you'd either run each service in its own terminal (and lose track of which window was which) or pipe everything into a single stream (and struggle to tell services apart). Now you get the best of both worlds — all your services in one terminal, clearly separated and easy to navigate.
  Try it out and let us know in this Central Station thread.

High Availability Postgres Template

One-click deploy a HA Postgres cluster
The default Postgres experience on Railway is a single node. Simple, easy to spin up, and honestly — it can take you pretty far. But depending on your requirements, a single node might not cut it. Maybe you need read replicas to handle increased load. Or you want to have automatic failover with a hot standby ready to go.
Previously, setting this up meant stitching together multiple services, configuring replication manually, and hoping you got the failover logic right. Not exactly a relaxing Friday afternoon.
So we built a template that handles all of this for you. One click, and you get a Patroni-based high availability PostgreSQL cluster with automatic failover, distributed consensus, and load balancing.
Here's what's inside:

• etcd-1, etcd-2, etcd-3 — A distributed key-value store that handles leader election and keeps the cluster state in sync. If the primary goes down, etcd coordinates which replica gets promoted.
• postgres-1, postgres-2, postgres-3 — Three PostgreSQL instances managed by Patroni. One serves as the primary, two run as streaming replicas. Patroni handles promotion, demotion, and replication configuration automatically.
• haproxy — Your single connection endpoint. It routes writes to the current primary and distributes read queries across replicas. Your application connects to haproxy, and the routing happens transparently.
  We’re using this template as an opportunity for us to collect feedback. The end goal is we want to incorporate a similar experience for Postgres on Railway with a smooth upgrade path.
  This is still early, and we're iterating. Try out the template and let us know how it goes in this Central Station thread.

Template Metrics

View metrics for your published templates
In case you're not familiar: Railway lets you turn any project into a one-click template. Package up a multi-service app, publish it to the marketplace, and anyone can deploy it instantly. And with the Open Source Kickback program, you earn money when users deploy and run your templates.
But until now, you were flying blind. You published a template and... hoped it was doing well? There was no easy way to see deployment counts, usage patterns, or how much you were actually earning from a specific template.
That changes today. Template creators now have access to metrics that show exactly how their templates are performing — deployments, usage, and earnings — all in one place. You'll finally know which templates are resonating with the community and which ones might need some love.

2025 Year in Review

What a year it's been. Before we head out for the break, here are the highlights of what we shipped in 2025:

• Railway Metal — Moved 100% of workloads to our own bare-metal infrastructure.(US West, US East, EU West ,Southeast Asia) regions. 50% cheaper egress, 40% cheaper storage, faster performance, and no more per-seat charges on Pro.
• Railway Functions — Write and deploy TypeScript code instantly from the canvas with sub-second deploys. No GitHub repo required. Supports cron jobs, webhooks, and volumes.
• Railpack — Next-generation builder with 38-77% smaller builds, better caching, and granular versioning. Supports Node, Python, Go, Ruby, Rust, Elixir, Deno, PHP/Laravel, and more.
• SSH — SSH into running services via the CLI with single command execution and tmux mode.
• Serverless — Scale to zero when services aren't handling requests. Pay only for active compute time.
• Monitoring & Metrics — Configurable alerts for CPU, RAM, disk, and egress. HTTP metrics with latency percentiles and error rates. Per-replica metrics.
• Log Explorer — 2x faster logs with filtering, natural language time ranges, copy/download, and clickable tokens.
• Passkeys — Passwordless authentication using Face ID, Touch ID, or hardware keys.
• Object Storage (Buckets) — S3-compatible storage that lives alongside your services. Private by default, no egress fees, no per-operation costs.
• Magic Config — AI-powered automatic detection of environment variables, frameworks, Docker Compose files, and project structure.
• railway dev — Spin up your entire Railway environment locally with a single command. New TUI with tabbed service logs and automatic Docker Compose management.
• Enterprise SSO — Connect to any SAML 2.0 identity provider (Okta, Azure AD, Google Workspace) with optional enforcement.
• SOC 2 Type II — Achieved SOC 2 Type II, SOC3, and HIPAA compliance.
• Audit Logs — Full visibility into who did what, when, and where across your workspace.
• Notifications — Real-time dashboard notifications for build failures, deploy crashes, and usage warnings with per-project customization.
• Automatic Image Upgrades — Configure automatic minor and patch updates for databases with customizable maintenance windows.
• Railway MCP Server — Official MCP server for AI coding agents to deploy, manage, and debug Railway projects.
• IPv4 Private Networks — Full IPv4 support for private networking.
• Bounties & Cash Withdrawals — Earn credits and cash for answering community questions and creating templates. Withdraw earnings via Stripe Connect.
• Affiliate Program — Earn 15% commission on referral spend for the first 12 months.
• Free Plan — $1/month in credits after trial for small projects and personal sites.

Thank you for building with Railway in 2025. We're incredibly grateful for this community, and we can't wait to show you what we've got for 2026.
See you next year! 🚄

Fixes and Improvements

• We shipped an automated vulnerability scanner for third-party dependencies where builds will fail if we detect security vulnerabilities in your application’s dependencies
• We shipped an improvement that automatically triggers a re-deployment for all services that were stopped due to subscription pause — whether from an exhausted trial, failed payment, or hard limits being reached. Previously, you'd have to manually redeploy each service after resolving the issue

Original source

Follow along with updates and improvements made to Railway

This week we're shipping features on both ends of the spectrum: one that helps you see everything that's happening across your workspace, and another that brings Railway into your local development workflow.

We’re releasing Audit logs which give you full visibility into who did what, when, and where across your workspace — essential for teams with security and compliance requirements. The Railway CLI also gets a new railway dev command, so you can now spin up your entire Railway environment locally with a single command. No more configuring things twice, no more private network headaches.

We've also cleaned up how Railway interacts with your GitHub PRs (fewer deployment entries cluttering your timeline) and shipped a handful of canvas improvements.

Let's get into it!

Audit Logs

View and filter audit events in your workspace

For teams with security and compliance requirements, visibility into who did what and when is essential. We're shipping audit logs to give you exactly that. Previously, if something changed in your workspace and you needed to trace it back, you were out of luck. Now you have a full paper trail.

Audit logs let you see every significant event that happens in your workspace:

• Which events happened — deployments, configuration changes, member additions
• Which project and environment — see exactly where the action took place
• Which user — know who made the change
• When — full timestamps for every event

You can filter logs by event type, environment, project, and define custom time ranges to find exactly what you're looking for.

Check out the documentation for more details on Audit logs and how you can export them via the Railway API.

Audit logs are part of our continued investment in making Railway enterprise-ready. Combined with SSO, RBAC, and our SOC 2 Type II compliance, Railway now has the security and compliance features that larger organizations need.

Let us know on this Central Station thread what you think of the feature and if there are any other events you’d like us to include.

Better Local Dev

Spin up your entire environment locally

When Railway started, it was always our goal to make the entire development process easier — and that extends to local development. Right now, you can configure a database or template with one click on railway.com, but spinning that up locally is a bit of a pain.

We're introducing a new CLI command to change that: railway dev.

The goal is simple: develop your project locally with the exact same setup that's in your Railway environment. Here's what it does:

• Manages Docker Compose for your image services — Railway creates, starts, and manages a Docker Compose file in the background for all your image services. This includes Postgres and Redis databases, or anything deployed from DockerHub and GHCR.
• Generates certs with pretty local domains — We start a reverse proxy with {service}.{project}.railway.localhost domains for all services configured with a public domain. No more localhost:5432 confusion.
• Automatically rewrites your variables — Variables that reference the public domain, private network, or TCP proxy get updated to point to your locally running services. If your service connects to Postgres over the private network in production, it'll just work locally too.
• Starts your code services — You can specify that your "web" service has a development command like bun run dev and runs on port 8000. When you run railway dev, it automatically starts with variables pointing to the other local services.

How to try it:

• Install the latest version of the Railway CLI
• In a directory linked to a Railway project, run railway dev
• You'll be prompted to optionally configure any code services (command, directory, port) — you can skip this and set it up anytime with railway dev configure
• Everything starts and you'll see URLs to connect to your services

You can also run railway run {cmd} --service {service} anywhere and it will replace the variables to point to local databases too.

Caveats:

• You need Docker installed and running locally
• Buckets and Railway Functions don't work yet
• Windows support is limited

This is early. There will be bugs and likely big changes ahead. We wanted to get this in your hands now because we'd love your feedback. What's working? What's missing? What would make this indispensable?

Try it out and let us know in this Central Station thread.

Canvas Updates

We shipped several improvements that make working with the canvas smoother:

• Add Buckets from dev.new

  You can now add a bucket when initializing your project from dev.new. One less step to get your object storage set up.

• Duplicating Services in Groups

  When you duplicate a service that's inside a group, the new service now stays in that group. Previously, duplicating a service within a group would create the new service outside of it, which was annoying if you were trying to keep things organized.

• Groups in Template Composer

  Templates made up of multiple services will be deployed as a group

  You can now add groups for services, buckets, and even other groups when creating templates in the Template Composer. If you've been using groups to organize your Railway projects, you can now preserve that organization when you turn your project into a template. Templates created from existing projects that contain groups will automatically include them — your users get a well-organized canvas from the start.

If you have feedback or run into any issues, let us know on Central Station.

Cleaner GitHub PRs

Simplified GitHub PR deployments

We've cleaned up how Railway interacts with your GitHub pull requests.

Previously, Railway created separate GitHub deployments for each service in your project. If you had five services, you'd see five deployment entries cluttering up your PR timeline. This also meant a lot of GitHub API calls.

Now, Railway creates a single deployment per commit per PR environment. Your PR timelines are cleaner, and we're making far fewer API calls to GitHub.

⚠️ Breaking change: GitHub deployments are now per-commit and environment-scoped. The serviceId field is gone, and environment names have changed accordingly. If you have workflows that rely on serviceId, you'll need to update them to treat each deployment as representing the whole environment instead.

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

Fixes and Improvements

• We fixed an issue where the branch selector showed an error on the service settings page for public repo deployments

Original source

Smart Canvas

Improved service states showing online status and failure information

Your Railway canvas just got a lot smarter.
We've shipped a batch of improvements that make it crystal clear what's happening with your services at a glance. No more guessing whether your service is actually online, or hunting through logs to figure out why something failed.

• Clearer service states

  • We've overhauled service states so it's immediately obvious whether your service is online and healthy. The visual feedback is more intuitive, giving you confidence that your services are doing what they should be doing.

• Explicit failure information

  • When something goes wrong, you shouldn't have to dig to find out what. Now, when a service experiences any kind of failure, we display exactly what failed right on the canvas. Build failed? You'll see "Build failed." Deploy crashed? It's right there. No more clicking around to piece together what went wrong.

• Smarter cron displays

  • For cron schedules, we now surface the information you actually care about: whether your scheduled job ran successfully. You'll see at a glance if your last run completed as expected, so you can trust your scheduled tasks are doing their job.

• Alert notifications right in the canvas when configured thresholds are exceeded

  • Alert notifications
    • When you configure alerts, you'll now see a notification pop up right in the canvas. Click on it, and you'll be taken directly to the observability dashboard to dive deeper into the metrics. It's a small touch that keeps you in flow while making sure you never miss what matters.

These changes are all about reducing cognitive load. Your canvas should tell you the truth about your system at a glance and now it does.
If you have feedback or run into any issues, let us know on Central Station.

Magic Config IV to Priority Boarding

Select which services and databases to deploy in an existing project

New in Priority Boarding: the next evolution of Magic Config.
Building on top of the previous iteration, Magic Config now gives you more control over what gets deployed in an existing project. After choosing to create a service from a GitHub repo, Railway will scan it and surface a dialog where you can pick and choose exactly which services or databases you want to deploy.
Got a monorepo with multiple services? Select just the ones you need. Want to skip a database for now? Uncheck it.
Previously, Magic Config would detect everything your repo needed, but you didn't have granular control over what to deploy. Now, you can be selective to deploy the frontend first while you figure out the backend config, or spin up just the database to test your connection strings.
Note: The option to deploy everything all at once in an existing project is coming soon — for now, you'll select what you want and hit deploy.
This is another step toward Railway truly understanding your code and getting out of your way. We scan your repo, show you what we found, and let you decide what happens next.
Try it out in Priority Boarding and share your thoughts on Central Station.

Fixes and Improvements

• We fixed an issue where buckets in groups would jump out of the group after a short time. Buckets now stay put where you placed them
• We improved the experience of configuring a cron schedule by adding a dropdown to the with common presets — hourly, daily, weekly, monthly, and more. You can still set a custom cron expression if you need something specific, but now the most common schedules are just a click away

Original source

Buckets

Buckets are now available on all plans

After weeks of battle-testing in Priority Boarding, Object Storage is ready for prime time. Buckets are now generally available — S3-compatible storage that lives right alongside your services on Railway.

No more juggling credentials from external storage providers, just cmd+k in your project canvas, Choose “+ New service” and then select Bucket, choose a region and you're ready to store files.

Here's what you need to know about pricing:

Free Plan

Buckets are available on the Free plan with sensible limits to get you started. You get 50GB while on the 30 day free trial, after that you you can store up to 10 GB. Perfect for side projects, prototypes, and learning the ropes.

Pricing structure

• No egress fees — Download as much as you need without worrying about surprise charges
• No per-operation costs — We don't nickel-and-dime you for every PUT, GET, or LIST request
• Pay for storage — Simple, predictable pricing based on what you store. $0.015 per GB-month

Account limits

• Hobby plan: you can create up to 50 buckets and store up to 1TB across your workspace
• Pro plan: you can create up to 100 buckets, with no limit on the amount of data you can store
• Enterprise: custom limits and pricing

Private by Default

Buckets serve private files only. Your data stays secure, and you control access through your services. If you need public file serving, deploy a public proxy service to handle that layer — giving you full control over caching, access patterns, and CDN configuration.

Buckets in Templates

We shipped Buckets in Templates a few weeks back and Template creators can include storage-backed resources that deploy cleanly in one click. When someone deploys your template, Railway automatically provisions the bucket and wires up credentials to the services that need them.

Ready to hack on Buckets? Check out the documentation, and let us know what you build in Central Station or by tagging us on X.

Magic Config Gets Smarter — Now Powered by AI

Magic Config now detects docker-compose files and suggests project structure

Magic Config continues to evolve. After launching last month, we've been shipping improvements that make service configuration even more seamless. Here's what's new in Priority Boarding.

Docker-Compose Detection

Connect a repo with a docker-compose.yml file, and Railway will now use it to scaffold your entire project. Under the hood, we're now using AI to make this even smarter:

• Project Name Suggestion — Analyzes your README, package.json, and other config files to suggest a meaningful project name
• Domain Setup Agent — Determines if a service should be publicly accessible and adds a domain if needed
• Service Connections — Sets up reference variables between services (e.g., connecting your backend to a database URL)

We'll also:

• Build & deploy the necessary services and databases automatically
• Pull variables from your code and give them initial values or set generator functions

This is another step toward Railway understanding your application and configuring everything automatically. Connect your repo, and let Magic Config handle the setup.

Try it out in Priority Boarding and share your feedback in Central Station.

Restricted Environments

New for Enterprise:

For teams with strict security requirements, not everyone should have access to production. Restricted Environments let you lock down sensitive environments so that non-admin members can see they exist but cannot access their resources — variables, logs, metrics, services, or configurations.

The key detail: Workspace members who have the “Member” and “Deployer” can still trigger deployments via git push. This means your CI/CD pipelines keep working, but engineers without admin access can't peek at production secrets or logs.

This builds on the Role-Based Access Control (RBAC) Railway gives you:

• Admin — Full administration of the workspace and all projects
• Member — Access to all workspace projects with the ability to create and configure services, but can't delete or manage workspace settings
• Deployer — View projects and trigger deployments through GitHub, but can't access logs, variables, or configuration

Restricted Environments add another layer of control for your most sensitive workloads.

To enable Restricted Environments for your Enterprise workspace, contact us. Once enabled, go to Project Settings → Environments and toggle the Restricted switch for any environment you want to lock down.

We're actively working on even more granular controls. What would you like to see? Let us know in this Central Station thread.

Template Kickback Program Updates

Templates now have dedicated support sections on Central Station

If you're not familiar, the Template Kickback program lets you earn money when users deploy your templates. You get 25% of what Railway makes from template deployments — no limits, no minimum amount required. Cash withdrawals are available in $100–$10,000 increments via Stripe Connect.

Here's the thing: templates require maintenance. Minor patches, security updates, and sometimes major upgrades that require template updates. Great templates need ongoing care, and we want to incentivize that.

To do that, we're restructuring how the 25% cut is distributed:

• 15% from template usage (when users deploy and run your template)
• 10% for answering questions about your template

This brings balance to the template ecosystem. Users can deploy templates with confidence knowing the creator is incentivized to provide support, and creators are rewarded for maintaining and supporting their work — not just for the initial publish.

Central Station now has a dedicated section for templates. A queue of questions users have asked about your templates will be displayed, and you can earn that additional 10% by helping them out.

Railway partners also now get dedicated pages where you can view all Railway templates that’s using their project.

View all templates that are using a Railway Partner’s technology

Here are a couple that just launched:

• Prisma
• Drizzle
• Directus

Better CLI Service Commands

The Railway CLI now has dedicated service subcommands

The Railway CLI just got a quality-of-life upgrade with new subcommands for the railway service command:

• railway service link [service] Link a service to your current project. railway service still works and redirects to link.
• railway service status - Check deployment status for your services with color-coded output:
  Status output includes service name, deployment ID, and color-coded status:
  • 🟢 Green for SUCCESS
  • 🔴 Red for FAILED or CRASHED
  • 🟡 Yellow for STOPPED or SLEEPING
  • 🔵 Blue for in-progress states like BUILDING or DEPLOYING

This makes it easier to script deployment checks in CI/CD pipelines or quickly see what's running across your environment.

Thank you @anonrose for the contribution!

Fixes and Improvements

• We improved cron job timing accuracy. Previously, scheduled jobs could occasionally run late. Now, cron executions are punctual and consistent.

Original source

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.
Let’s go! 🚄

Notifications

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:
• Email & In‑App
• Email Only
• In‑App Only
• None
  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.
  Create custom notification rules
  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.

New Home for Conductor Questions

Conductors now get a dedicated queue of questions to help more users, faster - station.railway.com
If you’ve ever asked a question in Discord or on Central Station, there’s a good chance you’ve already met a Railway Conductor. They’re Railway experts who keep things friendly, helpful, and unblocked. The Conductor Program 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
The new queue helps:

• 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 template bounties, recommendation letters, moderation status in Discord and Central Station, a shared team workspace, a private channel with the Railway team, and of course, Railway swag.
  If you love helping others and want to get more involved, you can apply to become a Conductor.

Fixes and Improvements

• 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.

Original source

Between year-end shipping sprints and Black Friday load tests, it’s peak alert fatigue season. This week we’re shipping better webhooks so you only get pinged when it matters, smarter service settings that catch misconfigurations before they bite you, and open office hours with the Railway team for folks running larger workloads.
Whether you’re tuning alerts, hardening production, or evaluating Railway for your infra, this one’s for you.
Now let’s get into what shipped this week 🚄

Better Webhooks

Configuring webhook alerts for critical service events
Webhooks on Railway just got a lot more powerful. You can now subscribe to a richer set of events, including CPU and memory threshold alerts, so your external tooling can react to performance issues in real time instead of waiting for a human to notice graphs spiking.
We also revamped the UI to make it easier to pick the events that matter. In a single click, you can subscribe to a curated set of critical events such as VolumeAlert Triggered, Monitor Triggered, Deployment Crashed, and Deployment OOM Killed, instead of hunting through a long checklist. This makes it straightforward to wire up “only wake me up when things are really broken” alert policies.
Finally, you can choose whether or not to receive webhooks from PR environments. They’re disabled by default, so your staging and preview workflows don’t accidentally spam your alert channels, but you can enable them when you want full parity between preview and production.
As always, we’d love to hear how you’re using the new webhooks and what events you’d like to see next over on Central Station.

Better Service Settings

The Service Settings panel picked up a whole wave of quality-of-life improvements this week, aimed at catching configuration issues before they reach your build or deploy.
First up: cron schedules. Railway cron jobs let you run short-lived tasks on a schedule by starting your service according to a crontab expression, running your task, then exiting once you’re done (for example, a daily backup or periodic job). We now validate cron schedules directly in the UI, so invalid expressions (including certain special characters, expressions, and hashes that caused build failures) are caught before they ever hit your pipeline.

Cron schedule validation

We also tightened up how Docker images are handled in Service Settings. Docker image names are required to be lowercase, but previously we didn’t enforce that, which led to confusing failed deploys. From now on, Railway will transparently lowercase image names while preserving the case of image tags and hashes, since those are case-sensitive. This reduces a whole class of subtle “why did my image deploy fail?” errors.

Docker image names is uses the correct casing

Domains and ports also received a big usability pass. The Generate Domain button is now disabled until you enter a valid port, with dynamic validation feedback so it’s clear what’s wrong and how to fix it. These improvements extend across the lifecycle of managing domains—adding domains, editing existing domains, and as a little bonus, the same validation behavior is applied to the TCP Proxy. The goal: fewer “what state is this actually in?” moments when wiring up network access.

Port and domain validation

On top of that, we shipped several smaller polish changes that should make daily usage smoother:

• Copy DNS record name easily: We added a copy button to the name field in the DNS records modal, so you can grab hostnames without carefully selecting text by hand.
• Template composer state behaves correctly between templates: Previously, when switching templates (for example: Edit a template → Create a new template, or Edit template A → Edit template B), the canvas configuration from the previously opened template could leak into the new one. We now clear the state when templateId changes, so every template opens with the correct canvas configuration.
• Safer diffs for project shared variables: When using the project shared variables raw editor, we now pass the existing decrypted variables into the editor, so the diff correctly represents what’s actually stored. This prevents sealed variables from being inadvertently overwritten with empty strings when applying changes.
  Shout-out to Brody for implementing all of these changes. If you have any feedback, drop us a line on Central Station.

Open Office Hours with the Railway Team

Sit down with the Railway team to tune your infra
Cloud bills creeping up, deploys slowing down, and every “quick change” turning into a yak shave? For a limited time, we’re opening up Office Hours with the Railway team for companies running larger workloads who want to move faster and spend less.
If your org is spending $5,000/month or more on infrastructure, you can grab time directly with our customer and solutions folks. In a session, we will:

• Map your workload: walk through your current architecture, pain points, and constraints
• Match you with the right setup: show how to get started on Railway, often with one of 1,200+ templates so you are not starting from scratch
• Pressure-test the value: explore where Railway can realistically help you ship 10x faster or cut infra costs by up to 65%, based on what we have already seen with similar teams
• Plan the path forward: if Railway looks like a fit, outline next steps for onboarding, migration, and change management so you do not have to figure it out alone
  If you are the person bringing Railway to your workplace, this is also your chance to benefit personally. When your company adopts Railway because you championed it, you can get paid for bringing Railway to work through our referral program.
  We are keeping this offer tight with limited slots and limited time, so if you have been meaning to rethink your infra, this is a good excuse to get it on the calendar.
• Book office hours with the team: cal.com/team/railway/railway-office-hours
• Read more about Railway at scale: railway.com/enterprise

Fixes and Improvements

• We shipped notifications for important SSO-related events, so workspace admins can quickly understand what changed in their authentication setup. You can now receive notifications when SSO is Connected, Disconnected, or Updated, as well as when a SAML certificate requires renewal and when a SAML certificate is renewed. You can learn more in the SSO events documentation.
• We shipped a new upgrade flow for payment methods that supports 3DS cards and removes the old $1 temporary verification charge. The previous flow could be confusing, especially when customers saw a $1 authorization that later disappeared. This new flow reduces friction when adding or updating cards and makes billing behavior more transparent.

Original source