Tired of copy-pasting configs and breaking production? Learn how to move from messy manual edits to robust, templated deployments using real-world DevOps practices that separate configuration from logic.

Stop Asking for ‘Templates’ and Start Building a System

I remember a Tuesday… 3:00 PM. The PagerDuty alert screams through my headphones. Staging is down. Hard. The team is scrambling, and after ten minutes of frantic log-diving, we find the culprit. A new engineer, just trying to be helpful, needed to test a feature flag. He copied the config.prod.yaml, changed the one value he needed, deployed it to staging, and forgot to change the database connection string. Just like that, our staging environment was trying to run destructive schema migrations against the live production database. We caught it in time, but it was a cold-sweat moment that cost us an hour of productivity and a few years off my life. This is why the question “do you have a template I can use?” always makes me nervous. It’s not about the template; it’s about the broken process it implies.

The Real Problem: Configuration Drift

When you have static, hand-edited configuration files for each environment (e.g., docker-compose.dev.yml, docker-compose.staging.yml, docker-compose.prod.yml), you’re fighting a losing battle against something we call “Configuration Drift.” The files start out similar, but over time, small, undocumented changes are made to one and not the others. You’re relying on human discipline to keep everything in sync, and that’s a strategy that always fails. The goal is to have a single source of truth for your application’s structure and inject environment-specific values into it reliably and automatically.

Solution 1: The Quick Fix (Shell Script Magic)

Let’s be honest, sometimes you just need to get something working right now. This is the duct tape of configuration management. It’s not pretty, but it gets the job done for a simple project or a proof-of-concept. The idea is to use a basic template file with placeholder variables and then use a shell command like envsubst to substitute them from environment variables during your CI/CD pipeline.

First, create a template file, let’s call it config.template.yaml:

# config.template.yaml
database:
  host: ${DB_HOST}
  port: ${DB_PORT}
  user: "default_user"

api:
  url: "https://${API_SUBDOMAIN}.techresolve.io"

Then, in your deployment script (e.g., in GitLab CI or Jenkins), you export the variables and run the command:

# deploy-staging.sh
export DB_HOST="stg-db-01.internal"
export DB_PORT="5432"
export API_SUBDOMAIN="api-staging"

# The 'envsubst' command reads the template and substitutes the variables
envsubst < config.template.yaml > config.staging.yaml

# Now you can use the generated config.staging.yaml file
docker-compose -f docker-compose.yml -f config.staging.yaml up -d

Warning: This approach is brittle. It gets messy with more than a few variables, has no built-in validation, and can have weird side effects with complex strings. Use it to get un-stuck, but plan to replace it.

Solution 2: The Permanent Fix (A Real Templating Engine)

This is where you graduate to a professional setup. The principle is the same—separating data from the template—but you use a purpose-built tool that offers logic, loops, conditionals, and validation. The tool you choose depends on your stack: Jinja2 for Ansible, HCL for Terraform, or Go templating for Helm.

Let’s look at a simple example using Ansible with Jinja2 templates. You’d have your template file and a separate variables file for each environment.

The Template File (nginx.conf.j2):

# This is a Jinja2 template. Note the {{ variable }} syntax.
server {
    listen 80;
    server_name {{ server_name }};

    location / {
        proxy_pass http://{{ upstream_app_host }}:{{ upstream_app_port }};
    }

    # Only include this block if we are in production
    {% if env == 'prod' %}
    location /admin {
        # Restrict access to internal IPs
        allow 10.0.0.0/8;
        deny all;
    }
    {% endif %}
}

Staging Variables (vars/staging.yml):

env: "staging"
server_name: "app-stg.techresolve.com"
upstream_app_host: "app-staging-web-01"
upstream_app_port: "8080"

Production Variables (vars/prod.yml):

env: "prod"
server_name: "app.techresolve.com"
upstream_app_host: "app-prod-web-cluster"
upstream_app_port: "8080"

When you run your Ansible playbook, you simply tell it which variable file to use. The template remains identical for all environments. This is the gold standard for infrastructure as code. You have a single, version-controlled template and separate, easy-to-read files for your environment-specific values.

Solution 3: The ‘Nuclear’ Option (The Platform Approach)

In a very large organization, even managing hundreds of Jinja2 templates can become a job in itself. The next evolution is to abstract the problem away entirely by building an Internal Developer Platform (IDP). Tools like Backstage or custom-built portals provide a “self-service” layer for developers.

In this model, a developer doesn’t even see the template. They go to a web UI and fill out a form:

• Application Name: payment-processor
• Language: Go
• Environment Type: Staging
• Database Required: Postgres (Small)

They click “Create,” and the platform engineering team’s backend machinery takes over. It uses standardized templates (Helm charts, Terraform modules, etc.) and the developer’s inputs to provision the infrastructure, set up the CI/CD pipeline, and deploy the application. This is the ultimate solution for enforcing standards and reducing cognitive load on developers, but it requires a dedicated platform team to build and maintain it.

Which Approach Is Right For You?

So, the next time you’re tempted to ask for a “template,” take a step back. Ask instead: “What’s the right system for managing our configuration?” Moving from copy-pasting to a real templating system is a foundational step in your DevOps journey. It’s what separates brittle, high-anxiety deployments from the calm, predictable, and boring ones—and trust me, when it comes to deployments, boring is beautiful.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions