Jak bezpečně nasadit svoji první AI-vygenerovanou aplikaci

Tak máš appku — co teď?

Gratuluju! Sedl jsi k ChatGPT, Cursorovi nebo Copilotu, popsal jsi co chceš, a ono to funguje. Máš hotovou aplikaci, běží ti lokálně na localhost:3000 a vypadá skvěle. Teď ji chceš ukázat světu.

Ale pozor — mezi "funguje mi to na mém počítači" a "je to bezpečně na internetu" je obrovská propast. A právě tou propastí proleze spousta problémů, které ti můžou pořádně zkomplikovat život.

Neboj, nemusíš být bezpečnostní expert. Stačí znát pár základních pravidel a tvoje appka bude v bezpečí. Pojďme na to.

Kde to vlastně hostovat?

První otázka: kam tu appku dát? Máš několik možností a každá má své výhody i nevýhody z pohledu bezpečnosti.

Managed platformy (Vercel, Netlify, Railway)

Pro koho: Pokud jsi vibecoder a nechceš řešit servery, tohle je tvoje volba.

• Vercel — ideální pro Next.js aplikace. HTTPS máš automaticky, deploye jsou izolované, environment proměnné se dají nastavit přes dashboard. Nemusíš řešit skoro nic.
• Netlify — podobné jako Vercel, super pro statické stránky a jednoduché backendy. Opět automatické HTTPS.
• Railway — skvělé pro full-stack aplikace s databází. Dá ti PostgreSQL jedním kliknutím a postará se o síťování.

Výhoda z bezpečnostního hlediska: Platforma řeší spoustu věcí za tebe — SSL certifikáty, izolaci, firewall, aktualizace operačního systému. Ty se staráš jen o svůj kód.

Nevýhoda: Menší kontrola. Pokud platforma udělá chybu, nemůžeš s tím nic dělat. A u free tierů můžou být omezení, která tě donutí dělat kompromisy.

VPS (DigitalOcean, Hetzner, Linode)

Pro koho: Pokud chceš víc kontroly nebo máš specifické požadavky.

Tady dostaneš prázdný Linux server a všechno si musíš nastavit sám. To znamená:

• Nainstalovat a nakonfigurovat webový server
• Nastavit firewall
• Řešit SSL certifikáty
• Aktualizovat systém
• Monitorovat co se děje

Výhoda: Plná kontrola, nižší cena při větším provozu, flexibilita.

Nevýhoda: Pokud nevíš co děláš, můžeš udělat bezpečnostní díry, o kterých ani nevíš. A nikdo tě na ně neupozorní.

Moje doporučení: Pokud jsi na začátku, jdi do managed platformy. Bezpečnostně je to výrazně jednodušší a za pár dolarů měsíčně máš klid.

HTTPS je povinnost, ne luxus

Tohle nemůžu zdůraznit dost: tvoje aplikace MUSÍ běžet na HTTPS. Bez výjimky. Bez diskuze.

Proč?

Bez HTTPS jde veškerá komunikace mezi uživatelem a tvou appkou po síti jako čistý text. To znamená, že kdokoliv na stejné Wi-Fi síti (kavárna, letiště, coworking) může vidět:

• Přihlašovací údaje uživatelů
• Data z formulářů
• API tokeny
• Prostě všechno

Jak na to?

Pokud používáš Vercel nebo Netlify, máš HTTPS automaticky. Hotovo, další bod.

Pokud máš VPS, použij Let's Encrypt — je to zdarma a certifikát si obnovuje sám:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d tvojedomena.cz

Certbot ti nastaví automatické obnovování certifikátu. Žádné výmluvy — HTTPS je zdarma a trvá to 5 minut.

Environment proměnné — nikdy nehardcoduj API klíče

Tohle je pravděpodobně nejčastější chyba, kterou vibecodeři dělají. AI ti vygeneruje kód a ty do něj přímo napíšeš svůj API klíč:

// ❌ NIKDY tohle nedělej
const apiKey = "sk-abc123456789";
const dbPassword = "mojeTajneHeslo123";

Proč je to problém? Protože:

1. Commitneš to do Gitu a i když to pak smažeš, v historii to zůstane navždy
2. Kdokoliv s přístupem k repo vidí tvoje klíče
3. Boti aktivně skenují GitHub a hledají přesně tyhle věci — tvůj AWS klíč najdou za minuty

Jak to dělat správně?

Použij environment proměnné. Vytvoř soubor .env:

# .env (tohle NIKDY necommituj!)
DATABASE_URL="postgresql://user:heslo@localhost:5432/mydb"
API_KEY="sk-abc123456789"
SECRET_KEY="nejake-nahodne-znaky"

A v kódu je načítej:

// ✅ Takhle je to správně
const apiKey = process.env.API_KEY;
const dbUrl = process.env.DATABASE_URL;

Důležité: Přidej .env do .gitignore! Vytvoř .env.example s prázdnými hodnotami, aby ostatní věděli jaké proměnné potřebují:

# .env.example (tohle můžeš commitnout)
DATABASE_URL=
API_KEY=
SECRET_KEY=

Firewall basics — proč nechceš mít vše otevřené

Představ si svůj server jako dům. Každý port je jedno okno nebo dveře. Chceš mít otevřené všechny? Asi ne.

Na VPS serveru bys měl mít otevřené jen porty, které skutečně potřebuješ:

• Port 22 — SSH (pro správu serveru)
• Port 80 — HTTP (přesměrování na HTTPS)
• Port 443 — HTTPS (tvoje aplikace)

Všechno ostatní zavři. Na Ubuntu/Debianu to uděláš s ufw:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Na managed platformách tohle řešit nemusíš — platforma to dělá za tebe. Další bod pro Vercel & spol.

SSH klíče místo hesel

Pokud se připojuješ na server přes SSH, vypni přihlašování heslem a používej SSH klíče. Je to bezpečnější a pohodlnější:

# Na svém počítači vygeneruj klíč (pokud ještě nemáš)
ssh-keygen -t ed25519

# Nahraj klíč na server
ssh-copy-id user@tvuj-server.cz

Pak v /etc/ssh/sshd_config nastav:

PasswordAuthentication no

Reverse proxy — proč neexponovat Node.js přímo

Spousta AI-generovaných aplikací běží na Node.js a poslouchá na portu 3000. Lákavé řešení: otevřu port 3000 na firewallu a hotovo!

Nedělej to. Místo toho použij reverse proxy — Nginx nebo Caddy, který stojí mezi internetem a tvou aplikací.

Proč?

• Nginx/Caddy jsou navržené pro práci s internetovým provozem — zvládají tisíce spojení, řeší SSL, komprimují data
• Node.js na tohle stavěný není — jedním DDoS útokem ho položíš
• Reverse proxy ti dává místo pro rate limiting, caching, security headers

Jednoduchá konfigurace Nginx:

server {
    listen 443 ssl;
    server_name tvojeappka.cz;

    ssl_certificate /etc/letsencrypt/live/tvojeappka.cz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tvojeappka.cz/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nebo ještě jednodušeji s Caddy (automatický HTTPS!):

tvojeappka.cz {
    reverse_proxy localhost:3000
}

Caddy si sám obstará SSL certifikát. Dvě řádky konfigurace a máš bezpečný reverse proxy.

Monitoring — potřebuješ vědět co se děje

Nasadit aplikaci a pak se na ni nikdy nepodívat je jako zamknout dům a nikdy nekontrolovat jestli tam někdo neleze oknem.

Základní monitoring nemusí být složitý:

Co sledovat?

• Uptime — běží tvoje appka vůbec? Služby jako UptimeRobot (zdarma) ti pošlou notifikaci, když spadne
• Logy — co se děje v aplikaci? Přidej logování, alespoň pro chyby a neúspěšné přihlášení
• Využití zdrojů — dochází ti místo na disku? Žere appka příliš RAM?

Jednoduché logování v Node.js:

const winston = require("winston");

const logger = winston.createLogger({
  level: "info",
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: "error.log", level: "error" }),
    new winston.transports.File({ filename: "combined.log" }),
  ],
});

logger.info("Aplikace nastartovala");
logger.error("Něco se pokazilo", { error: err.message });

Security monitoring

Sleduj i podezřelou aktivitu:

• Opakované neúspěšné pokusy o přihlášení
• Neobvyklý počet requestů z jedné IP
• Pokusy o přístup k souborům, které by neměly být přístupné (.env, .git, wp-admin)

Co zkontrolovat před nasazením

Než klikneš na „Deploy“, projdi si checklist v TunaGuard — krok za krokem, s testy a vysvětlením. Žádná položka ti neuteče.

Další krok

Tohle byl rychlý přehled, ale bezpečnost má spoustu dalších vrstev. Od správného nastavení HTTP hlaviček přes CORS politiku až po zabezpečení API endpointů.

Chceš si projít celý checklist krok za krokem? Podívej se na naši kategorii Bezpečné nasazení aplikace v TunaGuard. Provedeme tě všemi kroky a nic nevynecháš. Protože zapomenout na jednu věc může znamenat velký problém.