Agent AI rzadko jest pojedynczym procesem. Jest sama pętla agenta, magazyn wektorowy na pamięć, cache, zwykle baza danych na stan i może mały panel. Uruchamianie każdego z osobna ręcznie — startowanie, restartowanie po reboocie, pamiętanie, który port jest który — szybko się nudzi. Docker Compose opisuje całość w jednym pliku i uruchamia jednym poleceniem. To stos kopiuj-wklej do postawienia agenta na VPS w schludny sposób.
Jeśli chcesz tylko wersję wdrożenia-bez-Dockera, przewodnik uruchamiania agenta AI 24/7 omawia zamiast tego systemd. Ta strona to wersja natywnie kontenerowa.
Stos
Typowy self-hostowany agent chce obok siebie czterech rzeczy: procesu agenta, Qdrant (pamięć wektorowa), Redis (cache / kolejki) i Postgres (stan). Oto docker-compose.yml, który uruchamia to wszystko, z usługami wewnętrznymi trzymanymi z dala od publicznego internetu:
# /opt/agent/docker-compose.yml
services:
agent:
build: . # your agent image (or image: your/agent:latest)
restart: unless-stopped
env_file: [.env] # OPENAI/ANTHROPIC keys etc. — never in this file
environment:
QDRANT_URL: http://qdrant:6333
REDIS_URL: redis://redis:6379
DATABASE_URL: postgres://agent:${DB_PASSWORD}@postgres:5432/agent
depends_on: [qdrant, redis, postgres]
# no ports: — this agent only makes outbound calls. Publish one only if it serves webhooks.
qdrant:
image: qdrant/qdrant:latest
restart: unless-stopped
volumes: ["qdrant:/qdrant/storage"] # internal only — not published
redis:
image: redis:7-alpine
restart: unless-stopped
command: ["redis-server", "--save", "60", "1"]
volumes: ["redis:/data"]
postgres:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: agent
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_DB: agent
volumes: ["pg:/var/lib/postgresql/data"]
volumes: { qdrant: {}, redis: {}, pg: {} }
Sekrety żyją w .env, nie w pliku compose:
# /opt/agent/.env (chmod 600, never committed)
ANTHROPIC_API_KEY=sk-ant-...
DB_PASSWORD=a-long-random-string
Podnieś go:
apt update && apt install -y docker.io docker-compose-v2
systemctl enable --now docker
cd /opt/agent && docker compose up -d
docker compose logs -f agent
Każda usługa wewnętrzna (Qdrant, Redis, Postgres) jest osiągalna tylko w sieci compose po nazwie usługi — żadna z nich nie jest opublikowana do internetu. Agent rozmawia z nimi przez tę prywatną sieć i nic na tych portach nie jest zwrócone ku światu.
Szczegóły, które mają znaczenie
restart: unless-stoppedna każdej usłudze — to właśnie przetrwa reboot lub awarię. Włącz Docker przy rozruchu, a cały stos wraca sam.- Klucze w
.env, nie w YAML. Odwołuj się do nich jako zmiennych env; trzymaj.envnachmod 600i poza gitem. Wyciekły plik compose z żywym kluczem to klasyczny błąd. - Nie publikuj niczego, czego nie musisz. Agent, który wywołuje tylko API modeli i własne usługi, nie potrzebuje żadnego portu przychodzącego — więc plan NAT wystarczy. Dodaj dedykowane IP tylko, jeśli obsługuje webhooki lub panel.
- Dobieraj pod pamięć, nie rdzenie. Agenci oparci na API są lekcy. Gdy indeks Qdrant urośnie albo dodasz model lokalny, wtedy przechodzisz wyżej — zobacz VPS z dużą pamięcią dla agentów.
Część, która naprawdę jest nasza: agent może zbudować sobie maszynę
Ponieważ EQVPS udostępnia serwer MCP, agent uruchamiający ten stos może sam zapewnić sobie kolejny czysty VPS — zamówić go, dostać roota, zburzyć — płacąc z przedpłaconego salda krypto. Stos compose, który potrzebuje świeżej piaskownicy, może ją postawić bez człowieka w pętli.
Dlaczego EQVPS dla zdockeryzowanego agenta
- Czyste obrazy, root w ~60 sekund. Ubuntu/Debian;
docker compose upi stos działa. - Bez KYC, płatność w krypto. E-mail do rejestracji, USDC/USDT do zapłaty — nic nie wiąże maszyny z twoją tożsamością.
- NVMe + niemierzone 1 Gbit/s, UE (Niemcy/Finlandia). Ściąganie obrazów i wysyłanie logów nie wygeneruje niespodziewanego rachunku.
VPS dla agentów AI (przegląd) → · VPS dla Dockera → · Hostuj bazę wektorową dla pamięci agenta →
Komentarze
Brak komentarzy. Bądź pierwszy.