Skip to main content

Infrastructure Naming

Kubernetes Resources (RFC 1123)​

Kubernetes enforces RFC 1123 naming for most resource types. Violations fail silently through build and test, then break at deploy time.

Rules​

RuleDetail
Lowercase onlyA–Z are not allowed
Alphanumeric and hyphensOnly a–z, 0–9, and -
No leading or trailing hyphensMust start and end with alphanumeric
Max 63 characters253 for multi-label (dot-separated) names
note

Helm release names, ArgoCD application names, and other platform identifiers that map to Kubernetes resources are equally subject to these constraints.

Examples​

Valid InvalidProblem
order-serviceOrder_ServiceUppercase + underscore
payment-api-v2payment-api-v2-Trailing hyphen
auth-worker-auth-workerLeading hyphen
configmap-42configMap-42Uppercase letter

When a violation occurs, the Kubernetes API returns:

metadata.name: Invalid value: "MyApp": a lowercase RFC 1123 subdomain must
consist of lower case alphanumeric characters, '-' or '.', and must start
and end with an alphanumeric character

References​


Environment Variables​

Use SCREAMING_SNAKE_CASE with a hierarchical prefix structure. Group related variables under a shared prefix and spell out units.

# Good:
DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_NAME=app_development
DATABASE_USERNAME=app_user

REDIS_URL=redis://localhost:6379
REDIS_TTL_SECONDS=3600

API_BASE_URL=https://api.example.com
API_TIMEOUT_SECONDS=30
API_MAX_RETRIES=3

# Avoid — ambiguous, inconsistent, abbreviated:
DB_HOST=localhost
DB_P=5432
DATABASE=app_dev
REDIS=redis://localhost:6379
CACHE_TIME=3600

Cache Keys​

Use a colon-separated {namespace}:{identifier}:{aspect} pattern. Keep keys predictable so they can be scanned, expired by prefix, and reasoned about without opening application code.

user:abc123:profile
user:abc123:permissions
session:xyz789:data
api:/users:page=2