Blog
PLEN

GitHub Actions vs cron — kiedy co dla automatyzacji w 2026

GitHub Actions świetne dla CI/CD i public repos, lokalny cron dla wszystkiego co dotyka twojej infrastruktury. Pokazuję regułę i konkretne przypadki kiedy które wybrać.

·4 min read
#devops#automation#github-actions#cron
GitHub Actions vs cron — kiedy co dla automatyzacji w 2026

GitHub Actions to standard dla CI/CD. Cron działa od 50 lat. Po latach używania obu mam jasną regułę kiedy które wybierać. Pokazuję na konkretach z mojego setupu, niektóre rzeczy w GHA, niektóre w cronie, każde z konkretnym powodem.

Krótka reguła

GHA gdy: build/test publicznego artefaktu, public repo, masz audytowalny log, chcesz visibility.
Cron gdy: dotykasz lokalnej infry, sekretów, prywatnych danych, chcesz < 1s startup.

Co mam w GitHub Actions

1. Build + test portfolio przy każdym PR

# .github/workflows/ci.yml
name: CI
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - run: npm test

Standard. Czas: ~3 min. Visible na PR jako check. Worth it bo każdy PR widzi rezultat.

2. Auto-deploy demo do staging przy push to staging branch

on:
  push:
    branches: [staging]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          ssh kkaletka@$STAGING_HOST "cd /home/kkaletka/portfolio-staging && \
            git pull && docker compose up -d --build"

GHA odpala SSH do mojego mini PC. Mam tam SSH key zarejestrowany z GHA secrets. Każdy push do staging = rebuild za 30 sekund.

3. Weekly dependency audit dla open source repo

.github/workflows/audit.yml z cron: '0 0 * * 0' (niedziela 00:00 UTC). npm audit --json → output do issue na GitHubie jeśli HIGH/CRITICAL.

Public visibility. Inni contributorzy widzą.

Co mam w cronie (mini PC)

1. Blog publisher (codziennie 9:00)

0 9 * * * /home/kkaletka/kamilkaletka-portfolio/scripts/publish-due-drafts.sh

Ten skrypt rebuild'uje Docker container'a z portfolio. Wymaga lokalnego dostępu do docker compose. GHA by tu nie zadziałało (nie ma dostępu do mojego Docker daemon).

2. Backup status (co godzinę)

0 * * * * /home/kkaletka/docker/scripts/backup-check.sh

Sprawdza wiek snapshotów Proxmox. Lokalna ścieżka, lokalny Telegram token. GHA ma 1-min minimum granularity i koszt, overkill.

3. AEGIS audit (co 5 minut)

*/5 * * * * /home/kkaletka/docker/scripts/aegis-watch.sh

Network watchdog. Sprawdza czy Cloudflare tunnel żyje, czy kontenery odpowiadają, czy DNS działa. GHA by kosztowało $$$ przy 12 runach na godzinę.

4. Morning briefing claudeclaw (8:00)

Cron w ~/.openclaw/cron/jobs.json. Odpala Claude Code agent z prompt'em. Agent ma dostęp do moich MCP, hostów, sekretów. GHA nie ma tego.

Reguła decyzyjna w pytaniach

Sześć pytań które sobie zadaję:

1. Czy operacja dotyka infry lokalnej (Docker, Proxmox, sekrety)?

  • Tak → cron
  • Nie → przejdź dalej

2. Czy to public repo gdzie chcę visibility check'a?

  • Tak → GHA
  • Nie → przejdź dalej

3. Czy potrzebuję cadencji częściej niż co minutę?

  • Tak → cron (GHA min granularity = 1 min, real lag ~30s)
  • Nie → przejdź dalej

4. Czy run trwa > 30 minut?

  • Tak → cron (GHA free ma 6h cap, paid ma billed minutes)
  • Nie → przejdź dalej

5. Czy rezultat ma być audytowalny przez team/innych?

  • Tak → GHA (logi, runs, badges)
  • Nie → cron

6. Czy potrzebuję triggera od commit'a?

  • Tak → GHA (push/PR triggers natywnie)
  • Nie → cron

W praktyce większość moich automatyzacji odpowiada "infra/local" w pytaniu 1, idą do crona. Public CI/CD ląduje w GHA.

Hybrydowy pattern

Czasem chcę GHA jako trigger + cron jako worker:

[Push to main on GitHub]
    ↓
[GHA workflow: send webhook to mini PC]
    ↓
[mini PC: receive, fire local script]
    ↓
[Docker rebuild lokalnie]

Webhook listener to ~30 linii Pythona z aiohttp. Gives me GHA visibility + local infra access.

Anti-patterns

1. Self-hosted GHA runner na mini PC. Dał mi to "lokalność z GHA UI", ale w praktyce: GHA agent updates ciągle przerywają, runner jest mniej stabilny niż cron, i tak musisz mieć infra do utrzymania.

2. Cron z 30+ wpisami. Hard do utrzymania. Jak masz 30+, przejdź na systemd timery. Bardziej deklaratywne, lepsze logi.

3. GHA dla heavy ML/data work. Free tier ma 6h limit + paid mode jest drogi przy GPU runners. Lepiej własna VM.

Mój split

Aktualnie:

  • GHA: 4 workflowy (CI, staging deploy, audit, release)
  • crontab: 11 wpisów
  • claudeclaw cron: 7 jobów (większość disabled bo OAuth issues)
  • systemd timers: 2

GHA to mniejszość liczbowa, ale obsługuje 100% public-facing workflow. Cron to większość, obsługuje 100% prywatnej infry.

Wybór GHA vs cron to nie kwestia mody. To kwestia tego gdzie żyje praca i kto ma widzieć rezultat. Reguła w sześciu pytaniach skraca decyzję do 30 sekund. Hybrydowy pattern (webhook GHA → local) daje to co najlepsze z obu światów.