Pipe pilnuje Twojego serwera Linux i pisze, gdy coś się psuje

To agent AI, który działa na samym serwerze. Gdy coś idzie nie tak, pisze do Ciebie na Telegram, szuka przyczyny i naprawia. Restart czy zmianę w konfiguracji robi sam, z kopią i sprawdzeniem przed i po. Zanim usunie dane albo ruszy SSH, pyta Ciebie.

git clone https://github.com/Kvmyk/pipe && cd pipe
sudo bash scripts/install-server.sh --lang pl

Open source na licencji MIT. Działa z Gemini (darmowy limit), OpenAI, Claude, Ollamą i innymi. Najnowsze wydanie: wersja 0.50.5.

Okno pipe web: po lewej rozmowa z agentem, który bada błędy 502 i sam poprawia konfigurację nginx, z kopią; po prawej schemat serwera z podświetlonym elementem, na którym agent pracuje — Interfejs w przeglądarce (`pipe web`). Nagranie z zaplanowanej sesji demonstracyjnej.

Co robi sam, a o co pyta

Wszystko, co zaproponuje model, najpierw trafia do klasyfikatora. Zasady są w kodzie Pipe, poza modelem, więc model nie może ich przekonać ani obejść.

Animacja: komendy docierają do klasyfikatora. systemctl reload nginx rusza z kopią, rm -r reports/2025 czeka na Twoje TAK, rm -rf / dostaje odmowę.

Sam

odczyty i rutynowe zmiany z kopią i sprawdzeniem

logi, procesy, dyski, konfiguracja, internet
restart i przeładowanie usług i kontenerów
edycja konfiguracji (kopia, nginx -t przed, sprawdzenie po)
pakiety z repozytorium systemu
docker compose up, git pull z origin

Po Twoim „tak”

to, czego nie da się skopiować ani cofnąć, oraz każda nieznana komenda

usuwanie danych, wolumenów, pakietów
SSH, użytkownicy, zapora, cron, usługi systemd
kod aplikacji, Dockerfile, docker run
pliki z sekretami (.env, klucze)
wysyłanie danych poza serwer

Nigdy

odrzucane bez względu na to, kto prosi

rm -rf / i jego odmiany
mkfs, dd, wipefs na dyskach
zapis do /etc/shadow i /boot
pobieranie i uruchamianie skryptów (curl … | sh)

Jak wygląda praca z Pipe

Piszesz zwykłym językiem. Agent sam dobiera komendy, czyta logi i konfigurację, a gdy czegoś nie wie, szuka w internecie. Poniżej: błędy 502 w sklepie, a potem prośba, której sam nie wykona.

sklep.example.com co chwilę sypie 502, sprawdź co jest grane

pipe

docker logs shop-app
tail -n 80 /var/log/nginx/error.log
szuka w sieci: nginx upstream timed out 110
czyta nginx.org: ngx_http_proxy_module

pipe

Bez pytania: rutynowa zmiana, przez bezpiecznik

$ sed -i 's/proxy_read_timeout 60s;/proxy_read_timeout 120s;/' /etc/nginx/sites-enabled/sklep.conf && systemctl reload nginx

kopia: /etc/nginx/sites-enabled/sklep.conf
przed: nginx -t przeszedł
po: nginx działa, strony odpowiadają jak przed zmianą

Naprawione, sklep.example.com znów odpowiada. Raport PDF generuje się około 75 sekund, a nginx czekał na odpowiedź tylko 60 (proxy_read_timeout). Podniosłem limit do 120 sekund. Kopia jest w dzienniku, cofniesz to komendą /cofnij.

i usuń stare raporty z /srv/sklep/raporty

pipe

Tu potrzebuję Twojej zgody: danych nie da się skopiować

$ rm -r /srv/sklep/raporty/2025

2140 plików, 3,8 GB
po usunięciu nie będzie kopii do przywrócenia

Rura między Tobą a serwerem

Zawór to jedna z trzech części dłuższej rury. Przechodzi przez nią wszystko, o co prosisz, i tą samą drogą wraca to, co serwer ma Ci do powiedzenia, także alerty.

Schemat: po lewej Ty, po prawej Twój serwer, między wami rura. Twoje pytanie idzie do modelu językowego, który proponuje komendę. Komenda przechodzi przez zawór i bezpiecznik do serwera, a wynik wraca obok czujnika.

Zawór	Decyduje, co przejdzie, według zasad opisanych wyżej.
Bezpiecznik	Przed zmianą robi kopię, a po niej sprawdza wynik. Gdy kontrola konfiguracji się nie uda, wraca stara wersja. Resztę cofniesz przez `/cofnij`.
Czujnik	Co dwie minuty odczytuje stan serwera, bez modelu językowego. Gdy odczyt jest zły, Pipe pisze do Ciebie pierwszy.

Model wymyśla, co zrobić, a Pipe decyduje, co naprawdę się wykona. Dlatego model jest przed zaworem. To część wymienna: Gemini, Claude, OpenAI albo lokalna Ollama. Zasady, pamięć i narzędzia zostają w Pipe. Taką warstwę wokół modelu inżynierowie nazywają harnessem.

Gdzie z nim rozmawiasz

Backend działa na serwerze. Klienci łączą się z nim przez tunel SSH, więc na serwerze nie trzeba otwierać żadnego portu.

Terminal	Komenda `pipe` na Twoim komputerze (Windows, macOS, Linux). Potwierdzenia pokazują komendę i plan bezpiecznika, diagramy zapisują się jako PNG. Plik dołączasz przez `@ścieżka`.
Przeglądarka	`pipe web` otwiera rozmowę obok schematu serwera, na którym widać, gdzie agent właśnie pracuje. Każda zmiana ma podgląd różnic i przycisk cofnięcia. Zrzut ekranu wklejasz do rozmowy, a mikrofon nagrywa pytanie głosem.
Telegram	Tu przychodzą alerty, przypomnienia i poranny raport. Przy alercie jest przycisk „Zbadaj”. Możesz wysłać głosówkę, zdjęcie albo plik z logiem (głos rozumie od razu z Gemini, OpenAI i Groq).

Co jeszcze potrafi

Pilnuje bez kosztów: Co dwie minuty sprawdza dyski, pamięć, obciążenie, kontenery i nowe porty otwarte na świat. Te sprawdzenia działają bez modelu językowego, więc nic nie kosztują.
Wie, co się zmieniło: Co godzinę zapisuje stan serwera: pakiety, obrazy kontenerów, porty, crona, konta i konfiguracje. Na pytanie „co się zmieniło od wczoraj?” odpowiada z godziną.
Monitoring bez konfiguracji: Sam znajduje domeny w konfiguracji nginx, Caddy i Traefika i pilnuje certyfikatów, odpowiedzi stron, DNS oraz świeżości backupów.
Audyt bezpieczeństwa: /audyt ocenia serwer w skali 0–100: SSH, zapora, bazy wystawione na świat, konta, aktualizacje. Do każdej uwagi daje gotową poprawkę.
Wiele serwerów: Zdalne maszyny (SSH), kontenery i klastry Kubernetes dodajesz jako cele. Pomocnicy badają je równolegle i tylko czytają.
Pamięć: Zapisuje fakty o serwerze, mapę katalogów, sprawdzone procedury i rozwiązane incydenty. Gdy problem wraca, zaczyna od tego, co pomogło poprzednio.
Rutyny i przypomnienia: „Codziennie o 7 sprawdź backupy, pisz tylko jak coś jest nie tak” zakłada zadanie, które wykonuje się samo.
Inni agenci przez MCP: Claude Code czy Cursor mogą pracować na serwerze przez Pipe. Ich zmiany też czekają na Twoją zgodę.

Instalacja

Potrzebujesz serwera z Linuksem, dostępu przez SSH i klucza API do modelu językowego. Jeśli nie masz klucza, wybierz Google Gemini: darmowy klucz wygenerujesz na aistudio.google.com/apikey.

Na serwerze

Instalator postawi Dockera (jeśli go nie ma), zapyta o dostawcę modelu i klucz, sprawdzi, czy wybrany model obsługuje narzędzia, i uruchomi Pipe.

git clone https://github.com/Kvmyk/pipe && cd pipe
sudo bash scripts/install-server.sh --lang pl
# bez Dockera: sudo bash scripts/install-server.sh --mode native --lang pl

Na swoim komputerze

Instalator klienta zapyta o adres serwera. Potem w każdym terminalu wpisujesz pipe albo pipe web.

git clone https://github.com/Kvmyk/pipe && cd pipe
bash install.sh       # Linux, macOS
.\install.ps1         # Windows (PowerShell)

Załóż bota u @BotFather, wpisz jego token i swój identyfikator do clients/telegram/.env i uruchom instalator serwera jeszcze raz. Instrukcja krok po kroku.

Kubernetes, instalację natywną z systemd i cloud-init opisuje strona Wdrożenie w dokumentacji.

Co warto wiedzieć przed instalacją

W trybie Docker Pipe ma dostęp do docker.sock, czyli w praktyce uprawnienia roota. Bez pytania Pipe robi tylko rutynę z kopią (restart, przeładowanie, poprawka w konfiguracji). Usunięcie danych, dostęp, autostart i nieznane komendy czekają na Ciebie, więc czytaj, co zatwierdzasz.
Treść rozmowy trafia do dostawcy modelu. Klucze, hasła i tokeny z plików są ukrywane przed wysłaniem, ale logi i konfiguracja już nie. Jeśli to problem, użyj lokalnego modelu przez Ollamę.
Rozmowy są zapisywane na serwerze i przetrwają restart backendu. Potwierdzenie, które wtedy czekało, nie wraca.
Jakość diagnozy zależy od modelu. Słabszy model częściej się myli. Dlatego każda zmiana przechodzi przez kopię i weryfikację, a ważne czekają na Twoje potwierdzenie.

Szczegóły: Bezpieczeństwo.