Deployment hostnames

Authoritative list of every deployed service, its final hostname, and the state of the two things that have to be true for that hostname to work: a Railway custom domain attached, and a CNAME in the demo.cba.raidiam.io hosted zone.

This tracks standing action SA-1 in CLAUDE.md.

The situation, and why it costs no rework

cba.raidiam.io is not a delegated zone and never was. Only directory.cba.raidiam.io and pki.cba.raidiam.io were ever delegated, both from raidiam.io. So the hostnames originally written into the plan were never creatable.

demo.cba.raidiam.io exists as hosted zone Z019685026P7GRD1QOL71 in AWS account 681588999762, which we control.

The delegation is LIVE as of 2026-08-10. All four name servers answer and the SOA comes back from our zone. PR tf-raidiam-aws-organisation#1522 records it as code and is still open; the records themselves were added ahead of the merge.

Building against the final hostnames from the start cost no rework, exactly as intended. Entity IDs are identifiers rather than addresses, so registering https://netbank.demo.cba.raidiam.io in the directory before it resolved was harmless, and nothing has to be re-registered now that it does.

Current state, verified 2026-08-10

Eight services are deployed and every deployment reports SUCCESS. Every hostname resolves and Railway reports DNS_RECORD_STATUS_PROPAGATED with the observed CNAME matching the required value. Certificates are at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP, which is the expected state shortly after a zone is first delegated: Railway has seen the records and is issuing. Until issuance completes, HTTPS returns no response. That is the only thing outstanding.

Two services crashed on their first deploy and both were configuration rather than code. The bank OP refuses to start without BANK_COOKIE_SECRET when NODE_ENV=production, because it has no hardcoded fallback in production, and the signals subscriber could not find its key file. Both are correct behaviours: a service that silently starts with a development secret in production is the bug. Key material is supplied as base64 env values and materialised at boot by materializeKey.

Name servers for the delegation

ns-1976.awsdns-55.co.uk
ns-614.awsdns-12.net
ns-28.awsdns-03.com
ns-1379.awsdns-44.org

Three failures that all look like "the host does not answer"

Verified on this deployment, 2026-08-10. All three present identically and have different causes, so check them in this order.

1. No ownership TXT record. Railway will not issue a certificate until it has verified domain ownership through a TXT record at _railway-verify.<name>. That record is NOT in the API's dnsRecords array: it lives in verificationDnsHost, verificationToken and a verified flag. Symptom: certificateStatus sits at VALIDATING_OWNERSHIP indefinitely with a NULL error, which reads exactly like slow propagation. Tell: verified is false.

1. Certificate not yet issued. TLS still serves the Railway wildcard, so a client gets CN=*.up.railway.app and the request lands on the edge rather than the service, returning a 404 JSON body. If a consumer is fetching a discovery document, it will faithfully report something like "Response from discovery URI is missing the mandatory issuer key", which reads like a malformed document from a service that is in fact fine. Tell: inspect the SAN on the served certificate rather than trusting the error text.

1. Domain attached to a service that has not rebound. Certificate valid, verified true, DNS correct, deployment SUCCESS, and the process logging its port happily, yet HTTPS returns nothing at all. Fix: railway redeploy --service <name>. Tell: everything looks healthy and the edge still does not route.

The agent's hostname is not a preference

agent-ap-orchestrator.demo.cba.raidiam.io is the redirect uri REGISTERED in the agent's federation entity metadata, and it is repeated in the keystore sector identifier document. The bank refuses an authorization request whose redirect uri is not the registered one, so the deployment moved to the registered host rather than the registration moving to a friendlier host. Changing the registration instead would mean two directory writes and a live session.

agents.demo.cba.raidiam.io stays attached to the same service as a friendly alias for links and slides. AGENT_BASE must remain the registered host, because that is what the agent puts in the authorization request.

Run npx tsx tools/verify-federation-client.ts before recording anything. It checks the configured identity against what the federation actually publishes: that the client id is a URL, that the authority lists it, that its entity configuration resolves, and that our redirect uri is registered. Neither of the two blockers it catches is visible to typecheck or to a unit test, because both are agreements with a system outside this repository.

Service table

All fifteen services are deployed, verified, certificates valid and serving over HTTPS as of 2026-08-10. The delegation is live, so nothing here is blocked on DNS any more.

Not under our zone, deliberately, because they must look external:

When #1522 merges

1. dig NS demo.cba.raidiam.io returns the four name servers above.
2. For each row: confirm the hostname resolves, and that Railway has issued a certificate.
3. Fetch each entity's /.well-known/openid-federation and confirm it returns a JWT rather than HTML. The one pre-existing entity on the CBA directory fails exactly this way, so it is a real failure mode and worth checking explicitly.
4. Re-run the federation resolution checks in the universe view.
5. Update this table and close SA-1 in CLAUDE.md.

Do not re-register anything in the directory at that point. Entity IDs were correct from the start; only reachability changes.