Zmienne środowiskowe

Zmienne środowiskowe to pary nazwa-wartość ustawiane poza kodem aplikacji. Kod odwołuje się do nich przez nazwy, np. `SANITY_API_TOKEN`, `DATABASE_URL` albo `RESEND_API_KEY`, ale sama wartość nie musi leżeć w repozytorium. Dzięki temu możesz mieć inny token lokalnie, inny na Vercelu, inny w n8n i inny w środowisku testowym.

Najważniejsza zasada brzmi: sekrety nie powinny być wpisane na stałe w kod. Klucz API wrzucony do repozytorium może zostać skopiowany, użyty do generowania kosztów albo dać komuś dostęp do danych klientów. Plik `.env` jest wygodny lokalnie, ale powinien być w `.gitignore`. Na produkcji zmienne ustawiasz w panelu hostingu, CI/CD albo narzędziu do sekretów.

Dla soloprzedsiębiorcy zmienne środowiskowe są ważne, bo coraz więcej pracy opiera się na integracjach: OpenAI, Claude, Sanity, Supabase, Kit, Resend, Cal.com, n8n, Stripe. Jeśli trzymasz klucze w promptach, notatkach, screenach albo kodzie, budujesz system na piasku. Jeśli trzymasz je w env vars, możesz bezpieczniej podłączać automatyzacje i zmieniać konfigurację bez grzebania w aplikacji.

Praktyczny przykład: formularz newslettera na stronie używa endpointu API, a endpoint potrzebuje tokenu Kit. Frontend nie powinien widzieć tego tokenu. Użytkownik wpisuje email, strona wysyła request do serwera, a serwer odczytuje `KIT_API_KEY` ze zmiennych środowiskowych i dopiero wtedy rozmawia z Kit.

Najczęstsze błędy: commitowanie `.env`, używanie sekretów po stronie przeglądarki, wysyłanie kluczy AI w promptach do obcych narzędzi, brak rotacji po wycieku i jeden wspólny token do wszystkiego. Dobra praktyka: minimalne uprawnienia, osobne klucze dla środowisk, opisane nazwy zmiennych i szybka rotacja, gdy coś wycieknie.