Demo Deployments

Current Policy

• the canonical verification path is pnpm build:examples plus pnpm verify:examples
• example deployments do not run automatically on main
• the Next.js, SolidStart, and Remix examples (including their subdomain and tld variants) are excluded from deploy-examples.yml
• the deploy-examples.yml workflow supports manual deployment of the Vite-based examples (TanStack, Waku, React Router — cookie, route, subdomain, and tld) if an additional hosted URL is needed

Live Reference URLs

These URLs describe the intended public reference shape — six frameworks, each in four locale strategies. Switch language in a reachable demo and watch copy, plural seat counts, currency, and dates change together. The demos are grouped by framework below, with every locale-specific URL linked directly where public hosting exists. Remix v3 rows link to source because that beta integration is currently a local/CI proof surface.

How each strategy encodes the locale:

• cookie — one host; the locale is negotiated from Accept-Language, then persisted in a cookie, so there is no per-locale URL.
• route — one host; the locale is the first path segment (/en, /de, /es).
• subdomain — the leftmost DNS label is the locale (de.<app>-subdomain.examples.palamedes.dev).
• tld — the top-level domain is the locale (<app>.examples.palamedes-i18n.de); .com maps to en via an explicit override.

Next.js

Strategy	Live demos
cookie	nextjs-cookie.examples.palamedes.dev
route	en · de · es
subdomain	en · de · es
tld	en · de · es · fr

TanStack Start

Strategy	Live demos
cookie	tanstack-cookie.examples.palamedes.dev
route	en · de · es
subdomain	en · de · es
tld	en · de · es · fr

Waku

Strategy	Live demos
cookie	waku-cookie.examples.palamedes.dev
route	en · de · es
subdomain	en · de · es
tld	en · de · es · fr

React Router

Strategy	Live demos
cookie	react-router-cookie.examples.palamedes.dev
route	en · de · es
subdomain	en · de · es
tld	en · de · es · fr

SolidStart

Strategy	Live demos
cookie	solidstart-cookie.examples.palamedes.dev
route	en · de · es
subdomain	en · de · es
tld	en · de · es · fr

Remix v3

Remix v3 examples are verified through the default Remix Node loader path in CI. They are not public demo deployments yet while the Remix v3 beta hosting and UI adapter story settles.

Strategy	Reference source
cookie	examples/remix-cookie
route	examples/remix-route
subdomain	examples/remix-subdomain
tld	examples/remix-tld

Subdomain Locale Hosting (DNS And Reverse Proxy)

The subdomain demos encode the locale in the leftmost DNS label (de.nextjs-subdomain.examples.palamedes.dev renders German). That label sits one level below the existing *.examples.palamedes.dev wildcard, which only covers a single label: it resolves nextjs-subdomain.examples.palamedes.dev but not de.nextjs-subdomain.examples.palamedes.dev. Each public subdomain example therefore needs its own wildcard record:

• *.nextjs-subdomain.examples.palamedes.dev
• *.tanstack-subdomain.examples.palamedes.dev
• *.waku-subdomain.examples.palamedes.dev
• *.react-router-subdomain.examples.palamedes.dev
• *.solidstart-subdomain.examples.palamedes.dev

(Five records, same record type and target as the existing wildcard.)

The reverse proxy routes every locale host of one example (en./de./es.<app>-subdomain.examples.palamedes.dev) to that example's single backend and must pass the original Host header through unchanged — the app reads it to select the locale, so it is authoritative. As with the other demos, only domain names appear here; the host-to-backend port assignment lives in the internal proxy configuration, not in this document.

Because the locale — and the switch/suggestion links the app renders — are derived from the request host, responses must not be cached host-agnostically. Any cache in front of a subdomain example must include the Host in its cache key (or the app must send Vary: Host); otherwise a response rendered for one locale host could be served for another. This is the same constraint the per-host routing already implies, but it must hold for caching layers too.

These records and proxy routes are now in place, so the five subdomain rows above are publicly reachable (each locale host returns 200 and renders its locale). The canonical verification path remains pnpm verify:examples, which exercises the subdomain strategy locally via *.lvh.me hosts. Remix subdomain support is verified the same way, but it is not included in the public DNS/proxy deployment plan yet.

TLD Locale Hosting (DNS And Reverse Proxy)

The tld demos derive the locale from the top-level domain of the request host. Each framework example is reachable under four TLDs:

• nextjs.examples.palamedes-i18n.com / .de / .es / .fr
• tanstack.examples.palamedes-i18n.com / .de / .es / .fr
• waku.examples.palamedes-i18n.com / .de / .es / .fr
• react-router.examples.palamedes-i18n.com / .de / .es / .fr
• solidstart.examples.palamedes-i18n.com / .de / .es / .fr

All four TLD variants of a given framework point to the same backend. The reverse proxy must pass the original Host header through unchanged — the app reads the TLD to select the locale, so it is authoritative. .de, .es, and .fr are authoritative automatically (country code equals language code); the generic .com is mapped to en through an explicit tld override. A multi-lingual country TLD such as .ch would intentionally be left unmapped (non-authoritative), falling back to Accept-Language or the default locale.

Because locale and switch links are derived from the request host, responses must not be cached host-agnostically. Any cache in front of a tld example must include the Host in its cache key (or the app must send Vary: Host); otherwise a response for one TLD could be served for another. This is the same constraint the per-host routing already implies, but it must hold for caching layers too.

Until these domains are provisioned, the five public tld rows in the Live Reference table are not yet reachable. The canonical verification path runs locally via pnpm verify:examples, which exercises the tld strategy using Chromium's --host-resolver-rules flag to simulate the TLD hosts without real DNS. Remix TLD support is covered by the same local/CI verification path, not by public TLD deployment yet.

Optional Manual Deployments

The optional deployment workflow lives at:

• deploy-examples.yml

It is workflow_dispatch only and intentionally excludes the Next.js examples. If used, it runs:

1. target selection
2. selected example verification with the filtered pnpm verify:examples command
3. manual per-example deployment for the selected non-Next example

Supported deployment targets:

• tanstack-cookie
• tanstack-route
• tanstack-subdomain
• waku-cookie
• waku-route
• waku-subdomain
• react-router-cookie
• react-router-route
• react-router-subdomain
• tanstack-tld
• waku-tld
• react-router-tld

Why Next.js, SolidStart, And Remix Are Not In deploy-examples.yml

The Next.js, SolidStart, and Remix examples are part of the verified matrix, but they are excluded from the deploy-examples.yml workflow. That workflow targets the Vite-based examples (TanStack, Waku, React Router — cookie, route, subdomain, and tld) specifically.

For this OSS setup, the guaranteed baseline is:

• the examples build
• the examples run locally
• SSR, locale routing, cookie handling, and localized server actions are covered in browser tests

The hosting mechanism for the Next.js and SolidStart examples is separate from deploy-examples.yml and is not further documented here. Remix v3 remains a server-first beta proof surface until a public hosting target is chosen.