## Mój stack DevOps w 2026 roku

opublikowano 1 mar 2026 ~ 5 min czytania tagi: #devops#docker#kubernetes#cloudflare

Kontekst

Jestem inżynierem DevOps w movecloser - polskim software house’ie, gdzie buduję i utrzymuję infrastrukturę dla projektów klientów. Równocześnie prowadzę własne projekty open-source (donata, starlight-auth, ta strona) i infrastrukturę Flightcore Studios. Mój stack musi działać na dwóch poziomach: enterprise (movecloser) i personal (własne serwery, domowe laby).

Ten artykuł to przegląd narzędzi, których faktycznie używam w 2026 roku - nie lista „fajnych technologii z Hacker News”, lecz zestaw, który przetrwał selekcję naturalną codziennego użytkowania.

Konteneryzacja - Docker wszędzie

Docker to fundament. Każdy projekt, który tworzę lub utrzymuję, startuje od Dockerfile. Nie dlatego, że to modne - dlatego, że eliminuje klasę problemów, które kiedyś zjadały godziny: „u mnie działa”, rozbieżności wersji, brudne środowiska deweloperskie.

Multi-stage builds

Standardem jest multi-stage - osobny etap budowania z pełnym toolchainem, osobny runtime z minimalnym obrazem. Dla aplikacji Node.js to różnica między obrazem 1.2 GB a 180 MB.

# Etap budowania
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build

# Etap produkcyjny
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
CMD ["node", "dist/index.js"]

Docker Compose do developmentu

Dla lokalnego developmentu - docker-compose.yml z pełnym stackiem: baza danych, cache, aplikacja, reverse proxy. Jedno docker compose up i środowisko jest identyczne jak produkcja. W movecloser każdy projekt ma swój compose z predefiniowanymi seedami i migracjami.

Orkiestracja - Kubernetes tam, gdzie ma sens

Kubernetes nie jest odpowiedzią na każde pytanie. Dla moich osobistych projektów - VPS z Docker Compose wystarcza. Ale w movecloser, gdzie zarządzamy kilkunastoma usługami z różnymi cyklami wdrożeń, wymaganiami skalowania i SLA - Kubernetes rozwiązuje realne problemy.

Co K8s robi dobrze

Rolling updates - zero-downtime deploys z automatycznym rollbackiem. Jeden zły build nie kładzie produkcji.
Resource limits - izolacja zasobów między usługami. Jeden memory leak nie zabija pozostałych serwisów.
Secrets management - integracja z external secrets operator, rotacja bez restartów.

Czego unikam

Overengineering - Helm charts z setkami parametrów dla prostej aplikacji CRUD. Zwykły zestaw manifestów YAML jest czytelniejszy i łatwiejszy w debugowaniu.
K8s na siłę - osobiste projekty (donata, szymongwozdz.pl) działają na zwykłym Docker Compose za Cloudflare Tunnel. Nie potrzebują auto-scalingu ani service mesh.

Infrastructure as Code - Terraform

Terraform zarządza infrastrukturą chmurową - zasoby AWS/GCP, rekordy DNS w Cloudflare, klastry K8s. Kluczowa zasada: jeśli mogę kliknąć coś w konsoli, mogę to opisać w HCL.

State management

Remote state w S3 z lockiem w DynamoDB. Każdy zespół w movecloser ma osobny workspace. W osobistych projektach - Terraform Cloud na darmowym planie, bo utrzymywanie własnego backendu state’u dla trzech projektów to przesada.

# Typowy workflow
terraform plan -out=tfplan
# review planu
terraform apply tfplan

Modularyzacja

Własne moduły na powtarzalne wzorce - VPC z predefiniowaną topologią, kluster EKS z sensownymi domyślnymi ustawieniami, bucket S3 z politykami retencji. Moduły wersjonowane w osobnym repo, referencja przez tagi gitowe.

CI/CD - GitHub Actions

Po eksperymentach z GitLab CI, Jenkins i CircleCI - GitHub Actions wygrało przez integrację z ekosystemem, w którym już żyję. Repozytoria na GitHubie, code review w PR-ach, workflow obok kodu.

Wzorce, które się sprawdzają

Reusable workflows - wspólne pipeline’y (build → test → deploy) jako osobne workflow, wywoływane z repozytoriów projektowych. Zmiana w jednym miejscu propaguje się wszędzie.
Environment protection rules - deploy na produkcję wymaga approval. Automatyczny deploy na staging przy każdym merge do main.
Cache agresywnie - Docker layer cache, dependency cache, build artifacts. Różnica między 12 minut a 3 minuty na pipeline.

# Fragment workflow z cache
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: ${{ runner.os }}-npm-

Edge i CDN - Cloudflare

Cloudflare to moje domyślne rozwiązanie na edge - DNS, CDN, WAF, Tunnel, Workers. Ta strona (szymongwozdz.pl) serwowana jest statycznie z Cloudflare Pages - zero serwera do utrzymania, automatyczny deploy z GitHub, SSL bez konfiguracji.

Cloudflare Tunnel

Dla usług, które muszą być dostępne publicznie, ale działają na prywatnym serwerze - Tunnel zamiast otwierania portów. Donata, mój self-hosted system donacji dla streamerów, działa dokładnie tak: Docker Compose na VPS, Cloudflare Tunnel jako jedyny punkt wejścia. Żadnych publicznych IP, żadnych otwartych portów, żadnego stress-testu na firewallu.

Workers i KV

Lekkie funkcje edge - przekierowania, A/B testing, walidacja tokenów. Dla Flightcore Studios website używam Workers do obsługi formularzy kontaktowych bez backend serwera.

Co się zmieniło w ostatnich latach

Porzuciłem Ansible na rzecz konteneryzacji. Konfiguracja serwera to teraz Dockerfile + compose, nie playbook z setką tasków.
Mniej AWS, więcej Cloudflare - dla osobistych projektów. AWS to potężne narzędzie, ale pricing model wymaga dedykowanego księgowego.
Monitoring uproszczony - z Prometheus + Grafana + AlertManager na uptime-kuma + logi w stdout. Dla małych projektów pełny stack observability to overhead, który nie zwraca się.
PostgreSQL jako domyślna baza - po latach eksperymentów z MongoDB, Redis jako primary store, SQLite - PostgreSQL rozwiązuje 95% problemów i nie zaskakuje.

Podsumowanie

Mój stack w 2026 roku to: Docker do pakowania, Kubernetes do orkiestracji (gdzie ma sens), Terraform do zarządzania infrastrukturą, GitHub Actions do CI/CD, Cloudflare na edge. Nie jest idealny, ale jest przetestowany - każde z tych narzędzi używam codziennie od co najmniej dwóch lat.

Najważniejsza lekcja? Dobry stack to taki, który znasz na tyle dobrze, żeby debugować go o trzeciej w nocy. Nie ten, który ma najwięcej gwiazdek na GitHubie.