--- title: "Magic domains, deploy-less horizontal scaling, new docs" date: 2026-02-06 number: 0276 url: https://railway.com/changelog/2025-02-06-magic-domains --- # Magic domains, deploy-less horizontal scaling, new docs [Back](https://x.com/claudeai/status/2019467372609040752)-to-[back](https://x.com/OpenAI/status/2019474152743223477) 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](https://x.com/avstorm/status/2019062739402920033). What a time to be alive. Speaking of AI, we just dropped an [Agents Directory](https://railway.com/agents). 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 [Video: 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](https://station.railway.com/). ## Deploy-less horizontal scaling [Video: Scale horizontally without triggering a new deployment] To scale your service on Railway, you can [deploy replicas](https://docs.railway.com/deployments/scaling#horizontal-scaling-with-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](https://docs.railway.com/deployments/scaling#multi-region-replicas), 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](https://station.railway.com/) if you run into any issues. ## TXT verification for trusted domains [Video: 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](https://docs.railway.com/projects/workspaces#verifying-a-trusted-domain) for more details on setting up trusted domains. ## New Railway documentation [Video: A fresh coat of paint for the Railway docs] The [Railway docs](https://docs.railway.com/) 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](https://github.com/railwayapp/docs) and contributions are welcome. You can also share your feedback in [this Central Station thread](https://station.railway.com/feedback/feedback-railway-docs-a0fdb300), we’d love to hear from you. ## Fixes and improvements - We shipped [Focused PRs](https://docs.railway.com/environments#focused-pr-environments) 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