Server Naming Conventions and Best Practices

Server Names

By David Mytton,
CEO & Founder of Server Density.

Published on the 29th October, 2015.

Early last year we wrote about the server naming conventions and best practices we use here at Server Density. The post was inspired in part by an issue in one of our failover datacenters in San Jose.

Our workaround involved using Puppet to modify the internal DNS resolvers of the affected servers. Directing an automated change to the affected servers (our San Jose datacenter servers) turned out to be painless. Why? Because our naming convention includes a functional abbreviation for location:

Impressed with how easy deploying the fix was, we decided to talk about it in a post that has since proved quite popular. Frankly, we didn’t expect server naming conventions to be such a gripping topic. So we set out to understand why.

As it turns out, there are two main reasons why server names strike a chord with people.

1. Naming Things is Hard

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

Phil Karlton

Naming servers can get very tough, very quickly. That’s true, partly because deploying them has become incredibly easy. You can have a new server up and running in as little as 55 seconds.


It’s not unheard of for sysadmins to be responsible for dozens, hundreds, perhaps even thousands of servers these days. The cognitive burden involved with naming and managing rapidly escalating swarms of devices is beyond what humans are accustomed to.

Most people only ever get to name a few things in their life.

Chi chi van raisin

And yet, that’s what sysadmins find themselves doing for much of their day.

2. Servers Are not What They Used to Be

Not long ago, servers occupied physical space. We could see and touch them.

That’s no longer the case. The elastic nature of deploying infrastructure affords us an order of magnitude more servers that we can’t even see.

Attempting to stretch old-school naming conventions (planet names and Greek Gods) to the limitless scope of this brave new world is proving to be difficult, if not impossible.

Our habits and practices hail from a time when caring for each individual box was part of our job. When that doesn’t work, or suffice, we experience cognitive dissonance and confusion.

“We’ve had flame wars on internal team mailing lists arguing how it should be done to no result,” wrote one sysadmin on Reddit.

There is no such thing as a golden rule—much less a standard—on how to name servers.

A sysadmin said they name servers “randomly, based on whatever whim we are on that day”. Other methods were even more state of the art: “I just roll my face on the keyboard. That way there’s sure to be no duplicates.”

We spoke to Matt Simmons from Standalone Sysadmin to get his expert opinion on this transition.

“A computer infrastructure largely exists in one of two worlds,” he says. “Either you have so few machines that you individually deal with them, and they’re treated as pets, or you have so many that you can’t individually deal with them, and you treat them like cattle.”

Servers as Pets – our Old Scheme

Names give meaning. They allow us to understand and communicate. When we are battling with the same few boxes day in day out, it makes sense to give them personable, endearing names.

From Aztec Gods and painkillers, to Sopranos and Babar the Elephant, there is no shortage of charming candidates.

When dealing with a limited amount of servers, “pet” naming conventions work really well. They are short, memorable, and cute. They’re also completely decoupled from the server’s role, which makes it harder for hackers to guess their name (security through obscurity).

Back when we had a smaller number of servers we based our naming scheme on characters from His Dark Materials by Philip Pullman. A master database server was Lyra and the slave was Pan.

Much of the formal guidance we found online caters for similar scenarios, i.e. finite numbers of servers. An old RFC offers some astute guidance:

Words like “moron” or “twit” are good names if no one else is going to see them. But if you ever give someone a demo on your machine, you may find that they are distracted by seeing a nasty word on your screen. (Maybe their spouse called them that this morning.)

Servers as Cattle – our New Scheme

“The engineer that came up with our naming scheme has left the company. Nobody knows what is hosted on Prometheus anymore.” Sound familiar?

There’s only so many heroes in A-Team and Arrested Development. Dog Breeds will only get you that far. There comes a point when naming servers has to be more about function than form.

We moved to our current naming structure a few years ago. This allows us to quickly identify key information about our servers. It also helps us filter by role, provider or specific locations. Here is an example:

hcluster3 : this describes what the server is used for. In this case, it’s of cluster 3, which hosts our alerting and notification service (our monitoring app is built using a service orientated architecture). Other examples could be mtx2 (our time series metrics storage cluster) or sdcom (servers which power our website).

web1 : this is a web server (Apache or nginx) and is number 1 in the cluster. We have multiple load balanced web servers.

sjc : this is the datacenter location code, San Jose in this case. We also have locations like wdc (Washington DC) or tyo (Tokyo).

sl : this is the facility vendor name, Softlayer in this case. We also have vendors like rax (Rackspace) and aws (Amazon Web Services).

The advantage of this naming convention is that it scales as we grow. We can append and increment the numbers as needed.

As per above, it’s also easy to modify servers based on criteria (role, provider, location). In our Puppet /etc/resolv.conf template we can do things like:

<% if (domain =\~ /sl/) -%>
<% if (domain =\~ / -%>
# google DNS - temp until SL fixed
<% else %>
# Internal Softlayer DNS
<% end -%>

One disadvantage with long server names is that they can be unwieldy.

When compared to “pet” names, “cattle” server names are hard to remember and even harder to type in CLIs. They also need to be updated when servers are moved to different geographies or their roles change.

Security-wise they’re often seen as less robust than their “pet” name equivalents. That’s because they make it just one step easier for hackers, by helping them deduce the names of servers they want to access.


The transition to cloud computing has caused a dramatic increase of servers that sysadmins are tasked to administer (and provide names for).

A good naming convention should make it easy to deploy, identify and filter through your server pool. If you’re only planning to have a handful of servers, then coming up with real names (servers as pets) might suffice.

For anything remotely scaleable and if identifying your servers is key, then consider something more practical and functional (servers as cattle).

Free eBook: 4 Steps to Successful DevOps

This eBook will show you how we i) hacked our on-call rotation to increase code resilience, ii) broke our infrastructure, on purpose, to debug quicker and increase uptime, and iii) borrowed practices from the healthcare and aviation industry, to reduce complexity, stress and fatigue. And speaking of stress and fatigue, we’ve devoted an entire chapter on how we placed humans at the centre of Ops, in order to increase their productivity and boost the uptime of the systems they manage. What are you waiting for, download your free copy now.

Help us speak your language. What is your primary tech stack?

What infrastructure do you currently work with?

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time