Agent AI do konfiguracji Linuxa na VPS

Agent AI (Cursor, Claude Code i podobne) nie loguje się magicznie na Twój VPS. Ty dajesz mu stan serwera i cel. On proponuje polecenia i pliki. Ty wklejasz je na maszynę — albo odrzucasz. To asystent przy konfiguracji, nie administrator z kartą SIM do DC.

Na hostingu WWW agenta do jądra nie potrzebujesz. Na VPS oszczędza czas przy Nginx, Dockerze, Certbocie i zaporze, jeśli trzymasz ramy: fakty z serwera, wąskie zadanie, przegląd zanim coś skasuje.

Co zebrać przed rozmową

Zaloguj się i wklej wynik, nie hasło:

hostnamectl
cat /etc/os-release
df -h
free -h
ss -tlnp
sudo nft list ruleset
systemctl list-units --type=service --state=running

Dopisz po ludzku: system z panelu (Ubuntu 24.04), plan (np. VX21, 2 GB RAM), co ma stanąć (strona + Postgres w Dockerze), co już działa (SSH na 22). Agent bez tego zgaduje wersje pakietów i otwiera porty, których nie masz w zaporze.

Jak formułować zadanie

Źle: „Zabezpiecz serwer i zrób, żeby działało.”

Lepiej:

Ubuntu 24.04, 2 GB RAM, nftables default-deny, SSH na 22 już działa.
Chcę Nginx + Certbot dla domeny example.pl, backend na 127.0.0.1:3000.
Nie ruszaj SSH. Podaj konkretne pliki i polecenia apt/systemctl.
Po zmianie zapory pokaż, jak zapisać ruleset na restart.

Im ciaśniejszy cel, tym mniej halucynacji. Jedna sesja = jeden stos (WWW, albo Docker, albo FTP), nie „cały serwer od zera i jeszcze Kubernetes”.

Przykłady, przy których agent bywa użyteczny:

• plik compose.yml i jednostki systemd
• vhost Nginx / Caddy
• reguły nftables pod 80/443
• fail2ban na sshd
• rotacja logów i limit journald na małym NVMe

Przy Dockerze wklej też docker compose config i docker ps, żeby nie dostać drugiej, sprzecznej instalacji.

Zasady, których agent nie pilnuje za Ciebie

1. Nie wklejaj haseł, kluczy SSH, tokenów API, danych karty. Agent tego nie powinien widzieć. Placeholdery: HASLO_DB, TWOJ_IP.
2. Nie uruchamiaj w ciemno rm -rf, mkfs, iptables -F, nft flush ruleset, chmod -R 777, wyłączenia sshd. Najpierw przeczytaj. Flush zapory na VPS z SSH-only to sposób, żeby stracić dostęp.
3. Polecenie z curl | bash z nieznanego URL — odrzuć. Instaluj z apt albo z dokumentacji projektu, którą sam otworzysz.
4. Sprawdź nasłuch po zmianie: ss -tlnp. Baza na 0.0.0.0 to błąd, nawet jeśli „tak wyszło z przykładu”.
5. Backup przed dużą zmianą. Dump bazy, kopia compose.yml i /etc/nginx. Backup VPS w cenie nie zastępuje pięciu minut ostrożności.

Przepływ, który działa

1. Zbierasz fakty z VPS (blok poleceń wyżej).
2. Opisujesz cel i limity (RAM, nie ruszać SSH).
3. Dostajesz pliki — wklejasz na serwer przez SFTP albo nano, nie „cały skrypt na root bez czytania”.
4. Test: nginx -t, docker compose up -d, systemctl status.
5. Dopiero wtedy otwierasz port w zaporze. Kolejność odwrotna zaprasza skan w trakcie instalacji.

Jeśli agent proponuje ufw, a na maszynie jest nftables — popraw go. Na VPS b00ber licz się z nftables, nie z inną zaporą „bo tak było w tutorialu z 2019”.

Czego nie deleguj

• polityki kopii i retencji — to Twoja decyzja
• wystawiania panelu administracyjnego na 0.0.0.0
• produkcji bez przeglądu diffu konfiguracji

Agent przyspiesza składnię. Odpowiedzialność za otwarte wejście zostaje przy Tobie. Jak dobrze wykorzystać VPS i 30 poleceń — żebyś rozumiał, co właśnie wkleiłeś.

W skrócie

Dajesz kontekst z hostnamectl, ss i nftables. Prosisz o jeden konkret. Nie wklejasz sekretów. Nie odpalasz flush i rm -rf bez czytania. Agent skraca Compose i vhosty; zapora i root zostają Twoje.