Domain Stuck in "Creating Domain" State — DNS Correct, TXT Record in Place
axiomstate
PROOP

2 months ago

Issue: My custom domain liftkit.axiomstate.com has been stuck in "Creating domain" state for over an hour. DNS is resolving correctly and the TXT record is in place, but the domain won't complete provisioning.

Service Details:

  • Service: handsome-emotion
  • Domain: liftkit.axiomstate.com
  • Port: 3000

DNS Status (verified):

  • CNAME: liftkit.axiomstate.comdmico9io.up.railway.app ✓ (resolves to 66.33.22.1)
  • TXT Record: _railway-verify.liftkit = railway-verify=a9b1d37cd69841765be75975f28dfe3ae7e36e48f8c894c1f2d9451b98f3e385 ✓ (set to "DNS only")

Troubleshooting Done:

  • ✓ Verified DNS records with nslookup and dig
  • ✓ Confirmed TXT record exists in Cloudflare and is "DNS only"
  • ✓ Refreshed Railway dashboard multiple times
  • ✓ Waited 60+ minutes for propagation
$10 Bounty

2 Replies

Status changed to Awaiting Railway Response Railway 2 months ago


axiomstate
PROOP

2 months ago

Update: Root Cause Found — Cloudflare for SaaS Provisioning Lock (Ghost Record)

For anyone else running into this, the issue is not standard DNS propagation. It is a wedged provisioning state between Railway and Cloudflare's edge network.

The Root Cause: Railway uses Cloudflare for SaaS (Enterprise) to route custom domains. When you add a domain to Railway, it creates a custom hostname in their Cloudflare account. If the SSL provisioning gets interrupted (in my case, toggling Cloudflare's Universal SSL during the setup of a second subdomain, or using the one-click Domain Connect), the Railway provisioning state gets stuck.

Because Railway's Enterprise zone has priority routing over personal Cloudflare accounts, this creates a "ghost record" lock at the edge:

  • Your personal Cloudflare dashboard shows the CNAME is perfectly fine.
  • But Cloudflare's authoritative nameservers (burt / adaline) will return NXDOMAIN because the SaaS edge route is stuck in a failed state.

Why normal troubleshooting doesn't work:

  1. Deleting from Railway UI/API: Even if the Railway API returns customDomainDelete: true, it appears Railway doesn't always fire the downstream API call to Cloudflare to release the hostage hostname from their Enterprise zone.
  2. Changing DNS Providers: Moving off Cloudflare DNS won't fix it. Even if Route53 resolves the CNAME, the moment the HTTP request hits Railway's Cloudflare Anycast IPs, Cloudflare's edge inspects the SNI header, sees the locked SaaS route, and drops the connection.

The Fix: If your domain is stuck like this, you have three options:

  1. Support: Contact Railway support so they can manually issue the API call to Cloudflare to release the custom_hostname from their Enterprise tenant.
  2. Community Workaround: Use a tool like Liberate the Hostname to force Cloudflare to re-verify and strip the lock via fallback routing.
  3. Fresh Subdomain: Abandon the wedged subdomain completely. Spin up a brand new one (e.g., app.yourdomain.com), configure the DNS Only/Grey Cloud CNAME first, and then add it to Railway manually via their API/Dashboard (avoiding the one-click integration).

Hope this saves someone else the hours of debugging!


airdesk
PRO

8 days ago

Railway uses the cloudflare services and cloudflare is currently down : https://www.cloudflarestatus.com/ so you maybe experiencing these issues. Wait for cloudflare to resolve and later you can check


Welcome!

Sign in to your Railway account to join the conversation.

Loading...