DevOps

Jak porovnat .env soubory mezi prostředími

31. ledna 2026
10 min čtení
env diffkonfiguracedevops.env souboryenvironment variables

Deployoval jsem a aplikace spadla. Důvod? Chyběla env proměnná co byla na dev, ale ne na produkci. Od té doby před každým deployem porovnávám .env soubory.

Co je .env soubor

Textový soubor s proměnnými prostředí - databáze, API klíče, nastavení aplikace. Každé prostředí (dev, staging, produkce) má trochu jiný.

Typická struktura .env souboru:

# Databáze
DATABASE_URL=postgresql://user:password@localhost:5432/myapp
DATABASE_POOL_SIZE=10

# API klíče
STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxxx
SENDGRID_API_KEY=SG.xxxxxxxxxxxxxxxx

# Aplikační nastavení
APP_ENV=development
APP_DEBUG=true
APP_URL=http://localhost:3000

# Redis cache
REDIS_URL=redis://localhost:6379

Proč potřebujete různá prostředí?

Vývojové prostředí (development):

  • Lokální databáze
  • Testovací API klíče
  • Debug mód zapnutý
  • Volnější bezpečnostní pravidla

Testovací prostředí (staging):

  • Kopie produkční databáze (anonymizovaná)
  • Sandbox API klíče
  • Podobná konfigurace jako produkce
  • Přístup pro testery

Produkční prostředí (production):

  • Ostrá databáze
  • Skutečné API klíče
  • Debug vypnutý
  • Maximální bezpečnost

Proč je porovnání .env souborů kritické?

1. Chybějící proměnné způsobují pády aplikace

Nejčastější problém: Vývojář přidá novou proměnnou do lokálního .env, ale zapomene ji přidat na produkci. Aplikace pak spadne s chybou "undefined environment variable".

Příklad reálné situace:

# .env.development (lokální)
DATABASE_URL=postgresql://localhost/myapp
REDIS_URL=redis://localhost:6379
NEW_FEATURE_API_KEY=test_key_12345  # Nově přidáno

# .env.production (produkce)
DATABASE_URL=postgresql://prod-server/myapp
REDIS_URL=redis://prod-redis:6379
# NEW_FEATURE_API_KEY chybí! → Aplikace spadne

2. Bezpečnostní rizika

Testovací klíče na produkci mohou způsobit:

  • Úniky citlivých dat
  • Finanční ztráty (např. špatný Stripe klíč)
  • Bezpečnostní incidenty

3. Různé hodnoty způsobují nekonzistentní chování

Když se hodnoty proměnných liší, aplikace se chová jinak v různých prostředích:

# .env.staging
MAX_UPLOAD_SIZE=10MB
SESSION_TIMEOUT=3600

# .env.production
MAX_UPLOAD_SIZE=5MB      # Přísnější limit
SESSION_TIMEOUT=1800     # Kratší timeout

Jak efektivně porovnat .env soubory

Metoda 1: Online nástroj PorovnejText.cz

Nejrychlejší způsob pro okamžité porovnání:

  1. Otevřete PorovnejText.cz
  2. Vložte obsah prvního .env souboru do levého pole
  3. Vložte obsah druhého .env souboru do pravého pole
  4. Klikněte na "Porovnat"

Výhody:

  • ✅ Okamžitý výsledek
  • ✅ Barevné zvýraznění rozdílů
  • ✅ Žádná instalace
  • ✅ 100% soukromí – soubory zůstávají v prohlížeči

Tip: Před porovnáním seřaďte klíče abecedně pro lepší přehlednost:

sort .env.development > .env.dev.sorted
sort .env.production > .env.prod.sorted

Metoda 2: Příkazová řádka (diff)

Pro rychlé porovnání v terminálu:

# Základní diff
diff .env.development .env.production

# Side-by-side zobrazení
diff -y .env.development .env.production

# Pouze názvy proměnných (bez hodnot)
diff <(cut -d= -f1 .env.development | sort) <(cut -d= -f1 .env.production | sort)

Metoda 3: Skript pro kontrolu klíčů

Vytvoření vlastního skriptu pro kontrolu chybějících proměnných:

#!/bin/bash
# check-env.sh - Kontrola konzistence .env souborů

ENV_DEV=".env.development"
ENV_PROD=".env.production"

echo "=== Proměnné pouze v DEVELOPMENT ==="
comm -23 <(cut -d= -f1 "$ENV_DEV" | grep -v "^#" | sort) \
         <(cut -d= -f1 "$ENV_PROD" | grep -v "^#" | sort)

echo ""
echo "=== Proměnné pouze v PRODUCTION ==="
comm -13 <(cut -d= -f1 "$ENV_DEV" | grep -v "^#" | sort) \
         <(cut -d= -f1 "$ENV_PROD" | grep -v "^#" | sort)

Metoda 4: VS Code rozšíření

Pro vývojáře používající VS Code:

  1. Otevřete oba soubory
  2. Pravý klik → "Select for Compare"
  3. Pravý klik na druhý soubor → "Compare with Selected"

Best practices pro správu .env souborů

1. Používejte .env.example jako šablonu

Vytvořte soubor .env.example s prázdnými hodnotami a commitněte ho do repozitáře:

# .env.example (commitovaný do Gitu)
DATABASE_URL=
REDIS_URL=
STRIPE_SECRET_KEY=
APP_ENV=
APP_DEBUG=

Výhody:

  • Dokumentace všech potřebných proměnných
  • Nový vývojář ví, co nastavit
  • Lze automaticky kontrolovat proti skutečným .env

2. Automatická kontrola v CI/CD

Přidejte do CI pipeline kontrolu konzistence:

# .github/workflows/check-env.yml
name: Check Environment Variables

on: [push, pull_request]

jobs:
  check-env:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check .env.example completeness
        run: |
          # Extrahuj klíče z .env.example
          EXAMPLE_KEYS=$(cut -d= -f1 .env.example | grep -v "^#" | sort)

          # Zkontroluj, že všechny klíče jsou dokumentované
          if [ -f ".env.production.template" ]; then
            PROD_KEYS=$(cut -d= -f1 .env.production.template | grep -v "^#" | sort)
            MISSING=$(comm -13 <(echo "$EXAMPLE_KEYS") <(echo "$PROD_KEYS"))
            if [ -n "$MISSING" ]; then
              echo "Chybějící proměnné v .env.example:"
              echo "$MISSING"
              exit 1
            fi
          fi

3. Validace při startu aplikace

Přidejte validaci proměnných prostředí do aplikace:

// config/env.ts
const requiredEnvVars = [
  'DATABASE_URL',
  'REDIS_URL',
  'APP_ENV',
  'SESSION_SECRET'
];

export function validateEnv(): void {
  const missing = requiredEnvVars.filter(
    (key) => !process.env[key]
  );

  if (missing.length > 0) {
    throw new Error(
      `Chybějící proměnné prostředí: ${missing.join(', ')}`
    );
  }
}

4. Používejte nástroje pro správu secrets

Pro větší projekty zvažte:

dotenv-vault – Šifrované .env soubory s verzováním HashiCorp Vault – Enterprise řešení pro správu secrets AWS Secrets Manager – Cloud-native řešení pro AWS Azure Key Vault – Microsoft cloud řešení

Častá úskalí a jak se jim vyhnout

Úskalí 1: Commitování .env do Gitu

Problém: Skutečný .env soubor se dostal do repozitáře.

Řešení:

# .gitignore
.env
.env.local
.env.*.local
.env.production
.env.staging

# Povoleno
.env.example
.env.template

Pokud už je soubor commitovaný:

git rm --cached .env
git commit -m "Remove .env from tracking"
# Nezapomeňte změnit všechny kompromitované klíče!

Úskalí 2: Různé formáty hodnot

Různá prostředí mohou mít různé formáty:

# Development
DATABASE_URL=postgresql://localhost/myapp

# Production (s parametry)
DATABASE_URL=postgresql://user:pass@host/db?sslmode=require&pool=10

Tip: Při porovnávání se zaměřte na strukturu URL, ne přesnou shodu.

Úskalí 3: Komentáře a prázdné řádky

Různé formátování může zmást diff nástroje:

# File 1
DATABASE_URL=...
# Komentář
REDIS_URL=...

# File 2
DATABASE_URL=...
REDIS_URL=...
# Komentář na jiném místě

Řešení: Před porovnáním odstraňte komentáře:

grep -v "^#" .env | grep -v "^$" | sort

Úskalí 4: Citlivá data v porovnání

Při sdílení výsledků porovnání (např. v pull requestu):

NIKDY neposílejte:

  • API klíče
  • Hesla
  • Connection strings s credentials

Bezpečná alternativa:

# Porovnejte pouze názvy proměnných
diff <(cut -d= -f1 .env.dev | sort) <(cut -d= -f1 .env.prod | sort)

Automatizace: Skript pro komplexní kontrolu

Zde je kompletní skript pro kontrolu .env souborů:

#!/bin/bash
# env-diff.sh - Komplexní kontrola .env souborů

set -e

# Barvy pro výstup
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

# Výchozí soubory
FILE1="${1:-.env.development}"
FILE2="${2:-.env.production}"
EXAMPLE="${3:-.env.example}"

echo "================================================"
echo "Porovnání: $FILE1 vs $FILE2"
echo "================================================"

# Funkce pro extrakci klíčů
get_keys() {
    grep -v "^#" "$1" 2>/dev/null | grep -v "^$" | cut -d= -f1 | sort
}

KEYS1=$(get_keys "$FILE1")
KEYS2=$(get_keys "$FILE2")

# 1. Klíče pouze v prvním souboru
echo -e "\n${YELLOW}[1] Proměnné pouze v $FILE1:${NC}"
ONLY_IN_1=$(comm -23 <(echo "$KEYS1") <(echo "$KEYS2"))
if [ -z "$ONLY_IN_1" ]; then
    echo -e "${GREEN}  Žádné${NC}"
else
    echo -e "${RED}$ONLY_IN_1${NC}" | sed 's/^/  /'
fi

# 2. Klíče pouze v druhém souboru
echo -e "\n${YELLOW}[2] Proměnné pouze v $FILE2:${NC}"
ONLY_IN_2=$(comm -13 <(echo "$KEYS1") <(echo "$KEYS2"))
if [ -z "$ONLY_IN_2" ]; then
    echo -e "${GREEN}  Žádné${NC}"
else
    echo -e "${RED}$ONLY_IN_2${NC}" | sed 's/^/  /'
fi

# 3. Kontrola proti .env.example
if [ -f "$EXAMPLE" ]; then
    echo -e "\n${YELLOW}[3] Kontrola proti $EXAMPLE:${NC}"
    EXAMPLE_KEYS=$(get_keys "$EXAMPLE")

    MISSING_FROM_1=$(comm -23 <(echo "$EXAMPLE_KEYS") <(echo "$KEYS1"))
    MISSING_FROM_2=$(comm -23 <(echo "$EXAMPLE_KEYS") <(echo "$KEYS2"))

    if [ -n "$MISSING_FROM_1" ]; then
        echo -e "${RED}  Chybí v $FILE1:${NC}"
        echo "$MISSING_FROM_1" | sed 's/^/    /'
    fi

    if [ -n "$MISSING_FROM_2" ]; then
        echo -e "${RED}  Chybí v $FILE2:${NC}"
        echo "$MISSING_FROM_2" | sed 's/^/    /'
    fi

    if [ -z "$MISSING_FROM_1" ] && [ -z "$MISSING_FROM_2" ]; then
        echo -e "${GREEN}  Všechny proměnné jsou přítomny${NC}"
    fi
fi

# 4. Souhrn
echo -e "\n================================================"
TOTAL_1=$(echo "$KEYS1" | wc -l | tr -d ' ')
TOTAL_2=$(echo "$KEYS2" | wc -l | tr -d ' ')
echo "Celkem proměnných: $FILE1=$TOTAL_1, $FILE2=$TOTAL_2"
echo "================================================"

Integrace do vývojového workflow

Pre-commit hook

Přidejte automatickou kontrolu před každým commitem:

#!/bin/bash
# .git/hooks/pre-commit

# Kontrola, že .env není commitován
if git diff --cached --name-only | grep -q "^\.env$"; then
    echo "CHYBA: Pokoušíte se commitnout .env soubor!"
    echo "Odstraňte ho ze stage: git reset HEAD .env"
    exit 1
fi

# Kontrola, že .env.example je aktuální
if [ -f ".env.example" ] && [ -f ".env" ]; then
    EXAMPLE_KEYS=$(cut -d= -f1 .env.example | grep -v "^#" | sort)
    ENV_KEYS=$(cut -d= -f1 .env | grep -v "^#" | sort)

    NEW_KEYS=$(comm -13 <(echo "$EXAMPLE_KEYS") <(echo "$ENV_KEYS"))
    if [ -n "$NEW_KEYS" ]; then
        echo "VAROVÁNÍ: Tyto proměnné nejsou v .env.example:"
        echo "$NEW_KEYS"
        echo "Přidejte je do .env.example"
    fi
fi

Docker Compose validace

Pro projekty s Dockerem:

# docker-compose.yml
services:
  app:
    build: .
    env_file:
      - .env
    environment:
      # Vynucené proměnné - musí být definovány
      - DATABASE_URL
      - REDIS_URL
      - APP_ENV

Závěr

Správné porovnávání .env souborů mezi prostředími je základem stabilního a bezpečného vývoje. Klíčové body:

1. Pravidelně porovnávejte – Ideálně automaticky v CI/CD pipeline

2. Používejte .env.example – Jako dokumentaci a referenci pro všechny proměnné

3. Automatizujte kontroly – Pre-commit hooky a CI pipeline zabrání chybám

4. Chraňte citlivá data – Nikdy nesdílejte skutečné hodnoty, pouze názvy proměnných

5. Validujte při startu – Aplikace by měla selhat rychle, pokud chybí kritická konfigurace


Potřebujete rychle porovnat .env soubory? Vyzkoušejte PorovnejText.cz – stačí vložit obsah obou souborů a okamžitě uvidíte rozdíly. Vše probíhá ve vašem prohlížeči, vaše konfigurace zůstává v bezpečí.

Vyzkoušejte PorovnejText.cz zdarma

Nejrychlejší český nástroj pro porovnání textů. Vše probíhá ve vašem prohlížeči, žádná registrace není potřeba.

Porovnat texty nyní →