Introduction

sed is one of those tools many engineers know exists but rarely feel confident using.

It’s often described as:

• confusing
• dangerous
• easy to misuse

And yet, in real DevOps work, sed quietly solves problems that would otherwise require scripts, editors, or manual intervention.

sed is not about clever one-liners.
It’s about safe, repeatable text transformation at scale.

This post explains how sed is used in real-world DevOps scenarios — where reliability matters more than elegance.

---

Why sed Matters in DevOps

DevOps work involves constant change:

• configuration updates
• environment differences
• version bumps
• migration fixes
• automation pipelines

Most of these changes are:

• text-based
• repetitive
• error-prone if done manually

sed exists to make these changes predictable and automatable.

---

Scenario 1: Updating Configuration Values Safely

The Situation

You need to update a config value across environments:

• timeout values
• feature flags
• URLs
• ports

Manual edits don’t scale.

Example

sed 's/timeout=30/timeout=60/' app.conf

This replaces the value without touching anything else.

Why this matters

• No accidental edits
• Easy to test
• Works the same everywhere

---

Scenario 2: Environment-Specific Configuration During Deployments

The Situation

The same artifact is deployed to:

• dev
• staging
• production

But environment values differ.

Example

sed "s/{{ENV}}/production/" config.yaml

This is commonly used in:

• CI/CD pipelines
• Docker entrypoints
• Helm pre-processing
• GitOps workflows

Why this matters

You avoid maintaining multiple config copies.

---

Scenario 3: Fixing Broken Data After an Incident

The Situation

A production issue corrupts or misformats data:

• bad prefixes
• wrong delimiters
• malformed lines

Reprocessing manually is risky.

Example

sed 's/ERROR:/WARN:/' logs.txt

Or remove unwanted characters:

sed 's/\r//' file.txt

Why this matters

sed allows controlled, repeatable cleanup without opening files in editors.

---

Scenario 4: Bulk Changes Across Many Files

The Situation

A service name, API version, or endpoint changes.

You need to update it everywhere.

Example

sed -i 's/v1\/api/v2\/api/g' *.yaml

Why this matters

• Prevents partial updates
• Reduces human error
• Enables rollback via version control

---

Scenario 5: sed in CI/CD Pipelines

The Situation

A pipeline needs to:

• inject versions
• modify manifests
• adjust paths dynamically

Example

sed -i "s/IMAGE_TAG=.*/IMAGE_TAG=$CI_COMMIT_SHA/" deploy.env

Why this matters

sed enables deterministic pipelines without complex tooling.

---

Scenario 6: Removing Sensitive Data Before Sharing Logs

The Situation

Logs need to be shared externally but contain:

• tokens
• secrets
• internal URLs

Example

sed 's/token=[^ ]*/token=REDACTED/g' logs.txt

Why this matters

Security incidents often happen during debugging — not attacks.

---

sed Is Dangerous — If You Don’t Respect It

Common mistakes:

• Running -i without backup
• Writing untested expressions
• Applying changes blindly
• Using sed where parsing is required

Best practice:

• Test first without -i
• Keep files under version control
• Use backups when modifying in place

---

grep + sed: A Powerful Combination

In real workflows, tools work together.

Example:

grep "timeout" app.conf | sed 's/timeout=30/timeout=60/'

This narrows scope before transformation.

---

When NOT to Use sed

Avoid sed when:

• Data is structured (JSON, YAML parsing needed)
• Logic becomes complex
• Readability suffers

In those cases:

• Use jq
• Use templates
• Use configuration management tools

---

Final Thoughts

sed is not about clever tricks.

It’s about:

• reducing manual effort
• making changes safe
• enabling automation
• keeping systems consistent

In real DevOps work, reliability beats elegance every time — and sed helps enforce that discipline.