 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

. 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 

 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.

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 

 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 

Scale horizontally without triggering a new deployment

To scale your service on Railway, you can 

. This lets you scale horizontally by distributing the workload across multiple instances of your service. You can also deploy replicas in 

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

It's always been possible to configure trusted domains in your workspace settings (e.g. 

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

 users to auto-join, you'd have to spin up a throwaway service, add a subdomain like 

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

 for more details on setting up trusted domains.

A fresh coat of paint for 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, 

 and contributions are welcome. You can also share your feedback in 

 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

https://res.cloudinary.com/railway/image/upload/v1770422719/2026-02-06_nrh6os.png

Magic domains, deploy-less horizontal scaling, new docs

Changelog #0276