At work, whoever designed our setup put the staging and dev environments on the same domain and the entire massive company has adopted this pattern.

What a colossal mistake.

▲

teaearlgraycold 7 months ago | parent | next [-]

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

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

▲

mcfedr 7 months 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 7 months 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 7 months 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 7 months 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 7 months ago \| parent [-]
		The production site could be www. or something else that makes sense.

▲

jan_g 7 months 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 7 months 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 7 months ago | parent | prev [-]

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

▲

NavinF 7 months ago | parent | prev | next [-]

Yep. Even within the prod environment it's ideal to have a separate domain (as defined by the Public Suffix List) for sketchy stuff like files uploaded by users. Eliminates a whole class of security issues and general fuckery

▲

jamesfinlayson 7 months ago | parent | prev | next [-]

I had the option to re-use the prod domain for non-prod a few years ago (the company's other two projects use the prod domain for all non-prod environments).

I didn't really think about cookies back then but it just felt like a generally bad idea because disastrously messing up a URL in some config or related service would be much easier.

▲

dgoldstein0 7 months ago | parent [-]

Nah dev should probably be a separate tld so the cookies are completely isolated.

Stage, it depends - if you want stage to have production data with newer code, and are fine with the session / cookies being shared - host it on the same domain and switch whether users get stage or prod based on IP, who is logged in, and/or a cookie. That way your code doesn't have to do anything different for stage vs prod every time it looks at the request domain (or wants to set cookies).

If you want an isolated stage environment, why not just use a separate top level domain? Otherwise you are likely seeing yourself up for the two interfering with each other via cookies on the TLD.

	▲	jamesfinlayson 7 months ago \| parent [-]
		Yeah that's what I meant by separate domain - separate top level domain. Not that we use cookies much but it's one less thing to worry about.

▲

anal_reactor 7 months ago | parent | prev [-]

I'm sure this will be replicated in future projects because it's much easier to argue "we're already following this pattern so let's be consistent" than "this pattern is bad and let's not have two ruined projects"