ADR 0001: Move all hostnames to peoplewave.in
- Status: accepted
- Date: 2026-11-04 (investigation date; decision date not recorded)
- Decision makers: the project owner, as relayed in the task decisions
Context and problem statement
The platform's hostnames were under peoplewave.org. That domain was suspended at the registrar, so none of its names resolved. DNS for peoplewave.in was already live and pointed rtih, api.rtih, app.rtih, livekit.rtih and grafana.rtih at the ingress load balancer. Which domain should the platform use, and should it keep both?
Decision drivers
- The old domain no longer resolved, so keeping it protected nothing that was serving.
- Email on the new domain already existed.
- Two domains in CORS lists, redirect URIs and certificates multiply the places that can drift.
Considered options
- Support both domains for a transition period.
- Replace
.orgwith.inoutright.
Decision outcome
Replace .org with .in outright. No dual-domain entries anywhere: CORS allow-lists, Keycloak redirect URIs and web origins, certificate names, ingress hosts and cookie domains carry .in only. Email addresses move to the new domain too. The scope is StartupOS hostnames only; another application sharing the cluster is excluded. The Terraform DNS module is retired because records are managed by hand at the DNS host.
Consequences
- Good: one domain to reason about; no stale
.orgentries. - Bad: a certificate for the new names depends on HTTP-01 validation succeeding, and a wildcard name cannot be issued with an HTTP-01-only issuer.
- Bad: changing seed or realm configuration affects new environments only. It does not rename accounts already in the live Keycloak database, so configuration and running state can disagree.
Confirmation
A repository-wide search for peoplewave.org should return only the excluded application's names. The ingress hosts in infra/oci-devops/deploy/ingress.yaml are .in.
Sources
.agents/tasks/migrate-fqdn-peoplewave-in/decisions.json, .agents/tasks/fqdn-migration-deploy/findings.md.