Remix.run Logo
anonfordays 4 days ago

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

mcfedr 4 days ago | parent | next [-]

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

thayne 4 days ago | parent | prev | next [-]

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 4 days ago | parent | next [-]

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 4 days ago | parent | prev [-]

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

graemep 4 days ago | parent [-]

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

jan_g 4 days ago | parent | prev | next [-]

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 4 days ago | parent [-]

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 4 days ago | parent | prev [-]

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