Naming conventions that keep a large estate manageable

Decide the scheme in week one and keep it in one file. It costs twenty minutes then. At fifty sites it costs a move per site, because panel usernames and database names are not renamed in place: you create the new one, copy, repoint, delete. So whatever you drift into is what you keep. Choose it knowing that some of these names never leave your account while others are public the day you create them.

Which names stay private and which surface

The rule that falls out of the table

Derive names from information that is already public, and never from information that is not. A username derived from the domain leaks nothing an observer could not read off the site itself. A username of cl01, cl02, cl03 reveals a count, an ordering and an obvious next guess, and it only takes one leaked path for the whole series to become enumerable. Sequence is the problem, not the pattern.

Conventions worth copying

• Panel user: acmeco, from the registrable domain stem, lowercase alphanumerics, kept short because these fields cap low and capped lower on older builds. Add a digit only to break a real collision. No lookup table is needed, because the name is recomputable from the domain.
• Databases: the panel forces a user_ prefix, so spend the rest on the application: acmeco_wp, acmeco_wpstg, acmeco_shop. Role, not counter. This string can end up in a browser one bad afternoon, and it should describe an app rather than the shape of your estate.
• Database users: one per application, never a shared acmeco_admin. Grants stay narrow and a leaked credential stays local.
• Mailboxes: role addresses, billing@, abuse@, dns@, with named humans only where a human must be reachable. Roles survive staff changes. Avoid wp-acmeco@, which announces the stack for nothing.
• Backups: 2026-08-01_acmeco_full.tar.gz. Date first, so a plain lexical sort is already chronological and the oldest file is the first line of output.

The two places conventions leak

Non-public environments are the first. staging.acmeco.com is fine, because it sits under a domain the world already connects to that client. acmeco-staging.myagency.net ties a client to you in a public log forever, and repeating the pattern publishes your client list to anyone who searches your own domain. Obscurity is not the control here: restrict staging by authentication or address, then the label stops mattering.

Backup location is the second. A predictable filename is safe when the directory is unreachable and reckless when it is not. Stage archives in /home/acmeco/backups/, above public_html, and predictability becomes an asset. Same for the estate record: one row per site, fixed columns, held somewhere that is never part of a deployment.

If you are already at fifty sites

1. Freeze the convention today and apply it to every site from now on. Mixed estates are normal; unwritten ones are not.
2. Rename only where a move is happening anyway. A migration or rebuild is free renaming; nothing else justifies the downtime.
3. Fix leaks instead of names. Switch debug output off, keep error display server-side, and confirm no archive answers over HTTP.
4. Break sequences last, and only where one name genuinely predicts another that matters.

Plan address layout and naming in the same sitting, since both decide what an outsider can infer from one observation; the surrounding decisions live under network planning, and the day-to-day discipline under running your estate.