What are the best practice for domain names (dev, staging, production)?

With the rise of containers, Kuberenetes, 12 Factor etc, it has become easier to replicate an identical environment across dev, staging and production. However, what there appears to be no common standard to domain name conventions.

As far as I can see it, there are two ways of doing it:

  • Use subdomains:
    • *.dev.foobar.tld
    • *.staging.foobar.tld
    • *.foobar.tld
  • Use separate domains:
    • *.foobar-dev.tld
    • *.foobar-staging.tld
    • *.foobar.tld

I can see up and downs with both approaches, but I'm curious what the common practise is.

As a side-note, Cloudflare will not issue you certificates for sub-sub domains (e.g. *.stage.foobar.tld).


There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Depends on the company size.

Small businesses usually go for dashes and get the wildcard certificate. So they would have dev.example.com, test.example.com

In larger enterprises they usually have a DNS infrastructure rolled out and the provisioning processes takes care of the assignment. It usually looks like

aws-eu-central-1.appName.staging.[teamName].example.com

They would either use their own self-signed certs with the CA on all servers or have the money for the SANs.

For more inspiration:

https://blog.serverdensity.com/server-naming-conventions-and-best-practices/

https://mnx.io/blog/a-proper-server-naming-scheme/

https://namingschemes.com/


A quick note about the top level domain, many companies also use the ".local" suffix for internal name resolution.


we use below dns names in our environment

  1. *.dev.internal.com ( development )
  2. *.tst.internal.com ( test )
  3. *.stg.internel.com ( staging )
  4. *.internel.com ( prod ). you can also use like *.prd.internal.com

It also depends if you want dev/test/staging be available externally, if not you can set in such way: app_name.example.dev, app_name.example.test and etc