[teaearlgraycold]

For the juniors reading this, here's what you do:

Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

[anonfordays]

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

[mcfedr]

The reason not to do that is that dev.example.com can set cookies on example.com and other envs can see them.

[thayne]

That only works if you (and any third party code that might run on such a domain) are completely consistent about always specifying the domain as one of your subdomains whenever you set a cookie.

And if your marketing/SEO/business people are ok with having something like "prod" as a subdomain for all your production web pages.

[sensanaty]

Usually it's mainsite.com for the marketing site, and then app.mainsite.com for actual production, or if you have multiple it'll have the product name, like coolproduct.mainsite.com

We then have app-stg and app-canary subdomains for our test envs which can only be accessed by us (enforced via zero trust). No reason for marketing or SEO teams to care in any case.

[netdevphoenix]

When was the last time you saw a public website like that? prod.companyname.com websites are extremely rare especially outside tech.

[graemep]

The production site could be www. or something else that makes sense.

[jan_g]

We have *.example.dev, *.example.qa, *.example.com for development, staging/qa and production. Works well and we haven't had any issues with cookies.

[teaearlgraycold]

This works fine and is what I’ve done. But if you’re sending email from those domains or working with enterprise customers using the same TLD will be helpful.

[teaearlgraycold]

Ah yes if you use a CNAME that would work. You know better than me.