GitHub je super vecička, ale pri WordPresse sa dlho používal skôr ako záloha než ako reálny zdroj deploymentu. V tomto článku ukážem workflow, ktorý dnes používam pri klientských WordPress weboch: GitHub, Docker Compose, Coolify, WP-CLI a Claude Code.

Cieľ je jednoduchý: neupravovať produkciu cez FTP, nemať zmeny rozhádzané po serveri a nenechať AI agenta klikať naslepo. Všetko ide cez repozitár, commit, push a kontrolovaný deploy.

Prečo mi klasický WordPress workflow nestačil

Keď som v minulosti robil zmeny vo WordPress témach alebo pluginoch, problém bol v tom, ako ich bezpečne ukladať a nasadzovať. Dalo sa pracovať cez FTP, prípadne cez editor alebo sync z VS Code, ale GitHub bol často iba ďalšia kópia kódu.

To nie je ideálne. Ak sa niečo pokazí, ťažko sa hľadá, ktorá verzia je správna. Ak na webe pracuje viac ľudí, vzniká riziko prepísania zmien. A ak do workflowu zapojím Claude Code, chcem, aby robil zmeny v repozitári, nie priamo na produkcii.

GitHub ako zdroj deploymentu, nie iba záloha

Najväčší rozdiel je v tom, že GitHub používam ako source pre deploy. Keď sa zmena pushne na main, Coolify ju zoberie a nasadí nový build.

  • každá zmena má commit,
  • viem sa vrátiť v histórii,
  • deployment je naviazaný na konkrétnu verziu kódu,
  • Claude Code pracuje s lokálnym repozitárom,
  • produkcia sa nemení ručne cez FTP.

Toto je pre mňa zásadný posun. WordPress sa začne správať viac ako normálna aplikácia a menej ako server, do ktorého sa ručne kopírujú súbory.

Prečo to nie je workflow pre zdieľaný hosting

Toto celé dáva zmysel hlavne na VPS. Na bežnom zdieľanom hostingu typu lacný PHP hosting väčšinou nemáte Docker, nemáte normálny deployment proces a často nemáte ani WP-CLI v podobe, ktorú vie AI agent rozumne používať.

VPS je lacné, rýchle a dáva kontrolu. Nevýhoda je, že sa oň treba starať. Ja VPS beriem primárne ako miesto na weby, aplikácie a služby. E-maily by som na ňom neriešil, pretože doručiteľnosť je vlastná disciplína a nový mail server veľmi ľahko skončí v spame.

Docker Compose a persistent storage

Základ projektu je docker-compose.yml. V ňom sú služby ako WordPress, databáza, WP-CLI, prípadne Node, phpMyAdmin alebo Mailpit na testovanie mailov.

Dôležité je nastaviť persistent storage. Pri novom deployi sa WordPress kontajner môže prestavať a ak si nedáte pozor, prepíše súbory, ktoré chcete zachovať.

  • plugins musia prežiť deploy,
  • uploads musia prežiť deploy,
  • languages musia prežiť deploy,
  • ďalšie projektové dáta treba riešiť podľa konkrétnej štruktúry.

Toto je jedna z vecí, ktorú netreba podceniť. Automatizovaný deploy je super, ale len vtedy, keď neprepíše dáta, ktoré majú zostať perzistentné.

Coolify ako deploy z GitHubu

V Coolify mám aplikáciu nastavenú tak, že používa Docker Compose build pack. Coolify pozná lokáciu compose súboru, vie pracovať s persistent storage a pri commite do hlavnej vetvy spraví nový deploy.

Prakticky to znamená, že keď upravím napríklad footer, logá alebo linky, Claude Code spraví zmenu v repozitári, commitne ju, pushne na GitHub a Coolify nasadí novú verziu.

Dôležité pravidlo: neupravujem priamo súbory na serveri. Vždy idem cez GitHub, aby zostala história zmien.

Claude Code, Coolify API a kontrola deploymentu

Coolify vie vygenerovať API token. Keď ho bezpečne dáte Claude Code, agent vie pozerať stav deploymentov, kontrolovať, či deploy prešiel, a v niektorých prípadoch aj pripravovať alebo konfigurovať aplikácie.

Môj ideálny flow je:

  1. Claude Code upraví kód lokálne v repozitári.
  2. Skontroluje súvisiace súbory.
  3. Spraví commit a push.
  4. Coolify spustí deployment.
  5. Claude Code skontroluje stav deployu.
  6. Až potom sa pozerám na výsledok na stránke.

Takto má AI agent veľkú silu, ale stále pracuje cez proces, ktorý je dohľadateľný.

WP-CLI je kľúč k tomu, aby AI vedela robiť viac

Samotná úprava súborov je len polovica príbehu. Ak má projekt WP-CLI, Claude Code vie s WordPressom pracovať aj cez command line. Vie vytvárať obsah, meniť menu, pracovať s databázou, importovať články alebo vkladať Gutenberg bloky.

Na jednom projekte mi takto pomáhal migrovať približne 2000 článkov z predchádzajúcich webov do nového WordPressu. Toto by bolo ručne extrémne otravné. Cez WP-CLI a kontrolovaný skript je to oveľa lepšie.

Gutenberg bloky bez manuálneho klikania

Primárne používam Gutenberg, pretože s blokmi vie AI agent dobre pracovať. Vie vytvoriť nový blok, vložiť ho na stránku, upraviť obsah a cez WP-CLI alebo databázovú vrstvu spraviť aj väčšie zmeny.

Samozrejme, nie všetko vyjde na prvýkrát. Aj v mojom demo projekte sa objavil bug s kategóriami. To je normálne. Rozdiel je v tom, že chyba sa dá opraviť ďalším commitom a stále viem, čo sa stalo.

Pre koho tento workflow odporúčam

Tento setup dáva zmysel, ak robíte WordPress weby opakovane, máte vlastné témy alebo bloky a chcete menej ručného deployovania. Pre jednorazový jednoduchý web môže byť zbytočný. Pre klientské weby, ktoré treba dlhodobo spravovať, je to však veľmi dobrý základ.

Najväčšia výhoda nie je v jednom konkrétnom nástroji. Výhoda je v tom, že WordPress dostane normálny vývojársky proces: Git, deploy, kontrolu zmien, WP-CLI a možnosť zapojiť AI bez toho, aby robila chaos na produkcii.