Railway Release Notes

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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. Head over to Central Station to let us know which access controls matter most to you — your feedback will directly shape what we build.

Let's dive in! 🚄

Notifications to Priority Boarding

Notifications

New in Priority Boarding: Notifications

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.

Buckets in Templates

Buckets in templates

We 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:

• Provision the bucket automatically
• 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: Public Bucket Image Proxy.

Creating buckets is available in Priority Boarding 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 Central Station.

Better RBAC

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 this Central Station thread.

Fixes and Improvements

• 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

Original source Report a problem

Happy Halloween!

🎃
While everyone else is dressing up in costumes and pretending to be something they're not, we're helping your team members prove they are exactly who they say they are — with enterprise Single Sign-On (SSO). If you've been waiting to bring Railway to your workplace (BTW you can get paid for it) because of SSO requirements, that blocker is now gone. And if you're already using Railway at scale, you now have more control over who can do what in your workspaces.
We're also making Magic Config even smarter with intelligent defaults and Dockerfile selection, and we’re updating your projects’ build environment.
Let's dive in! 🚄

Enterprise SSO

Configure SSO for your workspace
SSO is a hard requirement for larger teams and enterprises. Managing authentication through an external Identity Provider (like Okta, Azure AD, or Google Workspace) streamlines the entire employee lifecycle. When someone joins your company, they get access to everything they need in one go. When they leave, you can revoke access across all systems from a single place.
Railway already supported team workspaces with role-based access control, multi-factor authentication with TOTP, and passkeys. But if your security team requires everyone to authenticate through your corporate IdP, you were out of luck.
Not anymore.
With SSO, you can now connect Railway to any SAML 2.0 compatible identity provider. Bring Okta, Azure AD, Google Workspace, JumpCloud, or any other IdP of your choice. Once configured, your team members authenticate through your IdP before accessing Railway — no separate password to manage, no additional MFA setup.
You can also enforce SSO across your entire workspace. When you enable SSO enforcement, existing team members will be required to re-authenticate using your IdP. This ensures everyone in your workspace is authenticated the same way, meeting your security and compliance requirements.
SSO is available as part of Railway's enterprise offering. To request access, contact our sales team. You can also learn more details about the feature in our docs.

Enterprise page

We've been shipping enterprise features for a while now — SOC 2 Type II, HIPAA compliance, SSO, RBAC — but if you weren't already knee-deep in Railway, you wouldn't know where to find any of it.
So to sum up our collective investment for organizational adoption we built a proper Enterprise page. It's not a new feature, it's just a single place that shows what Railway offers for teams with serious security, compliance, and support requirements. All the certifications, all the enterprise capabilities, all the ways to get in touch with our team in one spot.
If you've been trying to explain to your CTO or security team why Railway can handle production workloads, or you're comparing platforms and need to see what we actually offer beyond the developer experience, this page should make that conversation a lot easier.
Check it out at railway.com/enterprise

More Magic Config to Priority Boarding

Magic Config keeps getting smarter. This week, we're shipping two major improvements that make service configuration even more seamless. It’s currently in Priority Boarding.

Dockerfile Selection

You can now select Dockerfile as your builder directly in your service settings, and if you have multiple Dockerfiles in your project (like Dockerfile, Dockerfile.worker, Dockerfile.api), you can specify exactly which one to use.
Previously, if you wanted to use a specific Dockerfile, you'd have to structure your project in a particular way or rename files to make Railway pick the right one. Now, you have explicit control — just point to the Dockerfile you want, and Railway will use it.

Intelligent Variable Defaults

Magic Config already detected which environment variables your code needs and surfaced them for you to configure. Now, we're taking it a step further: we pre-fill defaults when we can.
Previously, Magic Config would suggest the variables your code needed, but you still had to manually figure out what values to use and type them in yourself. Now, Railway not only tells you what you need — it fills in the values too.
Magic Config detects variables that need specific types of values — like database connection strings, secret keys, or API tokens — it now automatically generates appropriate default values for you.

• If your application needs a secret key, Magic Config will set a value like ${{secret(32, "abcdef0123456789")}} which automatically generates a 32-character hex-based secret.
• If your application needs a DATABASE_URL, it can pre-fill the connection string for your Railway database using reference variables.
  This is another step toward Railway understanding your application's requirements and configuring everything automatically. Connect your repo, and let Magic Config handle the setup.
  Try it out out and share your feedback in Central Station.

Metal Builders

Build times matter. Every second your build takes is a second you're waiting to see your code in production, waiting to test that fix, or waiting to ship that feature. It’s the step that we do before deploying your app.
That’s why we're rolling out a brand new metal-based build environment, powered by our own infrastructure, that should make your builds significantly faster.
Here's how the rollout works:

• Free plan users have been using Metal Builders as the default for the past couple of weeks (surprise! you've been beta testing)
• Hobby plan users are being gradually migrated to Metal Builders automatically
• Pro plan users can opt-in to Metal Builders right now in your service settings
  Metal Builders are available in all Railway regions, so no matter where your services are deployed, you can get the speed boost.
  To enable Metal Builders, head to Service Settings → Build → Enable Metal Builders. If you opt-in and run into any issues, you can easily roll back to the standard builders — we've made it simple to switch back while we continue refining the experience.
  Previously, all builds ran on our standard virtualized build environment. It worked well, but there's a performance ceiling when you're running on virtualized infrastructure. Metal Builders run on bare-metal servers, giving you more consistent performance and faster build times without the overhead of virtualization layers.
  Eventually, Metal Builders will become the default for everyone on Railway. For now, we're taking a measured approach to ensure stability and gather feedback before making them the standard.
  Try them out and let us know what you think in Central Station.

Fixes and Improvements

• We improved template configuration by exposing auto-update settings for services that deploy from Docker images. Template creators can now enable automatic image updates, which will cause services to redeploy when a new image version is published. This feature was already available in service settings for all users — we've now made it accessible for templates as well
• We shipped support for browser local message drafts in Central Station. You can now draft messages without worrying about losing your work if you accidentally navigate away or close your tab.
• We improved template services to support both HTTP and TCP proxies simultaneously. Previously, you had to choose one or the other, which limited flexibility for services that needed both types of connections.
• We shipped support for QuickTime video attachments for Central Station. Previously, if you recorded a video on macOS using the built-in screen recorder, you'd have to convert it to MP4 before uploading it to Railway. Now, you can upload .mov files directly
• We fixed a bug where deleted templates would stick around in the frontend. Previously, users were confused when they tried to deploy templates that no longer existed. Templates now properly disappear once they're deleted.
• We fixed a bug where environment sync would fail when trying to sync over the disabled serverless setting. Previously, this setting wouldn't carry over during environment syncs, causing deployments to behave unexpectedly.
• We fixed a bug where opening service settings for a deploying service from a template would crash the frontend. This was particularly frustrating when trying to configure a service mid-deployment — now the UI stays stable throughout the process.

Original source Report a problem