Ak ste si už stihli prejsť úvod do možností Raspberry Pi a výber vhodného hardvéru, aj inštaláciu, základnú konfiguráciu a prvé kroky v Linuxe, je najvyšší čas posunúť si latku o úroveň vyššie. V záverečnej časti nášho seriálu sa pustíme do webového vývoja už na ostro. Predstavíme si konkrétne tipy a postupy, ako premeniť Raspberry Pi na spoľahlivý, bezpečný a ľahko udržiavateľný webový server.
Ako dostať našu službu na web
Pri nasadzovaní aplikácie do produkcie narazíte na množstvo otázok a rozhodnutí, ktorých odpovede sa budú líšiť podľa konkrétneho projektu, použitej technológie aj cieľov. Ide o tému, ktorá je príliš rozsiahla na detailné pokrytie vo forme článku. Tento článok tak berte skôr ako prehľad kľúčových oblastí, na rýchle zorientovanie sa pred ďalším samoštúdiom a experimentovaním. Pozrieme sa na témy ako napríklad:
- Ako dostať aplikáciu na zariadenie?
- Ako zabezpečiť nepretržitý chod aplikácie?
- Ako vystaviť aplikáciu na verejnú sieť?
- Ako automatizovať build-deploy procesy (CI/CD)?
- Ako monitorovať stav aplikácie?
- Na čo si dať pozor z hľadiska bezpečnosti?
Jedna poznámka: v nasledujúcich častiach sa pozrieme na celý proces primárne z pohľadu hostovania backendovej služby. Pri hostovaní statických stránok a SPA aplikácií renderovaných na strane klienta časť komplexity odpadá. Server v takom prípade totiž len posiela už hotové dokumenty a assety na vyžiadanie, bez potreby ďalšieho spracovania na serveri.

Ako dostať aplikáciu na zariadenie?
Keď už máme vytvorenú webovú aplikáciou, prvou výzvou je dostať ju na Raspberry Pi. Najjednoduchšie je spoliehať sa na Git. Na zariadení si naklonujete repozitár, nainštalujete závislosti, skompilujete kód a spustíte aplikáciu—presne ako pri vývoji. Ide o jednoduchý spôsob, ktorý ale má svoje obmedzenia. A to najmä pri náročnejších alebo komplikovanejších projektoch, kde môže byť potrebné nastaviť zložitejšie závislosti alebo garantovať rovnakosť prostredí medzi vývojom a produkciou.
Ak potrebujete robustnejšie riešenie alebo chcete zabezpečiť, aby aplikácia bežala v izolovanom a presne definovanom prostredí, ideálnym spôsobom nasadenia sú Docker kontajnery. Docker vám umožní zabaliť aplikáciu spolu so všetkými jej závislosťami do jedného image. Ten potom spustíte kdekoľvek, kde beží Docker. Základom je pripraviť súbor Dockerfile
, ktorý je akýmsi receptom na zloženie image. Na ukážku pripájam príklad pre jednoduchú Node.js aplikáciu (postavenú na oficiálnom node:18
základe):

Hotový image následne uploadnete do kontajnerového registra, napríklad na Docker Hub alebo GitHub Container Registry (ten je omnoho štedrejší v bezplatnej verzii):
docker login
docker build -t /: .
docker push /:
Na Raspberry Pi image stiahnete a spustíte jedným príkazom. Flag -p 8080:3000
slúži na sprístupnenie (namapovanie) portu mimo kontajner – služba tak bude dostupná na lokálnej adrese http://localhost:8080
:
docker run -d -p 8080:3000 /:
Pre zložitejšie aplikácie tvorené viacerými vrstvami (napr. webserver, databáza, lokálny súborový systém) je neoceniteľnou pomocou docker-compose.yml
, ktorý definuje všetky služby v projekte a ich vzájomné prepojenie:

Všetky časti následne naštartujete jedným príkazom:
docker compose up -d
Toto bola len jednoduchá ukážka, no ak si radi zjednodušujete život, Docker je oblasť na ktorú sa oplatí pozrieť.
Ako zabezpečiť nepretržitý chod aplikácie?
Akonáhle prechádzate z lokálneho vývojového prostredia do „ostrého“ nasadenia, akýkoľvek výpadok v prevádzke aplikácie sa stáva problémom. Pri nasadení na Raspberry Pi je preto kľúčové zabezpečiť automatický reštart vašej aplikácie pri neočakávaných pádoch alebo reštartoch zariadenia.
Jedným z najrozšírenejších a zároveň najjednoduchších riešení je nástroj systemd
, priamo zabudovaný do väčšiny Linuxových distribúcií (vrátane Raspberry Pi OS). Pomocou systemd
definujete jednoduchý servisný súbor, ktorý riadi životný cyklus aplikácie: spustenie po štarte systému, automatické obnovenie po páde, limitovanie spotreby zdrojov a jednoduchý prístup k logom. Základné nastavenie môže vyzerať napríklad takto:

Týmto krátkym konfiguračným súborom dosiahnete automatické spustenie pri štarte a reštartovanie aplikácie 5 sekúnd po každom páde. Aplikáciu následne povolíte a spustíte príkazmi:
sudo systemctl daemon-reload
sudo systemctl enable .service
sudo systemctl start .service
Výhodou systemd
je jednoduchá konfigurácia a nízky výkonový overhead, vďaka čomu je ideálny na nasadenie na menej výkonné zariadenia.
V prípade že vaša aplikácia beží vo forme Docker kontajneru, postup je ešte jednoduchší. Stačí doplniť príkaz na spustenie kontajnera o flag --restart unless-stopped
:
docker run -d --restart unless-stopped /:
Alebo doplníte riadok restart: unless-stopped
ku spúšťaným servisom v rámci vašej docker-compose.yml
konfigurácie. V oboch prípadoch máte istotu, že aplikácia pobeží spoľahlivo, s minimálnou potrebou manuálneho zásahu aj pri neočakávaných udalostiach.
Ako vystaviť aplikáciu na verejnú sieť?
V niektorých situáciách si vystačíte s aplikáciou dostupnou len v lokálnej sieti (napríklad pri automatizácii domácnosti). Ak však chcete, aby bola vaša služba prístupná zvonka, potrebujete sa popasovať s témami ako networking, DNS a bezpečnosť.
Tradične sa aplikácia sprístupňuje pomocou port forwardingu na routeri. Kým je Raspberry zariadenie súčasťou len vašej domácej siete, zvonku je „skryté“ za routerom. Port forwarding vám umožní presmerovanie portu z verejnej IP adresy routera na vnútornú IP vášho Raspberry Pi. V kombinácii s DynDNS službou (Dynamic DNS) navyše nemusíte riešiť, že váš poskytovateľ mení IP adresu každý deň – DynDNS automaticky mapuje dynamickú IP na fixnú doménu. Toto riešenie je však vhodné len pre ľudí, ktorí veľmi dobre vedia čo robia! Svoju domácu sieť ním vystavujete verejnému internetu, čo vytvára veľké bezpečnostné riziko, a navyše už nie každý provider umožňuje potrebné porty otvoriť bez ďalších bariér.
Jednoduchším, rýchlejším a bezpečnejším riešením (najmä pri menších projektoch), je spoľahnúť sa na riešenie tretej strany, napríklad na bezplatný Cloudflare Tunnel. Ide o reverzné proxy tunelovanie: aplikácia na vašom Pi si otvorí odchádzajúce spojenie na Cloudflare a práve cez tento spoj (a cez Cloudflare infraštruktúru) sa vaša služba bezpečne dostane na verejný internet. Nemusíte otvárať žiadne porty na routeri. Podmienkou je vlastníctvo domény (kľudne aj mimo Cloudflare), no tú budete potrebovať tak či onak, ak chcete aplikáciu vystaviť na seriózne vyzerajúcej adrese. A s Cloudflare Tunnel získate aj bonus navyše. Tunelovanie je šifrované, odolné voči bežným DDoS útokom a získavate zadarmo HTTPS certifikát. Týmto obchádzate množstvo bezpečnostných, sieťových aj právnych problémov a najmä, vaše zariadenie nie je „nahé“ na internete.

Potrebujem reverse proxy webový server? (Nginx, Apache)
Reverzná proxy je typ servera, ktorý prijíma požiadavky z internetu a preposiela ich do internej aplikácie. Ak vytvárame backendovú API službu, tá je sama o sebe HTTP serverom. Typicky beží na určitom porte (napr. 3000) a dokáže obsluhovať požiadavky priamo, bez potreby zapojenia samostatného sprostredkovateľa. Webové servery ako Nginx alebo Apache poskytujú cennú medzivrstvu, ktorá za nás rieši mnohé low-level záležitosti, ako je caching, rate-limiting, ochrana pred brute-force a DoS útokmi, základné logovanie, monitoring, HTTPS certifikáty a podobne. Je však možné, že tieto funkcie v menšom projekte nebudete potrebovať, alebo si ich implementujete sami v rámci backendovej aplikácie. Prípadne ich za vás vyrieši Cloudflare alebo iné externé služby.
Na druhú stranu, ak naším cieľom nie je poskytovať dynamickú API službu, ale len servovať statickú webstránku alebo single-page aplikáciu (SPA), vtedy nám úplne postačí Nginx / Apache, bez potreby samostatnej BE aplikácie. Ten dokáže efektívne a spoľahlivo servovať statické súbory priamo z disku (HTML, CSS, JS, obrázky). A aj v prípadoch keď už backendovú aplikáciu máme, väčšinou býva žiadúce servovať frontend ako samostatný nezávislý proces na inom porte (alebo dokonca na inom serveri). Zabezpečuje to lepšiu izoláciu medzi frontendom a backendom, zjednodušuje CI/CD, zvyšuje bezpečnosť a výkon, a umožňuje jednoduchšie škálovanie.
Ako automatizovať build-deploy procesy?
Každá manuálna operácia stojí drahocenný čas a zároveň zvyšuje riziko chyby. Čím viac narastá projekt na komplexite, tým jednoduchšie je pri jeho nasadzovaní na niečo zabudnúť. Riešením je CI/CD (Continuous Integration / Continuous Deployment)—systém v ktorom každý push do repozitára odštartuje sériu úloh (build, test, deploy) bez zásahu človeka. Pri menších projektoch si bohate vystačíte s GitHub Actions alebo GitLab CI/CD, kde v YAML workflow
súbore popíšete jednotlivé kroky procesu. Napríklad na automatizovaný deploy nového image po každom pushi do main
branche vieme využiť niečo takéto:

Na Raspberry zariadení si viete automatizovať natiahnutie aktuálneho image napríklad s nástrojom Watchtower. Stačí keď vašu docker-compose.yml
konfiguráciu rozšírite o nasledujúce:

Ak Docker nepoužívate, a chcete si nastaviť napríklad len automatickú aktualizáciu služby, na Raspberry zariadení si môžete vytvoriť jednoduchý script, napr. deploy.sh
, ktorý natiahne a spustí najnovšiu verziu aplikácie…

…ktorý potom môžete spúšťať napríklad pomocou CRON jobu (plánovanej, pravidelne sa opakujúcej úlohy) každú noc (v príklade nižšie každú noc o 3:00):
0 3 * * * /home///deploy.sh >> /home///deploy.log 2>&1
Alebo si môžete nakonfigurovať spúšťanie scriptu priamo z GitHub Actions pomocou SSH.
Ako monitorovať stav aplikácie?
Mať aplikáciu nasadenú je len polovica cesty. Druhá polovica je vedieť, čo sa v nej deje a ako sa správa v reálnom čase. Monitoring nie je len „nice to have“. Ide o základný predpoklad spoľahlivosti každej produkcie. Keď viete, čo sa v aplikácii a na serveri deje (alebo nedeje), môžete opraviť chybu skôr, než si ju niekto všimne.
Systémové logy
Ak aplikáciu spúšťate cez systemd, jej aktuálne logy zobrazíte príkazom journalctl -u <service-name.service> -f
, kde -u
(unit) vyberie konkrétnu službu podľa názvu a -f
(follow) zobrazí nové logy v reálnom čase. U dockerizovaných služieb vám podobný pohľad dá docker logs <container-name>
alebo ak používate docker compose
, všetko naraz uvidíte s docker compose logs -f
.
Tieto príkazy vám umožnia rýchlo sledovať štarty, chyby aj ďalšie udalosti aplikácie. Keď raz aplikácia beží, logy sa rýchlo stanú vaším najcennejším zdrojom informácií. Logy pravidelne sledujte, automatizujte ich čistenie a majte jasno v tom, kde a ako sa uchovávajú – chaos v logoch sa proti vám obráti práve vtedy, keď to najmenej potrebujete.
Automatizované sledovanie stavu / dostupnosti
Nejde však len o výpisy: často potrebujete včas zistiť, že niečo prestalo fungovať. Na jednoduchý alerting postačí UptimeRobot alebo self-hosted Uptime Kuma, ktoré v pravidelných intervaloch testujú, či sú web / API služby dostupné zvonku, a okamžite vás upozornia na výpadok cez e-mail, SMS alebo push notifikáciu.

Väčšina moderných backendových služieb ponúka vlastný endpoint typu /health
alebo /status
, ktorý testuje nielen dostupnosť, ale aj stav databázy, externých služieb či fronty na spracovanie úloh. Ak taký endpoint nemáte, pridajte si ho a nechajte monitorovaciu službu pravidelne kontrolovať práve tento bod. Získate tak rýchle varovanie nielen v prípade, že je server nedostupný, ale aj keď prestane korektne fungovať niektorá jeho kritická časť.
Pokročilé metriky a vizualizácie
Systémové logy a sledovanie dostupnosti sú úplným minimom. Komplexnejší prehľad o stave aplikácie získate až vďaka metrikám, ktoré odhalia napríklad vyťaženie CPU, RAM, rýchlosť odpovedí alebo stav závislostí cez vlastné /metrics
endpointy. Najčastejšie sa na to využíva Prometheus v kombinácii s Grafanou – tie spolu umožňujú zbierať a vizualizovať všetky dôležité údaje na jednom mieste. Sledovanie chýb a výnimiek v kóde vám zasa zjednoduší služba ako Sentry, ktorá zachytí podrobné informácie o každej chybe aj s kontextom, v ktorom nastala.

Zvážte však, koľko komplexity chcete na začiatku riešiť. Každá ďalšia vrstva znamená viac času na údržbu aj vyššie nároky na systém. Ak spúšťate malý projekt, kľudne začnite len so základnými logmi a jednoduchým monitoringom dostupnosti. Keď začne aplikácia rásť, monitoring rozšírite podľa potreby.
Na čo si dať pozor z hľadiska bezpečnosti?
Raspberry Pi je milé, drobné zariadenie, no v otázkach bezpečnosti platia tie isté pravidlá ako pri „dospelých“ serveroch: každé zariadenie prístupné z internetu je terčom na útok. Bez základnej bezpečnostnej hygieny si koledujete o problém.
- Dbajte na pravidelnú aplikáciu bezpečnostných záplat. S aktualizáciou systému vám na Raspberry Pi OS (alebo inom Debiane) pomôže balík
unattended-upgrades
, ktorý dokáže bezpečnostné aktualizácie aplikovať automaticky, bez vášho zásahu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
- Z času na čas aktualizujte aj veľké verzie balíkov a Raspberry firmware. Pred väčším upgradom si však radšej spravte zálohu dôležitých dát a konfigurácií – ak sa niečo pokazí, máte aspoň možnosť obnovy.
sudo apt update
sudo apt full-upgrade
sudo rpi-eeprom-update
sudo reboot
Na SSH vypnite prihlasovanie heslom a povoľte len prihlasovanie cez SSH kľúč. Vyhnite sa používaniu predvolených účtov (napr.
pi
) – ideálne ich premenujte, deaktivujte alebo vymažte. Po zmene SSH konfigurácie nezabudnite SSH reštartovať cezsudo systemctl restart ssh
.
# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
- Izolujte aplikácie od systému. Vaša aplikácia by nemala bežať pod root užívateľom. Nastavte ju tak, aby bežala ako menej privilegovaný užívateľ s obmedzenými právami. Ak používate Docker, aplikácia je čiastočne izolovaná už z princípu, no nezabudnite ani tam explicitne nastaviť bezpečné obmedzenia (user, capabilities, resource limity).
- Pravidelné zálohy sú vaša najlepšia poistka. Zálohujte pravidelne (napr. pomocou cron jobov) – databázy, konfiguračné súbory, certifikáty aj kód aplikácie. Zálohy ukladajte mimo zariadenia, na bezpečnom mieste (napríklad na vzdialené úložisko alebo cloud). Občas si skontrolujte, či viete zálohu reálne obnoviť.
Samostatnú kapitolu by si vyžadovala aj práca s firewallom (napr. UFW) a ochranou proti brute-force útokom (napr. fail2ban). Ak s tým ale nemáte skúsenosti, odporúčame držať sa radšej riešenia typu Cloudflare Tunnel, pri ktorom táto starosť odpadá (porty ostávajú uzavreté). Zároveň je dôležité dbať nad bezpečnosťou samotnej aplikácie, ktorú plánujete vypustiť do sveta (HTTPS, autentifikácia, ošetrenie vstupov, správa env premenných, aktualizácia knižníc…), no to je taktiež mimo rámec tohto článku.
Cesta pokračuje
Raspberry Pi je malý hardvérový zázrak a v rukách vývojára sa z neho môže stať poctivá webová infraštruktúra, inkubátor nápadov aj vstupná brána do sveta DevOps. Po ceste si osvojíte čítanie logov, monitoring, základy sieťovania aj bezpečnostnú hygienu—schopnosti, ktoré oceníte pri akomkoľvek pracovnom či voľnočasovom projekte.
Ako som spomínal v úvode, tento článok nemohol pokryť všetko. Nedostali sme sa ku támam ako záložné zdroje napájania (UPS), pokročilá bezpečnosť, rollbacky, rôzne typy deployu či škálovanie. Verím však, že ste sa zorientovali aspoň v základných témach a získali solídny odrazový mostík pre ďalšie experimenty a samoštúdium.

Ak ste dočítali až sem, alebo ak vám aplikácia dokonca už aj beží, je to veľký úspech! Raz možno narazíte na limity jednoduchého „domáceho serveríka“: databáza začne spomaľovať, SD karta sa opotrebuje, pamäť bude na hrane. No berte to ako signál, že váš projekt nabral obrátky. Vtedy nastáva čas zvážiť posun na výkonnejší server, do cloudu alebo špecializovaného hostingu. Alebo možno zistíte, že aj s Pi sa dá efektívnou prácou so zdrojmi, či domácim klastrom, zvládnuť omnoho viac, než by ste čakali. Nech už vaše ďalšie kroky povedú kamkoľvek, držím palce a prajem veľa úspechov!

Tomáš Bencko
Autorom článku je Tomáš, frontend developer so zameraním na React, Vue.js a TypeScript. Jeho úlohou je vytvárať moderné a škálovateľné frontend riešenia, pričom zvláda nielen vývoj, ale aj jemné detaily dizajnu. Okrem práce pre klientov neustále hľadá spôsoby, ako zefektívniť prácu v tíme, hrá sa s AI a automatizáciou, a prináša nové nápady, ktoré posúvajú projekty aj kolegov vpred.