Serviciile de automatizare găzduite taxează per sarcină, iar contorul merge și pentru lucruri care nici nu sunt muncă. Un flux care verifică un feed la fiecare cinci minute înseamnă 8.640 de rulări pe lună înainte să fi făcut ceva util. Rulează același flux pe serverul tău, iar factura e serverul.
Activepieces este un constructor de automatizări open source: declanșatoare, pași, ramificații, câteva sute de integrări gata făcute și pași de cod atunci când cele gata făcute nu mai ajung. Ediția community are licență MIT și rulează fără probleme pe un server mic cu Docker Compose.
Ce plan
L-am instalat pe un server de test și am măsurat. Fișierul compose standard pornește aplicația și cinci workeri: circa 2,6–3 GB RAM împreună cu Postgres și Redis. Cu un singur worker coboară în jur de 1,6 GB.
| Ce rulezi | Plan |
|---|---|
| Câteva fluxuri personale, un worker | Micro-IP — 2 vCPU, 2 GB, 25 GB ($10/lună), plus swap |
| Configurația standard: cinci workeri, fluxuri de echipă, webhook-uri | Small-IP — 4 vCPU, 4 GB, 35 GB ($16/lună) |
| Multe rulări simultane, pași de cod grei | Medium-IP — 6 vCPU, 6 GB, 45 GB ($20/lună) |
Alege un plan cu IPv4 propriu. Webhook-urile sunt motivul principal pentru care găzduiești asta singur, iar serviciile care le apelează trebuie să ajungă la porturile 80 și 443; pe planurile NAT, din exterior se poate ajunge doar la portul SSH. Există două locații din UE (disponibilitatea se vede la comandă). Poți plăti în cripto, fără KYC.
Instalare
Mai întâi îndreaptă un domeniu — să zicem flows.example.com — spre server. Apoi, ca root pe Ubuntu 24.04 sau Debian 12:
curl -fsSL https://get.docker.com | sh
git clone --depth 1 https://github.com/activepieces/activepieces.git
cd activepieces
sh tools/deploy.sh
deploy.sh copiază .env.example în .env și completează secrete aleatorii. Înainte de prima pornire, schimbă două rânduri în .env și unul în fișierul compose:
sed -i 's|^AP_FRONTEND_URL=.*|AP_FRONTEND_URL=https://flows.example.com|; s|^AP_TELEMETRY_ENABLED=.*|AP_TELEMETRY_ENABLED=false|' .env
sed -i "s|- '8080:80'|- '127.0.0.1:8080:80'|" docker-compose.yml
Contează primul rând. AP_FRONTEND_URL nu e doar pentru linkurile din interfață: prin el se conectează workerii la aplicație. Lasă-l pe http://localhost:8080 și fiecare container worker caută aplicația în el însuși, nu o găsește, iar fluxurile tale nu se publică niciodată. Exact asta ni s-a întâmplat: „Socket.IO connection error” în logurile workerului, o cerere de publicare blocată și webhook-uri care răspundeau 404. Cu domeniul real, același flux s-a publicat și webhook-ul a rulat.
sed-ul pe docker-compose.yml ține portul 8080 pe localhost. Porturile publicate de Docker ocolesc ufw, așa că fără el aplicația ar fi deschisă pe un port gol lângă HTTPS-ul tău.
Pe Micro-IP, coboară și la un singur worker:
sed -i 's/replicas: 5/replicas: 1/' docker-compose.yml
Acum HTTPS și pornirea:
apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
flows.example.com {
reverse_proxy 127.0.0.1:8080
}
EOF
systemctl reload caddy
ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
docker compose -p activepieces up -d
Așteaptă o jumătate de minut, deschide https://flows.example.com și creează-ți contul pe loc. Cine se înregistrează primul deține platforma; după aceea, înregistrarea se face doar pe bază de invitație.
Verifică dacă webhook-urile funcționează
Creează un flux cu declanșatorul Webhook (Catch Webhook), adaugă orice pas și publică-l. Panoul declanșatorului afișează URL-ul. Trimite-i un eveniment de test:
curl -X POST https://flows.example.com/api/v1/webhooks/YOUR_FLOW_ID \
-H 'content-type: application/json' \
-d '{"event":"payment.paid","amount":16}'
Ar trebui să primești 200, iar rularea apare în Runs ca reușită. Dacă primești 404, întoarce-te și verifică AP_FRONTEND_URL.
Pe termen lung
- Actualizări. Fișierul compose fixează o versiune exactă (
0.92.2la momentul scrierii). Schimbă eticheta îndocker-compose.yml, apoidocker compose -p activepieces pull && docker compose -p activepieces up -d. Răsfoiește întâi notele de versiune; instrumentele de automatizare adoră să redenumească lucruri. - Backupuri. Fluxurile, conexiunile și istoricul rulărilor stau în volumul Postgres. Fă un dump după un program și păstrează copia în afara serverului — conexiunile conțin tokenurile tale API pentru alte servicii.
- Pașii de cod nu rulează în sandbox în această configurație (
AP_EXECUTION_MODE=UNSANDBOXED). E serverul tău și sunt fluxurile tale, deci e acceptabil. Încetează să fie din momentul în care lași oameni în care nu ai încredere să construiască fluxuri.
Dacă știi deja n8n, ideea e aceeași — vezi VPS pentru n8n. Alege editorul în care gândești mai ușor; amândouă se simt bine pe aceleași planuri.
Articole conexe
- VPS pentru n8n — celălalt mare instrument de automatizare găzduit pe serverul tău
- Mai multe servicii pe un singur VPS — Activepieces lângă aplicația ta și un panou, un singur IP
- VPS pentru Docker
- Cum adaugi swap pe un VPS
- Cum configurezi un firewall ufw
Comentarii
Încă nu există comentarii. Fii primul.