Summary: nuxt-website runs the same SSR build behind multiple sibling domains (7mind.de prod, 6mind.de staging, 8mind.de local, 9mind review previews), and an axios request interceptor rewrites outbound backend URLs at request time to match the current request’s hostname family. This is what makes one build deployable across all envs while keeping cookies and CORS aligned. Sources: direct code inspection (plugins/axios-config.js, nuxt.config.ts proxy + publicRuntimeConfig, .env.example, terraform/web-v2/environment/{staging,production}/main.tf) Last updated: 2026-05-15


The problem it solves

A single Nuxt build needs to call the backend under different hostnames depending on environment:

EnvFrontend hostBackend host
Productionwww.7mind.de, www.7sleep.de, *.ca, *.fr, …magic.7mind.de, magic.7sleep.de
Stagingwww.6mind.de, www.6sleep.demagic.6mind.de, magic.6sleep.de
Local devlocalhost, 8mind.de, 8mind.fr (via /etc/hosts)magic.6mind.de proxied
PR previews*.review.6mind.de, 9mind.*magic.6mind.de (staging)

The naming is intentional: replace the leading digit of Nmind.<tld> to switch env. 7 is production, 6 is staging, 8 is local, 9 is preview. The frontend baseURL is set per environment in Terraform, but at runtime any given pod may be reached via any of several hostnames (multiple TLDs, plus the migration host www2.7mind.de).

Cookies and CORS only work if the API hostname matches the page’s hostname family. Hardcoding magic.7mind.de would break staging, local, and previews; hardcoding magic.6mind.de would break production. So the rewrite happens dynamically.

How the rewrite works

The axios interceptor in plugins/axios-config.js:

  1. Determines the current page’s hostname (window.location.hostname client-side; x-forwarded-host or host header server-side).
  2. Looks at the outbound baseURL (or absolute url) and matches ([67]mind)\.(.+)$.
  3. Looks at the current hostname and matches ([6789]mind)\.(.+)$.
  4. If both match, swaps the outbound URL’s Nmind.<tld> segment to match the current hostname’s Nmind.<tld> segment.

So a request configured to https://magic.7mind.de/user/me, made from a page served on 6mind.de, is rewritten to https://magic.6mind.de/user/me before it leaves the browser. All axios calls get withCredentials: true so the cookie travels.

In addition, nuxt.config.ts registers a @nuxtjs/proxy config for local/8mind/9mind hosts that proxies /user/**, /prevention/**, /monetization/**, /user_identity/**, /analytics/** to the configured backend URL, rewriting cookie domains (cookieDomainRewrite: '.8mind.de') and stripping the Secure flag in dev so cookies work over plain HTTP.

Why it matters

  • The same Docker image runs in staging and production, distinguished only by env config. The hostname rewrite means there is no per-env API URL hardcoded into the JS bundle.
  • Cookie authentication via supertokens-auth is host-scoped. Without the rewrite, login cookies set on 6mind.de would not match calls going to 7mind.de.
  • PR preview environments work without extra configuration; whatever review subdomain you land on, the backend calls follow.
  • Localized TLDs (.fr, .it, .nl, etc.) for the same brand share the same logic — they all match the [67]mind\.<tld> family.

What agents should know

  • Do not hardcode magic.7mind.de in frontend code. Use the configured axios.baseURL and let the interceptor adapt it.
  • The regex is ([67]mind)\.(.+)$ for the outbound URL and ([6789]mind)\.(.+)$ for the current host. Hostnames that don’t match (e.g. cdn.7mind.de, partner subdomains, an external *.googleapis.com) are left untouched.
  • If a new env-equivalent domain prefix is introduced beyond 6/7/8/9, the second regex needs updating. Currently only those four digits are recognized.
  • Cookies set by the backend are forwarded by the proxy with their domain rewritten (changeOrigin: true, cookieDomainRewrite). In production this path is not used; the browser talks to magic.<host> directly.
  • Server-side rendering picks up the hostname from x-forwarded-host (set by the Traefik ingress) before falling back to host. Anything stripping or rewriting those headers in the network path will break SSR auth.