rsync deploy tiše přepíše serverový .env starým lokálním

import { Aside } from ‘@astrojs/starlight/components’;

Do každého rsync deploy příkazu patří `--exclude '.env*'`. Serverový .env po každé změně zálohuj mimo deploy adresář.

Symptom

Na server byl přes API/SSH přidán nový secret do .env (funkčně ověřeno). O pár minut později stejný endpoint vrací „Unauthorized / chybí konfigurace” — proměnná v .env není. stat souboru ukazuje měsíce staré datum: soubor je identický s lokální dev kopií.

Zákeřné je zpoždění projevu: běžící proces (PM2/Node) drží env z doby startu, takže aplikace funguje dál i s přepsaným .env — rozbije se až při příštím restartu, klidně o dny později, kdy už nikdo deploy s incidentem nespojí.

Root cause

Deploy skript kopíruje celý projekt:

# ŠPATNĚ — přenese i lokální .env a přepíše serverový
rsync -az --exclude 'node_modules' --exclude '.next' --exclude '.git' ./ server:/app/

Lokální vývojová kopie .env (stará, bez produkčních klíčů) při každém deployi tiše přepsala serverový .env se všemi doplněnými secrets. rsync nic nehlásí — z jeho pohledu jde o běžný změněný soubor.

Fix

# SPRÁVNĚ
rsync -az --exclude 'node_modules' --exclude '.next' --exclude '.git' \
  --exclude '.env*' ./ server:/app/

Obnova: ztracené hodnoty doplnit zpět do serverového .env, restartovat proces, ověřit funkčnost endpointu závislého na secretu. Pokud starý proces ještě běží, hodnoty lze vytáhnout z /proc/<pid>/environ — po restartu už ne.

Prevence

1. --exclude '.env*' v každém rsync deploy příkazu (a v deploy dokumentaci projektu).
2. Záloha serverového .env mimo deploy adresář po každé změně: cp .env /root/<app>-env-backup-$(date +%Y%m%d) && chmod 600 ….
3. Po deployi smoke-test endpointu, který secrets reálně používá — ne jen HTTP 200 homepage (ta jede i s rozbitým env do restartu).