I'm able to access your domains just fine. Try using a different device or an incognito browser.

Thanks for checking — but the domains working right now is expected. They currently point at our OLD service, which we rolled back to after the migration failed. The problem is with the NEW service.

To be specific:

1. We attached api.burgermilitia.co.nz and api.gearboxhospo.co.nz to a new service (service id c341d301, project ample-integrity, id 88ea1f6a) in the same workspace (burgersforlife2026). Both showed certificateStatus VALID and DNS PROPAGATED, but Railway's edge returned 404 "Application not found" indefinitely — over an hour, including after fresh redeploys. The service itself was healthy the whole time (its railway.app domain responded fine).

2. Re-attaching the exact same domains back to the old service (service id cc4571b4, project keen-acceptance) worked within ~60-90 seconds. That's the state you tested — it works because it's the rollback, not because the issue is resolved.

3. Separately, attempting to create a third custom domain returned "Not Authorized" — trace id 3224731620473714293. Is there a per-account or per-service custom domain quota we're hitting?

So the questions remain: why do custom domains never route when attached to the service in ample-integrity, and what does the "Not Authorized" mean? We can't just keep retrying to reproduce it for you — the failed attempts burned through Let's Encrypt's 5-certs-per-week limit on api.burgermilitia.co.nz, so we're frozen on domain changes until the window resets (~26 July). We'd like to understand the cause before attempting the cutover again.

Hobby plan only allows 2 custom domains per service.

Also, did you update the TXT record when adding the domains?

That's very likely it — thank you. Checking our Cloudflare zones now, both domains have _railway-verify TXT records (e.g. _railway-verify.api.burgermilitia.co.nz) that were created when the domains were first set up in May/June and never modified since. When we moved the domains to the new service we only updated the CNAME targets, not those TXT records.

Two questions to confirm before we retry:

1. Is a new railway-verify token generated each time a domain is attached (or per service/project)? I.e. was the stale TXT token the reason the edge kept returning 404 "Application not found" on the new service even though the certificate showed VALID and DNS showed PROPAGATED?

2. We attached the domains via the GraphQL API — querying domains { customDomains { status { dnsRecords } } } for our currently-attached (working) domains only returns the CNAME requirement, no TXT. Does the TXT requirement only appear in the response at attach time / while unverified? Just want to make sure we capture the right value on the next attempt.

And thanks for the Hobby plan clarification on the 2-domains-per-service limit — that explains the "Not Authorized" error.

We'll retry the migration with fresh TXT values once Let's Encrypt's per-hostname weekly cert limit resets for us (~26 July — the failed attempts used up the 5/week budget on one of the domains).

That's very likely it — thank you. Checking our Cloudflare zones now, both domains have _railway-verify TXT records (e.g. _railway-verify.api.burgermilitia.co.nz) that were created when the domains were first set up in May/June and never modified since. When we moved the domains to the new service we only updated the CNAME targets, not those TXT records.