Stop the copy-paste nightmare of managing similar configuration files across environments. A senior engineer breaks down three battle-tested methods—from quick shell scripts to robust templating—to solve the ‘almost identical’ content problem for good.

The ‘Almost Identical’ Config Problem: A Senior Engineer’s Guide to Ditching Copy-Paste

I still remember the 3 AM page. A “routine” deployment to our staging environment had somehow crippled the checkout API for our main production app. The team was scrambling, dashboards were red, and nobody could figure out how a staging change was hitting a production system. After a frantic hour, we found it: a single, forgotten line in a Kubernetes ConfigMap. A developer, trying to be helpful, had copied the `prod` config for a new microservice, updated 99% of the values for `staging`, but missed one single environment variable pointing to the production database URL. It was a classic copy-paste disaster. We’ve all been there, and it’s a symptom of a much deeper problem I call the ‘almost identical’ content trap.

So, Why Does This Keep Happening?

Let’s be real: it’s not just about being lazy. The root cause is a failure to separate structure from values. Your Nginx config for staging and production has the exact same structure—the same directives, the same blocks, the same logic. The only things that change are the values: the server name, the SSL certificate path, the upstream API endpoint. When you manage these as two separate, monolithic files, you’re forcing a human to be a version control system for tiny, critical differences. And humans, especially at 2 AM, make mistakes. This is known as “configuration drift,” and it’s a silent killer of reliable systems.

Three Ways to Fix This, From Gritty to Grand

Over the years, I’ve seen and implemented a few ways to tackle this. The right choice depends on your team, your tools, and how much time you have. Here are my top three, from the quick-and-dirty to the architecturally sound.

Solution 1: The Shell Scripter’s Duct Tape

Sometimes you just need to get it done. You have a single file, a simple deployment script, and no time to set up a new tool. This is where basic shell substitution comes in. It’s not pretty, but it works.

The idea is simple: create a template file with placeholder variables. Then, use a shell command like sed or envsubst in your CI/CD pipeline to swap them out.

Here’s a template `nginx.conf.template`:

server {
    listen 443 ssl;
    server_name ${SERVER_HOSTNAME};
    ssl_certificate /etc/ssl/certs/${CERT_NAME}.crt;
    ssl_certificate_key /etc/ssl/private/${CERT_NAME}.key;

    location / {
        proxy_pass http://${UPSTREAM_API_HOST};
    }
}

And your deployment script could look like this:

#!/bin/bash
# deploy.sh

# Set variables based on the environment
if [ "$ENVIRONMENT" == "prod" ]; then
    export SERVER_HOSTNAME="api.mycompany.com"
    export CERT_NAME="prod-cert"
    export UPSTREAM_API_HOST="prod-api-backend:8080"
elif [ "$ENVIRONMENT" == "staging" ]; then
    export SERVER_HOSTNAME="staging-api.mycompany.com"
    export CERT_NAME="staging-cert"
    export UPSTREAM_API_HOST="staging-api-backend:8080"
fi

# Substitute variables and create the final config
envsubst < nginx.conf.template > /etc/nginx/sites-available/default

Warning: This method is brittle. It’s terrible for complex logic like loops or conditionals. If you find yourself writing `sed` commands with more than two substitutions, it’s time to move on to the next solution. Trust me.

Solution 2: The Right Way (For Most People) – Templating Engines

This is where we start treating our configuration like proper code. A dedicated templating engine like Jinja2 (used heavily by Ansible), Go Templates (used in Helm), or HCL (used by Terraform) gives you the power of a real programming language: variables, loops, conditionals, and more.

This approach fully separates the data (your values per environment) from the presentation (the template). Your environment-specific values live in a structured data file like YAML or JSON, which is much easier to manage.

Here’s our `nginx.conf.j2` Jinja2 template:

server {
    listen 443 ssl;
    server_name {{ server_hostname }};
    ssl_certificate /etc/ssl/certs/{{ cert_name }}.crt;
    ssl_certificate_key /etc/ssl/private/{{ cert_name }}.key;

    # An example of a conditional
    {% if enable_rate_limiting %}
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
    {% endif %}

    location / {
        proxy_pass http://{{ upstream_api_host }};
        {% if enable_rate_limiting %}
        limit_req zone=mylimit;
        {% endif %}
    }
}

Your values for production could be in a `prod.yml` file:

---
server_hostname: "api.mycompany.com"
cert_name: "prod-cert"
upstream_api_host: "prod-api-backend:8080"
enable_rate_limiting: true

Tools like Ansible can then render this template with the correct values file during deployment. This is the gold standard for managing configuration files in an infrastructure-as-code world. It’s testable, repeatable, and scales beautifully.

Solution 3: The Architect’s Approach – Runtime Configuration

This is the “nuclear option” because it often requires changing the application itself, not just the deployment process. The question here is: why are we even baking these values into a file at build or deploy time?

The most robust systems make the deployed artifact (like a Docker container) identical across all environments. The container is environment-agnostic. It learns its identity—whether it’s `staging` or `prod`—at runtime by fetching its configuration from an external source.

This could be:

• Reading environment variables injected by the orchestrator (like Kubernetes).
• Querying a dedicated configuration service like AWS Systems Manager Parameter Store, HashiCorp Consul, or Vault on startup.

In this model, your application code is responsible for fetching its config. For example, a Go application might do this on startup:

func main() {
    // Get the environment from an OS environment variable
    env := os.Getenv("APP_ENVIRONMENT") // e.g., "staging" or "production"

    // Fetch the specific database connection string from a secrets manager
    dbConn, err := secretsmanager.GetSecret(fmt.Sprintf("/%s/database/connection_string", env))
    if err != nil {
        log.Fatalf("Failed to fetch config: %v", err)
    }

    // ... now connect to the database and start the app
}

This completely eliminates config files from your repository for sensitive or environment-specific values. It’s the most secure and flexible approach, but it requires buy-in from your development team to build apps this way.

Comparing The Approaches

Here’s a quick breakdown to help you decide.

Approach	Complexity	Scalability	Best For…
1. Shell Duct Tape	Low	Low	Quick fixes, personal scripts, or very simple, one-off deployments.
2. Templating Engine	Medium	High	The default choice for most IaC setups (Ansible, Terraform, Helm). Perfect for managing config across multiple complex environments.
3. Runtime Config	High	Very High	Cloud-native applications, microservices architectures, and systems where security and dynamic configuration are paramount.

Ultimately, the goal is to get away from being a human `diff` tool. Start with the simplest solution that removes the manual copy-paste step. If you’re using shell scripts now, plan your migration to a templating engine. If you’re already there, start talking with your developers about runtime configuration. Your 3 AM self will thank you for it.

---

🤖 Frequently Asked Questions