שרת VPS ל-Activepieces: אוטומציה בשרת משלכם

שירותי אוטומציה מאוחסנים גובים לפי משימה, והמונה רץ גם על דברים שבכלל אינם עבודה. זרימה שבודקת פיד כל חמש דקות היא 8,640 הרצות בחודש עוד לפני שעשתה משהו מועיל. הריצו את אותה זרימה על שרת משלכם, והחשבון הוא השרת.

‏Activepieces הוא בונה אוטומציות בקוד פתוח: טריגרים, צעדים, הסתעפויות, כמה מאות אינטגרציות מוכנות, וגם צעדי קוד כשהמוכנות לא מספיקות. מהדורת ה-community ברישיון MIT ורצה בלי בעיה על שרת קטן אחד עם Docker Compose.

איזו תוכנית

התקנו אותו על שרת בדיקה ומדדנו. קובץ ה-compose שמגיע כברירת מחדל מפעיל את האפליקציה וחמישה workers: כ-2.6–3 GB RAM יחד עם Postgres ו-Redis. עם worker אחד זה יורד לכ-1.6 GB.

בחרו תוכנית עם IPv4 משלה. ה-webhooks הם הסיבה העיקרית לארח את זה בעצמכם, והשירותים שקוראים להם חייבים להגיע לפורטים 80 ו-443; בתוכניות NAT אפשר להגיע מבחוץ רק לפורט ה-SSH. המיקומים הם גרמניה ופינלנד, והזמינות מוצגת בזמן ההזמנה. אפשר לשלם בקריפטו, בלי KYC.

התקנה

קודם הפנו דומיין — נניח flows.example.com — לשרת. אחר כך, כ-root על Ubuntu 24.04 או 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 מעתיק את .env.example ל-.env וממלא סודות אקראיים. לפני ההפעלה הראשונה שנו שתי שורות ב-.env ואחת בקובץ ה-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

השורה הראשונה היא החשובה. ‏AP_FRONTEND_URL הוא לא רק בשביל קישורים בממשק: דרכו ה-workers מתחברים לאפליקציה. השאירו http://localhost:8080 וכל קונטיינר worker יחפש את האפליקציה בתוך עצמו, לא ימצא, והזרימות שלכם לעולם לא יתפרסמו. בדיוק בזה נתקלנו: «Socket.IO connection error» בלוגים של ה-worker, בקשת פרסום שנתקעה ו-webhooks שענו 404. עם הדומיין האמיתי אותה זרימה התפרסמה וה-webhook רץ.

הפקודה sed על docker-compose.yml משאירה את פורט 8080 על localhost. פורטים ש-Docker מפרסם עוקפים את ufw, כך שבלעדיה האפליקציה הייתה פתוחה על פורט חשוף לצד ה-HTTPS שלכם.

ב-Micro-IP רדו גם ל-worker אחד:

sed -i 's/replicas: 5/replicas: 1/' docker-compose.yml

עכשיו HTTPS והפעלה:

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

חכו חצי דקה, פתחו את https://flows.example.com וצרו מיד את החשבון שלכם. מי שנרשם ראשון הוא בעל הפלטפורמה; אחר כך ההרשמה היא בהזמנה בלבד.

בדקו שה-webhooks עובדים

צרו זרימה עם הטריגר Webhook ‏(Catch Webhook), הוסיפו צעד כלשהו ופרסמו. לוח הטריגר מציג את ה-URL. שלחו אליו אירוע בדיקה:

curl -X POST https://flows.example.com/api/v1/webhooks/YOUR_FLOW_ID \
  -H 'content-type: application/json' \
  -d '{"event":"payment.paid","amount":16}'

אתם אמורים לקבל 200, וההרצה תופיע תחת Runs כמוצלחת. אם קיבלתם 404 במקום זה, חזרו ובדקו את AP_FRONTEND_URL.

לטווח הארוך

• עדכונים. קובץ ה-compose מקבע גרסה מדויקת (0.92.2 בזמן הכתיבה). שנו את התג ב-docker-compose.yml, ואז docker compose -p activepieces pull && docker compose -p activepieces up -d. עברו קודם על ה-release notes; כלי אוטומציה אוהבים לשנות שמות.
• גיבויים. זרימות, חיבורים והיסטוריית הרצות יושבים ב-volume של Postgres. בצעו dump לפי לוח זמנים ושמרו את העותק מחוץ לשרת — החיבורים מחזיקים את טוקני ה-API שלכם לשירותים אחרים.
• צעדי קוד לא רצים ב-sandbox בתצורה הזו (AP_EXECUTION_MODE=UNSANDBOXED). זה השרת שלכם והזרימות שלכם, אז זה מקובל. זה מפסיק להיות מקובל ברגע שאתם נותנים לאנשים שאינכם סומכים עליהם לבנות זרימות.

אם אתם כבר מכירים את n8n, הרעיון זהה — ראו שרת VPS ל-n8n. בחרו את העורך שבו קל לכם יותר לחשוב; שניהם מרגישים טוב על אותן תוכניות.

קשור

• שרת VPS ל-n8n: כלי האוטומציה הגדול השני לאחסון עצמי
• כמה שירותים על VPS אחד: ‏Activepieces לצד האפליקציה שלכם ולוח בקרה, IP אחד
• שרת VPS ל-Docker
• איך מוסיפים swap ב-VPS
• איך להגדיר חומת אש ufw