Hur mycket RAM behöver Freqtrade på en VPS?

För en live- eller dry-run-bot är 2 GB en bekväm baslinje — Freqtrade själv är lätt, men Docker-imagen plus en handfull par och indikatorer vill ha marginal. 1 GB kan fungera för en enda strategi på få par, men 2 GB ($5 Micro) är det säkrare golvet. Backtesting och hyperopt är en annan historia — de är minnes- och CPU-hungriga, och du bör köra dem på din egen maskin, inte servern.

Kan jag backtesta och hyperopta på VPS:en?

Du kan, men du bör oftast inte. Backtesting över långa intervall och hyperopt är CPU-bundna och bursty — de nålar fast kärnor i minuter eller timmar. På ett delat, burst-orienterat plan är det fel arbetsbelastning (och ihållande 100%-belastning strider mot policyn för godtagbar användning). Gör den tunga optimeringen lokalt, skeppa sedan den tunade strategin till VPS:en för att köra live.

Hur håller jag min exchange-API-nyckel säker på en server?

Skapa nyckeln med endast trade-behörigheter — aktivera aldrig withdrawal. Om din börs stöder IP-vitlistning, lås nyckeln till serverns IP, vilket är ett verkligt skäl att använda ett dedikerat-IP-plan (ett NAT-plan delar nodens utgående IP). Håll nyckeln i Freqtrade-configen i en root-läsbar, icke-world-readable fil, och kör boten som en non-root användare.

Varför köra boten på en VPS istället för min laptop?

Marknader stänger inte, och en trading-bot måste vara online kontinuerligt för att agera på signaler och hantera öppna positioner. En laptop sover, startar om, och tappar wifi — varje glapp är en missad entry eller en ohanterad exit. En VPS ger dig 24/7 drifttid och en stabil, low-latency-anslutning till börsen. Det är hela poängen.

Att köra Freqtrade på en VPS: krav, Docker-setup, och ärliga gränser

En trading-bot på din laptop är en dålig idé av ett tråkigt skäl: din laptop är inte online 24/7, och marknader är det. Stäng locket mitt i en trade och boten slutar hantera en öppen position. Freqtrade — den populära open-source Python-trading-boten — är byggd för att köra obevakad, vilket är precis vad en liten VPS är till för. Här är vad den faktiskt behöver, hur du sätter upp den med Docker, och de ärliga gränserna ingen nämner förrän du träffar dem.

Varför en server, inte din maskin

Två skäl, båda praktiska:

Drifttid. Boten måste bevaka marknaden och hantera positioner dygnet runt. Varje gång din laptop sover eller startar om är boten blind — en missad entry, eller värre, en öppen position ingen bevakar.
Latens och stabilitet. En VPS sitter på en datacenteranslutning med en stadig rutt till börsen. Hem-wifi-jitter och NAT-resets hjälper inte en bot som reagerar på pris.

Detta är samma logik bakom att köra vilken trading-bot som helst på en VPS — Freqtrade gör bara kraven konkreta.

Vad den faktiskt behöver

Freqtrade själv är lättviktig, men var realistisk om arbetsbelastningen:

Live- / dry-run-bot: 2 GB RAM är ett bekvämt golv. Docker-imagen, en handfull par, indikatorer, och SQLite-trade-DB:n vill alla ha lite marginal. En $5 Micro (2 vCPU / 2 GB / 25 GB) är rätt startpunkt. 1 GB kan köra en enda enkel strategi på ett par par, men du är närmare kanten.
Många par / flera strategier: kliv upp till en $8 Small (4 vCPU / 4 GB / 35 GB) — fler par betyder mer samtidig indikatorberäkning och en större dataframe i minnet.
Disk: blygsam. Imagen, din user_data, och trade-DB:n får plats bekvämt i 25 GB. Nedladdad historisk data för backtesting är det enda som växer — och det lever mestadels på din lokala maskin (se nedan).

Sätt upp den med Docker Compose

Docker är det underhållna, minst smärtsamma sättet att köra Freqtrade. På en fräsch box:

sudo apt update && sudo apt install -y docker.io docker-compose-v2
mkdir ~/ft && cd ~/ft
docker run --rm -v "$(pwd)/user_data:/freqtrade/user_data" \
  freqtradeorg/freqtrade:stable create-userdir --userdir user_data

Hämta den officiella compose-filen och skapa en config interaktivt (den frågar om din börs, stake, och dry-run):

curl -s https://raw.githubusercontent.com/freqtrade/freqtrade/stable/docker-compose.yml -o docker-compose.yml
docker compose run --rm freqtrade new-config --config user_data/config.json

Dry-run först — alltid

Rikta aldrig en fräsch strategi mot riktiga pengar. Freqtrade defaultar till dry-run (paper trading) och du bör lämna den där tills strategin har bevisat sig på live marknadsdata ett tag. I config.json:

{
  "dry_run": true,
  "dry_run_wallet": 1000
}

Starta den och titta:

docker compose up -d
docker compose logs -f

Policyn restart: unless-stopped i compose-filen är din systemd-motsvarighet här — Docker tar tillbaka boten efter en krasch eller en serveromstart, inget manuellt steg. (Om du föredrar att köra den utanför Docker gör en systemd-unit med Restart=always samma jobb — samma princip som att hålla vilken bot som helst vid liv.)

Exchange-API-nycklar — delen som biter folk

Det är här en trading-uppsättning går fel dyrt. Två regler, icke förhandlingsbara:

Endast trade-behörighet. Aktivera aldrig withdrawal. Om nyckeln läcker är worst case oönskade trades — inte att dina medel går ut genom dörren. Freqtrade behöver aldrig withdrawal-åtkomst.
IP-vitlista nyckeln. De flesta börser låter dig binda en API-nyckel till specifika IP:er. Det är ett konkret skäl att köra på ett dedikerat-IP-plan: nyckeln fungerar bara från din servers fasta adress. På ett NAT-plan delar boten nodens utgående IP, vilket inte är din ensam — bra för att boten ska fungera, men du kan inte rent vitlista den.

Håll nycklarna i config.json, gör den icke-world-readable (chmod 600), och kör containern som en non-root användare. Och lås ner boxen först — nya-VPS-säkerhetschecklistan tar tio minuter och stänger dörrarna som spelar roll.

Säkerhetskopiera user_data

Dina strategier, config, och trade-historik lever alla i user_data. Det är det du inte vill förlora:

tar czf ft-backup-$(date +%F).tar.gz user_data

Dra ner det från servern regelbundet (eller till objektlagring). Att förlora trade-DB:n betyder att förlora din prestandahistorik; att förlora en tunad strategi betyder att göra om optimeringen.

De ärliga gränserna

Backtesting och hyperopt är tunga — gör dem lokalt. De nålar fast CPU i utdragna sträckor, och en delad, burst-orienterad VPS är byggd för spikiga arbetsbelastningar, inte timmar av ihållande 100%-belastning (vilket också strider mot policyn för godtagbar användning). Optimera på din egen maskin, distribuera resultatet för att köra live. VPS:en är för live-boten, inte forskningen.
CPU är delad/burst. Utmärkt för en live-bot som mestadels väntar på candles och reagerar; fel för att mala ett år av 1-minutersdata genom hyperopt.
En region, endast CPU. Servern finns i Tyskland utan GPU. Bra för Freqtrade (det är CPU/logik, inte ML-träning) — värt att veta om din strategi lutar sig mot en tung ML-modell, som återigen är bättre att träna lokalt.

Slutsats

Freqtrade på en VPS är rätt uppsättning för live-boten: en $5 Micro för en fokuserad strategi, en $8 Small om du kör många par, Docker Compose med restart: unless-stopped för drifttid, och en trade-only, IP-vitlistad API-nyckel så att en läcka inte kan tömma dig. Håll den tunga backtestingen och hyperopten på din laptop, säkerhetskopiera user_data, och låt servern göra det enda den är bra på — att hålla sig online medan marknaden rör sig. Registrering är endast-e-post och du betalar i USDC eller USDT; en dedikerad IP är den enda uppgraderingen värd det här, rent för API-nyckel-vitlistan.

Redo att distribuera? Freqtrade är bekväm på ett Micro-plan; för tyngre backtests eller många par, skala upp till Small.