n8n czy własny skrypt bash — kiedy workflow tool to overkill

Mam u siebie n8n i ~30 skryptów bashowych w ~/docker/scripts/. Niektóre rzeczy zostawiam w n8n, inne celowo trzymam jako bash. Pokazuję regułę którą stosuję i konkretne przykłady każdego podejścia.

Reguła w jednej linii

n8n gdy są human-readable kroki, integracje z 3 lub więcej zewnętrznymi serwisami i ktoś inny może to edytować. Bash gdy mam mniej, czas mi się liczy, i sam jestem właścicielem.

W praktyce: w n8n leci ~5 workflow, w bash ~30 skryptów. Stosunek mówi wszystko.

Co w n8n: 3 przykłady

1. Cold outreach pipeline

Workflow który dla każdego nowego leada w bazie:

1. Pobiera dane firmy (Google Places API)
2. Generuje brand brief (LLM call)
3. Tworzy stronę demo (HTTP do mojego skryptu deploy'owego)
4. Wysyła email z linkiem (Gmail API)
5. Loguje do Vikunja jako task

5 zewnętrznych systemów, każdy z różnym auth. n8n daje gotowe credential storage, retry logic, wizualizację flow. Bash by tu gnił od ifów na fail-handling.

2. Lead capture z formularza

Webhook → walidacja → zapis do bazy → email powitalny → notyfikacja na Telegram. Również 4 zewnętrzne integracje. n8n.

3. Prototypowanie nowych workflow

Gdy nie wiem czy dany flow ma sens, prototypuję w n8n. Łatwo dodaję kroki, łatwo testuję. Jak workflow się ustabilizuje i będzie tylko 1-2 integracje, czasem przepisuję na bash.

Co w bash: 3 przykłady

1. Backup status check

#!/usr/bin/env bash
# /home/kkaletka/docker/scripts/backup-check.sh
LATEST=$(ls -t /backups/proxmox/ | head -1)
AGE_HOURS=$(( ($(date +%s) - $(stat -c %Y "/backups/proxmox/$LATEST")) / 3600 ))
 
if (( AGE_HOURS > 26 )); then
  curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
    -d "chat_id=${CHAT}" \
    -d "text=⚠️ Backup ostatni $AGE_HOURS h temu"
fi

15 linijek, jedna zmienna do zmiany jak coś się przesunie. n8n by tu robił JSON-y i webhook'i, overkill.

2. Trading dashboard alert

Cron co minutę. SQL query, parse wyniku, jeśli próg PnL przekroczony, Telegram. 30 linii bash + sqlite3 CLI.

W n8n by trzeba było: trigger node (Cron), DB node (PostgreSQL), filter node, Telegram node. Każdy z konfiguracją. Bash robi to w jednym pliku.

3. Deploy demo strony

#!/usr/bin/env bash
# scripts/deploy-demo.sh
slug=$1
ssh forge "cd /home/kkaletka/demo-${slug} && docker compose up -d --build"

To jest cała robota. n8n by potrzebował SSH execute node, error handling. Bash w 4 linijkach.

Co kosztuje n8n

Konkretne minusy:

1. Pamięć. Mój n8n container chodzi na ~512MB RAM. Bash zużywa 0 (kończy się natychmiast).

2. Wersjonowanie. Workflow są zapisane jako JSON w n8n DB. Eksport-import działa, ale code review jest słaby. Bash w git = full diff.

3. Czas startu nowego workflow. Prosty bash piszę w 5 minut. Workflow w n8n, 15-20 (klikanie, łączenie nodes, testowanie).

Co kosztuje bash

Też nie jest darmowe:

1. Brak retry/error handling out-of-box. Musisz pisać set -e, trap, retry-with-backoff ręcznie.

2. Brak GUI dla nie-technicznych. Jak chcesz dać innej osobie do edycji, n8n wygrywa.

3. Słabsza integracja z OAuth services. n8n ma gotowe nody dla Gmail/Slack/etc. Bash potrzebuje pełnej obsługi token refresh sam.

Reguła decyzyjna

Pytania które sobie zadaję:

1. Ile zewnętrznych integracji? ≤ 2 → bash. ≥ 3 → rozważ n8n.
2. Czy workflow ma się zmieniać? Często → n8n. Stabilny → bash.
3. Kto będzie utrzymywał? Tylko ja → bash. Też ktoś inny → n8n.
4. Czy potrzebuję webhook listener? Bash może (z nc albo dedicated server), ale n8n robi to natywnie.

Większość moich automatyzacji to "1 integracja, ja-utrzymuję, stable" → bash. Mniejszość to "wiele systemów, ewolucja, czasem ktoś inny patrzy" → n8n.

n8n nie jest "lepszy" ani "gorszy" od basha. Są dwoma różnymi narzędziami do dwóch różnych klas zadań. Wybieraj świadomie, nie z mody na visual workflows.