Subdomain strategy: www vs. apex, and wildcard subdomains for multi-tenancy

Choosing one as canonical and redirecting the other to it isn't arbitrary — a consistent, single canonical form avoids search engines and inbound links splitting authority between two URLs that serve identical content (a real SEO concern), and avoids cookie/session-scoping inconsistencies that can arise if www and the apex are ever treated as genuinely different origins by some part of a stack. Lesson 3's own apex-CNAME-workaround discussion is part of why www-as-canonical was historically more common (a plain CNAME works cleanly for www, while the apex needed a workaround) — with every modern platform's apex workaround now routine, this historical reason carries less weight than it used to, and the choice is now more genuinely a style and brand preference.

Each of these subdomains can be — and often should be — deployed completely independently, on entirely different platforms if that's what each actually needs: Railway's and Render's own domains both covered exactly this pattern (an api. subdomain on a different platform than the main site), and Vercel's own multi-service/monorepo lesson covered the frontend side of a similar split. A subdomain isn't just a URL convenience; it's the actual seam between independently deployable, independently scalable pieces of a real system.

A wildcard subdomain configuration (*.example.com, paired with a wildcard certificate, lesson 5's own territory) routes every possible subdomain — acme-corp.example.com, widgets-inc.example.com, any arbitrary customer slug — to the same underlying application, which then reads the subdomain from the incoming request to determine which tenant's data to serve. This is a real, common architecture for multi-tenant SaaS products specifically because it gives each customer their own branded-feeling URL without needing to provision a genuinely separate deployment, certificate, or DNS record per customer — the application-level tenant-isolation logic Auth & Multi-Tenancy's own domain covers handles the actual data separation; the wildcard subdomain just handles routing every customer to that same application correctly.

Switching from a single-domain app to a subdomain-per-tenant architecture after launch means real, non-trivial migration work — existing customers' bookmarked/shared URLs, any hardcoded assumptions about the domain in application code, cookie-scoping rules that may have assumed a single origin. Deciding upfront whether a product's actual shape calls for app.example.com for everyone, or a wildcard subdomain per customer, avoids this retrofit entirely — the same "decide the architecture deliberately, not by accident" principle this curriculum's other domains have applied to plenty of other early decisions.