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