Mutable server traditions - the legacy approach

Mutable server traditions are the legacy approach: servers are updated in place, configured manually, and patched over time. This lesson covers what that means and the limitations.

What mutable means

A mutable server is one that is updated in place:

• Install packages.
• Modify configuration.
• Apply patches.
• Restart services.

The server’s state evolves over time. The current state includes every change ever made.

Why mutable was the norm

Historically, mutable was the only option:

• Manual configuration: each server is configured by an operator.
• In-place updates: packages and patches are applied directly to running systems.
• Incremental changes: changes are made when needed, not redeployed.

For decades, this was the only way to manage servers.

Limitations

Mutable server management has well-known limitations:

• Drift: servers that started identical end up different.
• Snowflake servers: each server is unique; no two are alike.
• Hard to reproduce: “what was the state of web01 on 2026-08-01?” is not answerable.
• Hard to test: changes are applied to production; testing is limited.
• Hard to scale: each server needs manual care.
• Slow recovery: rebuilding a server takes time.

The limitations get worse as the fleet grows.

When mutable is acceptable

Mutable is acceptable for:

• Single-server setups: a handful of servers can be managed manually.
• Stateful services: services that cannot be redeployed (legacy databases, custom hardware).
• Development environments: where reproducibility matters less.

For most production, the limitations of mutable outweigh the simplicity.

Knowledge check