Project houseloop-esign (80db2dcf-cd03-4410-bc4a-6d2daad19b92), service esign (9c7f90e1-47ca-4813-a340-0eb657ec881e), env production. Custom domain esign.houseloop.ai (id d28cfd3b-4302-470b-847e-52c907dc4e7f). TWO issues, reproducible: 1) AUTOMATIC CERT ISSUANCE NEVER FIRED. The domain sat in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for 13 days while dnsRecords status read PROPAGATED the whole time (DNS-only CNAME to the exact requiredValue, no CAA, no DNSSEC). crt.sh showed ZERO Certificate Transparency entries — Let's Encrypt never received an order. Calling the explicit customDomainIssueCertificate mutation issued the cert in under 60 seconds, so validation was never the problem — the automatic issuance trigger never ran. 2) EDGE NEVER BINDS NEW CUSTOM-DOMAIN TARGETS (still broken). With cert VALID, syncStatus ACTIVE, targetPort 3000, and DNS matching requiredValue exactly, https://esign.houseloop.ai returns 404 'Application not found' with x-railway-fallback: true. The per-domain CNAME targets THEMSELVES 404: ity8gqx6.up.railway.app and smk47851.up.railway.app both return the fallback, while the service domain esign-production-a875.up.railway.app returns 200 on the SAME edgeId. So the per-domain target hostnames are minted but never bound to the deployment. Ruled out our side: domain deleted+recreated (x2 + a canary esign2.houseloop.ai — wedged identically), targetPort pinned, instant redeploy AND full serviceInstanceDeploy after all changes (SUCCESS, no effect), Cloudflare grey-cloud DNS-only confirmed from multiple resolvers. CONTROL TEST: created esigntest.houseloop.ai on a different, healthy service (houseloop-crm, 4e2d5df6-b22d-41b1-b5fa-40e8107e922d, project 7d393225-f8d8-4187-845c-ee49b8842e91) — its fresh target swxe88mo.up.railway.app ALSO 404s, while that service's long-standing domain crm.houseloop.ai works perfectly. Every custom-domain target minted 2026-07-06 fails to bind; older ones work. Ask: please re-sync/repair the edge bindings for our workspace's custom domains (esign.houseloop.ai is the one we need), and check why automatic cert issuance isn't firing on domain creation. Example fallback request id: 8tuzfyyWSh2vb81pFFmdQQ.

Custom domains never bind at edge (404 Application not found) + cert auto-issuance never fires — houseloop-esign

spradlz

HOBBYOP

a month ago

Project houseloop-esign (80db2dcf-cd03-4410-bc4a-6d2daad19b92), service esign (9c7f90e1-47ca-4813-a340-0eb657ec881e), env production. Custom domain esign.houseloop.ai (id d28cfd3b-4302-470b-847e-52c907dc4e7f). TWO issues, reproducible:

AUTOMATIC CERT ISSUANCE NEVER FIRED. The domain sat in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for 13 days while dnsRecords status read PROPAGATED the whole time (DNS-only CNAME to the exact requiredValue, no CAA, no DNSSEC). crt.sh showed ZERO Certificate Transparency entries — Let's Encrypt never received an order. Calling the explicit customDomainIssueCertificate mutation issued the cert in under 60 seconds, so validation was never the problem — the automatic issuance trigger never ran.
EDGE NEVER BINDS NEW CUSTOM-DOMAIN TARGETS (still broken). With cert VALID, syncStatus ACTIVE, targetPort 3000, and DNS matching requiredValue exactly, https://esign.houseloop.ai returns 404 'Application not found' with x-railway-fallback: true. The per-domain CNAME targets THEMSELVES 404: ity8gqx6.up.railway.app and smk47851.up.railway.app both return the fallback, while the service domain esign-production-a875.up.railway.app returns 200 on the SAME edgeId. So the per-domain target hostnames are minted but never bound to the deployment.

Ruled out our side: domain deleted+recreated (x2 + a canary esign2.houseloop.ai — wedged identically), targetPort pinned, instant redeploy AND full serviceInstanceDeploy after all changes (SUCCESS, no effect), Cloudflare grey-cloud DNS-only confirmed from multiple resolvers. CONTROL TEST: created esigntest.houseloop.ai on a different, healthy service (houseloop-crm, 4e2d5df6-b22d-41b1-b5fa-40e8107e922d, project 7d393225-f8d8-4187-845c-ee49b8842e91) — its fresh target swxe88mo.up.railway.app ALSO 404s, while that service's long-standing domain crm.houseloop.ai works perfectly. Every custom-domain target minted 2026-07-06 fails to bind; older ones work.

Ask: please re-sync/repair the edge bindings for our workspace's custom domains (esign.houseloop.ai is the one we need), and check why automatic cert issuance isn't firing on domain creation. Example fallback request id: 8tuzfyyWSh2vb81pFFmdQQ.

Solved$10 Bounty

Pinned Solution

0x5b62656e5d

MODERATOR

a month ago

You need a TXT record at _railway-verify.esign.houseloop.ai. You can get the content for it from the verificationToken property under status.

4 Replies

Railway

BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 2 months ago

0x5b62656e5d

MODERATOR

a month ago

You need a TXT record at _railway-verify.esign.houseloop.ai. You can get the content for it from the verificationToken property under status.

spradlz

HOBBYOP

a month ago

UPDATE: we've worked around the outage by fronting esign.houseloop.ai with a Cloudflare Worker that relays to the service domain (esign-production-a875.up.railway.app), so the site now returns 200 through the proxy. PLEASE NOTE when triaging: the underlying defect is still live — the per-domain edge targets (ity8gqx6.up.railway.app) still return 404 'Application not found' with x-railway-fallback: true when hit directly, so new custom-domain bindings remain broken on our workspace. We'd still like the edge binding repaired (and the automatic cert-issuance trigger checked) so we can remove the proxy.

spradlz

HOBBYOP

a month ago

Thank you! That was it — the API flow never surfaced that requirement (we drove everything via customDomainCreate + the domains query, and nothing in dnsRecords mentioned the TXT step; certificateStatus just sat in VALIDATING_OWNERSHIP). TXT record railway-verify=828e… is now live at _railway-verify.esign.houseloop.ai (verified propagated via 1.1.1.1). Will report back once the edge binds. Suggestion for the docs/API: expose the TXT requirement in the domains status payload — it would have saved us 13 days.

spradlz

HOBBYOP

a month ago

RESOLVED ✅ — TXT verification was the missing piece. Within ~90s of the record landing, the edge bound the domain; we then removed our Cloudflare Worker workaround and reverted to a plain DNS-only CNAME → ity8gqx6.up.railway.app. esign.houseloop.ai now serves 200 directly from railway-hikari with the LE cert. Root cause for anyone finding this thread: if your domain sits in VALIDATING_OWNERSHIP forever with dnsRecords PROPAGATED and the per-domain target 404s, check status.verificationToken and create the TXT at _railway-verify.. Thanks for the fast answer!

Status changed to Solved spradlz • about 2 months ago

Welcome!