Sinlege / VPS / VPS Discord Bot
VPS pod bota Discord - proces online całą dobę
Bot to proces 24/7 — nie laptop zamykany o północy. Node, Python, Lavalink obok — policz RAM. Token w env, nie w repo.
Proces, nie serverless
Discord bot to długo żyjący proces. VPS daje stały IP i systemd restart.
Serverless z cold start — słabe do voice i gateway persistent connection.
Mały plan często wystarczy. 512 MB–1 GB dla prostego bota. Muzyka + Lavalink — więcej.
Node, Python, JDA, discord.py
Wybierz runtime i pinuj wersję w package.json / requirements.txt.
pm2 albo systemd Unit z Restart=always. Logi do journal lub pliku z rotation.
Sharding przy dużej liczbie guild — wtedy większy plan albo kilka procesów.
Tokeny i uprawnienia
DISCORD_TOKEN w .env, plik chmod 600. Nigdy w GitHub.
Intents — włącz tylko potrzebne. Privileged intents wymagają weryfikacji aplikacji.
Rotacja tokena po wycieku — procedura w dokumentacji Discord.
Inne ryzyko. Oba sekretne.
Bot muzyczny i Lavalink
Lavalink to osobny JVM — RAM rośnie szybko. Często drugi proces na tym samym VPS.
Egress transferu przy streamingu utworów — sprawdź limity planu.
CPU steal przy transcode — mniejszy bitrate albo źródło bez transcode.
Sieć i latency
Discord gateway globalny — WAW nie „przyspiesza Discorda”, ale stabilność procesu tak.
Transfer w planie. Obrazki, embedy, upload plików — egress.
Anti-DDoS L3/L4 — bot rzadko celem, ale IP publiczne zostaje.
Monitoring i alerty
Health ping co minutę — Uptime Kuma albo cron curl.
Alert gdy proces padnie — systemd FailedUnit albo zewnętrzny monitor.
Discord webhook do Ciebie o crashu — ironia, ale działa.
Kiedy większy plan
RAM >80% stale — upgrade. CPU spike co event — może OK.
Wiele botów na jednym VPS — oddzielne użytkowniki systemowi, limity cgroup.
Lavalink obok bota
Osobny JVM 512 MB–1 GB+. Nie na najmniejszym planie z botem i DB.
Pluginy Lavalink — wersje zgodne z botem muzycznym.
YouTube źródła — zmiany API, nie problem VPS — monitoruj biblioteki.
SQLite vs Postgres dla bota
SQLite OK do kilku tysięcy rekordów, jeden proces. Backup pliku .db na stop bota.
Postgres gdy wiele workerów — connection pool limituj.
Redis cache — opcjonalnie, kolejny proces.
Deploy bez downtime bota
pm2 reload albo blue/green z dwoma folderami i krótkim disconnect.
Webhook informujący adminów o deploy — transparency.
Env per environment — dev token nigdy na prod VPS.
Koszt utrzymania 24/7
Mały plan VPS często tańszy niż always-on home PC + prąd.
Transfer przy dużych embedach i uploadach — w limicie planu.
Upgrade gdy latency komend rośnie z CPU steal.
Uptime 99% bota
Monitor zewnętrzny co 60 s — Discord API czasem ma outage, odróżnij od padnięcia VPS.
Auto-restart z limitem — nieskończony restart loop zjada logi.
Status channel na Discord z embed — transparentność dla użytkowników.
Proces 24/7 w praktyce
systemd Restart=always z sensownym StartLimitBurst — unikaj pętli restart.
Mały plan często wystarczy — bot nie potrzebuje 8 vCPU. Lavalink obok — osobno licz RAM.
Token w env, rotacja po wycieku. Intents w portalu Discord — minimum.
Transfer — embedy, upload, muzyka. Limit planu VPS.
KVM WAW — stabilność procesu, nie „bliżej Discord gateway”. Monitoring zewnętrzny.
Backup SQLite/Postgres bota offsite. Kod w git ≠ backup danych użytkowników bota.
Eventy Discord a obciążenie
Giveaway, mass role — spike API. Rate limit handling w kodzie.
Shard manager gdy guild count rośnie — plan przed bottleneck.
Cache guild w pamięci — monitor RSS.
Host Sinlege
KVM mały plan, WAW, transfer w cenie. AS219481 routing stabilny dla outbound API Discord.
Anti-DDoS — bot rzadko celem DDoS, ale IP publiczne zostaje.
Backup tokenów i DB poza VPS.
Po pierwszym outage
Postmortem: token wyciekł czy proces crash — inna naprawa.
Restart counter w systemd — czy pętla.
RAM baseline idle zapisany — wykryjesz leak.
Backup bota i config poza VPS.
Skala bota
Shard manager config zapisany w repo.
Rate limit 429 handler testowany.
Cache size limit — unikaj memory leak map guild.
Webhook errors — log do pliku rotowany.
Plan upgrade gdy latency komend >1s sustained.
Bot 24/7 — podsumowanie
systemd/pm2 restart — obowiązkowy.
Token .env chmod 600 — poza git.
Mały plan często wystarczy; Lavalink osobno licz RAM.
Transfer embed/upload w planie VPS.
KVM WAW — stabilność procesu.
Monitoring zewnętrzny — Discord API outage ≠ Twój VPS down.
Backup SQLite/Postgres bota offsite.
Ryzen host — rarely bottleneck bota.
Anti-DDoS L3/L4 — IP publiczne zostaje.
Shard przed skalą — plan architektury.
Jak o tym myśleć
VPS Discord Bot ma sens, gdy chodzi o: bot 24/7, systemd, tokeny poza laptopem.
To nadal VPS na współdzielonej infrastrukturze: masz root, KVM i transfer w cenie planu, ale CPU steal, IOPS i uplink zależą od realnego obciążenia hosta. Jeśli potrzebujesz stałego heavy loadu 24/7, policz osobną architekturę zamiast zakładać, że większy plan VPS załatwi wszystko.
FAQ
Czy 1 GB RAM wystarczy?
Prosty bot tak. Muzyka, cache, baza obok — zwykle nie.
Czy mogę hostować stronę i bota razem?
Tak, pilnuj sumy RAM i portów.
Python czy Node?
Oba OK. Wybierz bibliotekę, którą znasz. Wydajność rzadko problem przy małej skali.
Czy potrzebuję bazy?
Redis/SQLite/Postgres zależnie od bota. SQLite na NVMe OK dla małych botów.
Backup?
Kod w git. Dane bota (SQLite, config) — backup offsite.
Python discord.py vs Node?
Obie działają. Wybierz znaną bibliotekę. RAM podobny.
Czy bot potrzebuje domeny?
Nie — wystarczy IP. HTTPS tylko jeśli dashboard web.
Dashboard web obok bota?
Tak — nginx reverse proxy, osobny port wewnętrzny.
Rate limit Discord API?
Obsługuj 429 w kodzie — ban globalny boli.
Hosting w WAW a Discord EU?
Gateway globalny — stabilność VPS ważniejsza niż „blisko Discord”.
systemd vs pm2?
systemd — integracja z OS. pm2 — wygodne logi Node.
Wiele botów jeden VPS?
Tak — osobne user i systemd unit. Sumuj RAM.
Secrets rotation?
Regeneruj token w portalu, update .env, restart.
Czy Docker dla bota?
OK — patrz /vps-docker. Nie przesadzaj ze stackiem na 1 GB.
Backup guild config?
Eksport JSON poza VPS — rebuild po utracie dysku.
Pm2 czy systemd dla Node bota?
systemd — mniej moving parts, logi w journal. pm2 — wygodny reload i cluster mode dla sharding. Oba OK na KVM; wybierz i dokumentuj. Restart policy obowiązkowy — laptop nie może być hostem bota produkcyjnego.
Lavalink obok bota — RAM?
Osobny JVM często 512 MB–1 GB+. Nie wciskaj Lavalink, bota, Postgres i redis na najmniejszy plan. Transfer przy streamingu muzyki liczy się do planu VPS w WAW.
Intents a weryfikacja bota?
Privileged intents wymagają weryfikacji aplikacji Discord. Bez MESSAGE CONTENT nie czytasz treści wiadomości. To polityka Discord, nie ograniczenie Sinlege KVM.