Move the hosted domain
This is the operator checklist for moving the hosted product, documentation, and default relay from paseo-rooms.pyratzlabs.fr to paseo-rooms.pyratz.com. It is a prepared cutover; editing the repository alone does not change DNS or the running service.
The GitHub Pages client remains a separate, default frontend. Its configured relay origin moves to the new domain. The plugin's Pyratz Labs client preset and the documentation canonical URL also use the new domain. A link's embedded relay remains authoritative, so older links need their original relay hostname to keep working.
1. Prepare before changing DNS
- Build and verify the documentation, browser client, plugin, and CI configuration on the migration branch.
- Keep the public relay's registration policy
open; changing its hostname must not reintroduce the registration-key requirement. - Use the existing nginx-proxy stack on the VPS. Do not run the separate Caddy stack on ports already owned by nginx-proxy.
- Keep the old DNS record and virtual host. Avoid a redirect for WebSocket paths: both names should route to the same relay.
- Defer deploying the new default until the new hostname has valid DNS and TLS.
2. Add DNS last
Add the new record in the pyratz.com zone:
| Type | Name | Value |
|---|---|---|
| A | paseo-rooms | 188.165.200.34 |
That is the relay VPS's public IPv4 address observed on 2 November 2026; confirm it still belongs to the deployment before changing DNS. DNS-only mode is sufficient. If using a CDN proxy, ensure WebSockets and the ACME challenge are supported and use validated origin TLS. Do not add an AAAA record unless the server is actually reachable on that IPv6 address.
3. Configure and deploy both hostnames
After DNS resolves, update these values in the existing relay deployment environment, preserving its SSH credentials, capacity limits, and proxy configuration:
ROOMS_DOMAIN=paseo-rooms.pyratz.com
ROOMS_HOSTNAMES=paseo-rooms.pyratz.com,paseo-rooms.pyratzlabs.fr
RELAY_AUTH_MODE=open
Deploy the reviewed GitHub revision to the relay VPS through the operator’s existing deployment flow, and use compose.proxy.yml. The public GitHub workflow publishes the browser client only; it does not deploy the VPS or manage its secrets. The retained .gitlab-ci.yml is a legacy record of that relay deployment, not the new public development workflow. Both nginx-proxy and acme-companion use ROOMS_HOSTNAMES for routing and TLS. The old and new hostnames reach one relay instance, not two competing route tables. Certificate issuance must succeed for both names.
A relay container replacement interrupts connections temporarily. Host runtimes should reconnect and register their rooms again. Avoid restarting the host plugins during this check, because their process-local room keys would be lost.
4. Verify before publishing
Check both hostnames with certificate verification enabled:
curl --fail https://paseo-rooms.pyratz.com/.well-known/paseo-rooms
curl --fail https://paseo-rooms.pyratzlabs.fr/.well-known/paseo-rooms
curl --fail --head https://paseo-rooms.pyratz.com/docs/
Both discovery responses must report "registration":"open". Then:
- Open the new product homepage and documentation. Check navigation and all three shared diagrams.
- Update/reload a test plugin from the reviewed revision and create a new room with automatic discovery and no key.
- Join through the default Pages client in a second browser; verify history, a message, and an image. Verify the Pyratz Labs same-origin client too.
- Reopen an existing complete old invitation after its host reconnects. Confirm it still works, even if the new client asks to confirm the old relay origin.
- Check the new HTTPS/WSS certificate chain and observe relay reconnects before publishing the article.
Deploying server defaults does not update already installed directory plugins or saved Advanced settings. Those users must update their checkout and reload the plugin, or select the new relay manually. Saved custom origins are not silently rewritten.
Roll back
Keep the old hostname active throughout the cutover. If validation fails, restore the previous reviewed application revision and old ROOMS_DOMAIN, retaining both virtual hosts where possible. Do not rotate room secrets or restart host plugins as part of a hostname rollback. Continue serving the old origin until users have moved and no supported invitations depend on it.