פורסם

Activepieces

פלטפורמת אוטומציה ללא קוד: flows שנבנים מטריגרים ומ-"pieces" (אינטגרציות), ‏webhooks, תזמונים, צעדי Code וסוכני AI. מתאימה לצוותים שרוצים עורך flows נוח גם למשתמשים עסקיים, על שרת משלהם. הפריסה העצמית כוללת קונטיינר app, ‏worker נפרד שמריץ את ה-flows, ‏PostgreSQL ו-Redis.

משאבים לפי רמת עומס

מה האפליקציה עצמה צריכה בכל רמה, לצד מה שאנחנו ממליצים לשרת שמריץ רק אותה.

רמהמה זה אומרדרישות האפליקציהמומלץ
קלהערכהעד 5 בוני flows, ‏20 flows פעילים, כ-500 הרצות ביום, flow אחד רץ בכל רגע, ‏payloads מתחת ל-1 MB; ‏worker אחד, קבצים ב-PostgreSQL.2.25 vCPU · 3.5 GiB RAM · 9.25 GiB דיסק2.82 vCPU · 5.7 GiB RAM · 20.298 GiB דיסק
בינוניהערכהעד 20 בוני flows, ‏100 flows פעילים, כ-5,000 הרצות ביום, עד 3 flows רצים במקביל, ‏payloads של MB בודדים; ‏worker אחד ב-concurrency ברירת המחדל 5.4.75 vCPU · 8.5 GiB RAM · 54.75 GiB דיסק5.82 vCPU · 11.7 GiB RAM · 72.623 GiB דיסק
כבדהערכהעד 50 בוני flows, ‏300 flows פעילים, כ-25,000 הרצות ביום, 5 flows רצים במקביל (ה-concurrency ברירת המחדל של ה-worker והמגבלה לפרויקט); מעבר לזה, הוסיפו workers.6 vCPU · 11 GiB RAM · 56.25 GiB דיסק7.32 vCPU · 14.7 GiB RAM · 74.348 GiB דיסק

מומלץ = דרישות האפליקציה + baseline של המערכת + מרווח ביטחון (headroom), לפי מדיניות ה-sizing ‏2026.10.0. האפשרויות נשארות בברירת המחדל. ״הערכה״ פירושה שהמקורות לא נותנים מספר למקרה הזה, ולכן הוא מחושב מהם בשיטה שמפורטת תחת רכיבים. איך המספרים נבנים

לחישוב ב-Stack Sizer

קבצים מוכנים להפעלה

רמת תמיכה נתמך

תבנית Compose מהמקורות הרשמיים; עוד לא נבדקה בהרצה.

צור docker-compose

רכיבים

מה כל רכיב צריך בכל רמת עומס, לפני baseline ו-headroom.

vCPU / GiB RAM / GiB דיסק
רכיבקלבינוניכבדמקורות
Activepieces (app: API and UI) (app)0.5 / 1 / 1.51 / 1 / 1.51 / 1 / 1.5[7][10][11][26]
Activepieces worker (worker)0.5 / 1 / 0.51.5 / 3 / 12.5 / 5 / 2[6][9][10][12]
PostgreSQL (database)1 / 1 / 6.52 / 4 / 51.52 / 4 / 51.5[9][12][34][35][36][37][38][39][40]
Redis (BullMQ job queue) (queue)0.25 / 0.5 / 0.750.25 / 0.5 / 0.750.5 / 1 / 1.25[9][10][11][29]
איך ההערכות מחושבות
  • Activepieces (app: API and UI) · קל: RAM: גודל ה-app המתועד של 1 GB ‏(GB נספר כ-GiB). ‏vCPU: ה-app המתועד הוא 1 vCPU לכל עשרה workers, וב-benchmark צרך 0.52-0.61 core ל-pod ביותר מ-20 בקשות בשנייה; flow פעיל אחד בכל רגע צריך כחצי. Disk: ‏image של 1,456,418,304 B אחרי פריסה (1.356 GiB), מעוגל ל-1.5 GiB; אין volume לנתונים, כל המצב נשמר ב-PostgreSQL.
  • Activepieces (app: API and UI) · בינוני: גודל ה-app המתועד, 1 vCPU / 1 GB, שמשרת עד עשרה workers של flow אחד במקביל (GB נספר כ-GiB). Disk כמו ב-light: ‏image של 1.356 GiB אחרי פריסה, מעוגל ל-1.5 GiB.
  • Activepieces (app: API and UI) · כבד: גודל ה-app המתועד, 1 vCPU / 1 GB, מכסה עד עשרה workers של flow אחד במקביל; 5 flows במקביל נשארים בתוכו. Disk כמו ב-light: ‏1.5 GiB ל-image של 1.356 GiB אחרי פריסה.
  • Activepieces worker · קל: התיעוד מקצה ל-flow אחד שרץ במקביל 0.5 vCPU / 1 GB (כ-300 MB מהם תקורה של תהליך חם); flow אחד בכל רגע נותן 0.5 vCPU / 1 GiB. Disk: ‏0.5 GiB ל-volume של ה-cache של pieces ו-flows (הנחה של ANAROQ, אין נתון רשמי); ה-image הוא של ה-app, נמשך פעם אחת ונספר שם.
  • Activepieces worker · בינוני: ‏3 flows במקביל × 0.5 vCPU / 1 GB המתועדים ל-flow ‏= 1.5 vCPU / 3 GiB; כל תהליך engine ב-sandbox מוגבל ל-1 GiB ‏(AP_SANDBOX_MEMORY_LIMIT ‏1048576 KB). Disk: ‏volume של 1 GiB ל-cache, עבור יותר pieces ו-flows (הנחה של ANAROQ).
  • Activepieces worker · כבד: התיעוד נותן כ-2.5 vCPU / 5 GB ל-worker ב-concurrency 5 ‏(5 × 0.5 vCPU / 1 GB); ‏GB נספר כ-GiB. Disk: ‏volume של 2 GiB ל-cache עבור כ-300 flows וה-pieces שלהם (הנחה של ANAROQ).
  • PostgreSQL · קל: מסד metadata מובנה בהגדרות ברירת המחדל של ה-image: שווה ל-preset ה-light של פרופיל PostgreSQL ‏(עד 5 GB נתונים, עד 20 חיבורים בו-זמנית) בכל רמת עומס. שיטת ה-light: ‏shared_buffers ‏25% מה-RAM, תקציב work_mem ו-maintenance_work_mem למקרה הגרוע, 0.5 GiB ל-image ‏+ 5 GiB נתונים + 1 GiB ל-WAL.
  • PostgreSQL · בינוני: יומני הרצה, קבצי צעדים (AP_FILE_STORAGE_LOCATION=DB) ואירועים נשמרים 30 יום: ‏5,000 הרצות ביום × 30 × הנחה של 30 KB להרצה ≈ 4.5 GB, בקצה מעטפת ה-sidecar של 5 GB, ולכן preset ה-medium של פרופיל PostgreSQL ‏(עד 50 GB). השיטה שלו: ‏shared_buffers של 1 GiB ‏= 25%, תקציב work_mem למקרה הגרוע ל-100 חיבורים, 0.5 GiB ל-image ‏+ 50 GiB נתונים + 1 GiB ל-WAL.
  • PostgreSQL · כבד: שמירה של 30 יום: ‏25,000 הרצות ביום × 30 × הנחה של 30 KB להרצה ≈ 22.5 GB נתוני הרצות, בתוך preset ה-medium של פרופיל PostgreSQL ‏(עד 50 GB). לפי התיעוד, ה-CPU של מסד הנתונים גדל עם התפוקה (כ-2.5 millicores לבקשה בשנייה); 25,000 הרצות ביום הן בממוצע 0.29 הרצות בשנייה. שיטת medium: ‏shared_buffers של 1 GiB ‏= 25%, 0.5 GiB ל-image ‏+ 50 GiB נתונים + 1 GiB ל-WAL.
  • Redis (BullMQ job queue) · קל: התיעוד מקצה ל-Redis ‏1 vCPU / 1 GB לצי workers בייצור; ב-benchmark ‏Redis צרך 0.123 core ב-213 בקשות בשנייה, הרבה מעל הרמה הזו, ולכן 0.25 vCPU. ‏RAM: חצי מ-1 GB המתועד עבור התור, payloads של webhooks ששמורים inline ‏(פחות מ-512 KB כל אחד) ו-jobs שנכשלו (נשמרים 30 יום, עד 100,000). Disk: ‏image של 43.8 MiB דחוס × 3 ‏(131 MiB) ועוד snapshot מסוג RDB עד 0.5 GiB של נתונים, מעוגל ל-0.75 GiB.
  • Redis (BullMQ job queue) · בינוני: כמו ב-light: ב-benchmark ‏Redis צרך 0.123 core ב-213 בקשות בשנייה, עדיין הרבה מעל כ-5,000 הרצות ביום; 0.5 GiB ‏RAM ו-0.75 GiB דיסק (‏image של 131 MiB ועוד snapshot מסוג RDB).
  • Redis (BullMQ job queue) · כבד: RAM: ‏1 GB המתועדים (GB נספר כ-GiB). ‏vCPU: חצי מ-1 vCPU המתועד; ב-benchmark ‏Redis צרך 0.123 core ב-213 בקשות בשנייה. Disk: ‏image של 131 MiB ‏(43.8 MiB דחוס × 3) ועוד snapshot מסוג RDB עד 1 GiB של נתונים, מעוגל ל-1.25 GiB.

פורטים

פורטים ציבוריים נועדו לגישה מחוץ ל-stack, בדרך כלל דרך reverse proxy; פורטים פנימיים נשארים ברשת של ה-stack עצמו.

רכיבפורטחשיפהשימושמקורות
Activepieces (app: API and UI)80/tcpציבורי, דרך proxyUI, REST API, webhooks and the worker's API/Socket.IO endpoint (HTTP; put behind TLS)[2][23]
PostgreSQL5432/tcpפנימי בלבדPostgreSQL connections from the app[3][9]
Redis (BullMQ job queue)6379/tcpפנימי בלבדBullMQ job queue between the app and the workers[9][30]

כל הפורטים בקטלוג, עם התנגשויות בין אפליקציות

משתמש והרשאות (UID/GID)

המשתמש שהתהליך של כל קונטיינר רץ תחתיו, והנתיבים שהוא כותב אליהם. ‏bind mount לאחד הנתיבים האלה חייב להיות ניתן לכתיבה על ידי ה-UID:GID הזה.

רכיבUID:GIDמשתמשמתחיל כ-rootכותב אלמקורות
Activepieces (app: API and UI)נגזר0:0rootלא—[4][23]
Activepieces workerנגזר0:0rootלא/usr/src/app/cache[2][6][23]
PostgreSQL999:999postgresכן, מכין את התיקיות שלו ואז עובר למשתמש הזה/var/lib/postgresql/var/run/postgresql[32][33][39]
Redis (BullMQ job queue)999:999redisכן, מכין את התיקיות שלו ואז עובר למשתמש הזה/data[30][31]
  • Activepieces (app: API and UI): ה-Dockerfile לא מגדיר USER וה-User בהגדרות ה-image ריק, ולכן node רץ כ-root ‏(uid 0) ולא מוריד הרשאות. כש-AP_ENCRYPTION_KEY ו-AP_JWT_SECRET מוגדרים, ה-app לא כותב קבצים מקומיים; הכול נשמר ב-PostgreSQL.
  • Activepieces worker: אותו image כמו ה-app, ולכן root (אין USER ב-Dockerfile). ה-worker כותב את ה-cache של pieces ו-flows ל-'cache' תחת ה-WORKDIR ‏/usr/src/app, הנתיב שה-Compose הרשמי מחבר.

צמיחת אחסון

בכמה הנתונים של כל רכיב גדלים בחודש בכל רמת עומס, מעבר לדיסק שבפרופיל. ערך שמסומן ״הנחה״ הוא הנחה מוצהרת של ANAROQ ולא מספר מהמקורות; ההערות מפרטות על מה היא נשענת.

GiB לחודש
רכיבקלבינוניכבדמקורות
PostgreSQLהנחה0.050.20.5[9][12]
על מה מספרי הצמיחה נשענים
  • PostgreSQL: יומני הרצה, קבצי צעדים ואירועים נמחקים אחרי 30 יום (AP_EXECUTION_DATA_RETENTION_DAYS), ולכן נתוני ההרצות מתייצבים אחרי החודש הראשון. מה שממשיך לגדול: גרסאות flows, ‏connections, רשומות Tables ‏(עד 10,000 לטבלה) וערכי Store. ‏Activepieces לא מפרסם קצב גדילה; זו הנחה של ANAROQ.

שדרוג וחזרה לאחור

איך עוברים לגרסה חדשה בבטחה, ואיך חוזרים אחורה אם משהו נכשל.

קודם גיבוי

קחו קודם dump של מסד הנתונים (pg_dump של מסד activepieces) ושמרו לידו את ה-.env עם AP_ENCRYPTION_KEY. [7][20]

שלבי השדרוג

  1. קראו את ה-breaking changes של כל גרסה שאתם מדלגים עליה, מהחדשה לישנה. [7][21]
  2. הגדירו את אותו tag חדש של image גם ל-app וגם ל-worker: מאז 0.85.4 מנגנון הגנה דורש ששניהם ירוצו באותה גרסה. [7][21]
  3. הריצו docker compose pull ואז docker compose up -d. [7][20]נגזרהתיעוד משדרג עם סקריפט ההתקנה או בהעלאת ה-tag המוצמד ב-docker-compose.yml; ‏pull ו-up -d הם הדרך שבה Compose מחיל tag חדש.

חזרה לאחור

עצרו את ה-stack, הריצו את פקודת ה-rollback עם ה-image החדש (npm run rollback -- --to <גרסה ישנה>, ו-‎--force אם ב-release יש migrations שוברים), ואז החזירו את שני השירותים ל-tag הישן והפעילו. או שחזרו את ה-dump מלפני השדרוג. [20]

שינויים שוברים ידועים

  • בגרסה 0.92.0: קבצים שמועברים לצעדי AI ‏(Extract Structured Data, ‏Generate Image) מוגבלים ל-AP_MAX_FILE_SIZE_MB, ‏25 MB כברירת מחדל. [21]
  • בגרסה 0.90.4: ‏telemetry הוא הגדרה לכל platform בממשק הניהול; ‏AP_TELEMETRY_ENABLED הוא רק ערך ההתחלה שלה. [21]
  • בגרסה 0.88.2: ‏PM2 הוסר מה-image: תהליך שקרס או נהרג ב-OOM מסיים עכשיו את הקונטיינר, ולכן נדרשת מדיניות restart. [21]
  • בגרסה 0.85.4: ה-worker וה-app חייבים לרוץ על אותה גרסת image. [21]
  • בגרסה 0.80.0: ‏Nginx הוסר מה-image; ‏Fastify מגיש את הממשק ואת ה-API, כל נתיבי ה-API תחת ‎/api, ובדיקת הבריאות עברה ל-‎/api/v1/health. [21]

מגבלות

  • ‏worker אחד מריץ לכל היותר 5 flows במקביל (AP_WORKER_CONCURRENCY), וכל פרויקט מוגבל כברירת מחדל ל-5 הרצות במקביל. תפוקה גבוהה יותר דורשת עוד קונטיינרים של worker, שהתבנית לשרת יחיד לא מוסיפה. [9][10][14]
  • הרצה נעצרת אחרי 600 שניות של זמן פעיל, קבצים מוגבלים ל-25 MB ויומן הרצה ל-50 MB, ולתהליך worker יש תקציב זיכרון של 1 GB ‏(כ-300 MB מהם תקורה). פצלו משימות גדולות לכמה flows. [12]
  • צעדי Code רצים ב-V8 isolate ‏(SANDBOX_CODE_ONLY): בלי חבילות npm ובלי גישה ל-filesystem. מצבים שמאפשרים npm עם בידוד דורשים קונטיינר privileged, שהתבנית לא מעניקה. [13]
  • קבצים ונתוני הרצות נשמרים כברירת מחדל ב-PostgreSQL ‏(בלי S3), ול-PostgreSQL המובנה אין pgvector, ולכן ה-knowledge bases של סוכנים נשארים מוסתרים. [9][22][24]

אבטחה

  • הגישו את Activepieces ב-HTTPS דרך reverse proxy שמעביר WebSockets, והגדירו את AP_FRONTEND_URL לכתובת הציבורית הזו: ממנה נבנים ה-webhooks וה-app triggers, והרצות בדיקה צריכות את ה-WebSocket. [9][17][18]
  • קוד של flow יכול להגיע לכל מה שה-worker מגיע אליו (AP_NETWORK_MODE ברירת מחדל UNRESTRICTED), כולל ה-Redis של ה-stack, שאין לו סיסמה. אפשרו רק לאנשים מהימנים לבנות flows, או חסמו טווחים פנימיים בחומת האש. [16]
  • אין התחברות ברירת מחדל: החשבון הראשון שנוצר הופך למנהל ה-platform. צרו אותו מיד אחרי ההפעלה הראשונה. [7]

גיבוי

  • גבו את PostgreSQL ‏(pg_dump): ה-flows, ההרצות, ה-connections והתזמונים נשמרים שם, לא בתיקיית ההתקנה. שמרו איתו את AP_ENCRYPTION_KEY; בלי המפתח אי אפשר לפענח את ה-connections השמורים גם מגיבוי מלא. [7][19]
  • שמרו את ה-volume של Redis: ‏webhooks אסינכרוניים מאושרים ברגע שנכנסו לתור ב-Redis, לפני שיש להם רשומה ב-PostgreSQL, ולכן jobs שאבדו עם Redis אבדו לתמיד. כל השאר נבנה מחדש מ-PostgreSQL. [19]

גרסה אחרונה

הגרסה האחרונה של הפרויקט
Activepieces 0.92.3 [27][28]
הפרופיל נבדק מול

Activepieces 0.92.3

הפרופיל נבדק מול הגרסה האחרונה.

נבדק ב-
14 באוק׳ 2026
מצב
נבדק ב-90 הימים האחרונים
איפה הגרסאות מתפרסמות
תגיות ב-Docker Hub

הגרסאות האחרונות של כל האפליקציות

גרסה

סטטוס הפרופיל
פורסם
נבדק מול גרסה
Activepieces 0.92.3
גרסת הפרופיל
1.0.0
המספרים אומתו
14 באוק׳ 2026
גרסת הקטלוג
2026.10.10
מדיניות sizing
2026.10.0
קובץ Compose
לא אומת
האתר הרשמי
www.activepieces.com

מקורות

  1. Docker Docs: Control startup order in Compose (pg_isready healthcheck, service_healthy) (תיעוד רשמי · נקרא 11 באוק׳ 2026)
  2. activepieces repository: docker-compose.yml at 0.92.3 (app + worker replicas 5 + pgvector/pgvector:0.8.0-pg14 + redis:7.0.7; app 8080:80) (Compose רשמי · נקרא 14 באוק׳ 2026)
  3. activepieces repository: .env.example at 0.92.3 (AP_POSTGRES_HOST=postgres, AP_REDIS_HOST=redis, AP_EXECUTION_MODE=UNSANDBOXED) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  4. activepieces repository: docker-entrypoint.sh at 0.92.3 (AP_CONTAINER_TYPE, AP_PORT 80, AP_WORKER_TOKEN signed from AP_JWT_SECRET) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  5. activepieces repository: system-validator.ts at 0.92.3 (AP_ENCRYPTION_KEY must match ^[A-Za-z0-9]{32}$; AP_JWT_SECRET required) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  6. activepieces repository: worker configs.ts at 0.92.3 (a WORKER reaches the app at AP_FRONTEND_URL/api; concurrency default 5; cache dir 'cache') (מאגר רשמי · נקרא 14 באוק׳ 2026)
  7. Activepieces Docs: Self host (Docker Compose): 4 containers, at least 2 vCPU and 4 GB RAM, /api/v1/health, worker AP_FRONTEND_URL=http://app (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  8. Activepieces Docs: Install options (Docker Compose recommended; Activepieces Cloud) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  9. Activepieces Docs: Environment variables (AP_ENCRYPTION_KEY 32 hex chars; AP_WORKER_CONCURRENCY 5; retention 30 days; file storage DB) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  10. Activepieces Docs: Production setup (worker 0.5 vCPU / 1 GB per flow; app 1 vCPU / 1 GB; Redis 1 vCPU / 1 GB; concurrency 5 worker ~2.5 vCPU / 5 GB) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  11. Activepieces Docs: Benchmark (app ~0.52-0.61 core per pod; Redis 123m at 213 req/s; worker idle RSS ~145 Mi) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  12. Activepieces Docs: Limits (600 s run timeout, 1 GB worker memory with ~300 MB overhead, 25 MB files, 50 MB run log, 30-day retention) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  13. Activepieces Docs: Sandboxing (SANDBOX_CODE_ONLY unprivileged; SANDBOX_PROCESS needs CAP_SYS_ADMIN / privileged) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  14. Activepieces Docs: Workers (stateless, pull jobs from Redis, scale by replicas; default concurrency 5 is transitional) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  15. Activepieces Docs: Separate workers (worker needs AP_CONTAINER_TYPE, AP_FRONTEND_URL and a token from AP_JWT_SECRET; no DB or Redis access) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  16. Activepieces Docs: Network security (AP_NETWORK_MODE defaults to UNRESTRICTED; user code can reach Redis, Postgres, metadata) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  17. Activepieces Docs: HTTPS (terminate TLS in a reverse proxy, WebSocket upgrade) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  18. Activepieces Docs: Websocket issues (proxy must pass WebSockets; test runs and live updates need them) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  19. Activepieces Docs: Disaster recovery (Postgres is the system of record; queued async-webhook jobs exist only in Redis) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  20. Activepieces Docs: Rollback (pg_dump first; npm run rollback -- --to <version> with the newer image) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  21. Activepieces Docs: Breaking changes (0.92.0 back to 0.30.0) (Release notes · נקרא 14 באוק׳ 2026)
  22. Activepieces Docs: Agent knowledge (needs the pgvector extension; hidden when Postgres lacks it) (תיעוד רשמי · נקרא 14 באוק׳ 2026)
  23. activepieces repository: Dockerfile at 0.92.3 (node:24.14.0-bullseye-slim, no USER, HEALTHCHECK curl /api/v1/health, EXPOSE 80) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  24. activepieces repository: knowledge-base-schema.ts at 0.92.3 (CREATE EXTENSION vector only when available, otherwise skipped) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  25. activepieces repository: LICENSE at 0.92.3 (MIT Expat, except packages/ee and packages/server/api/src/app/ee under the Enterprise license) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  26. GHCR manifest of ghcr.io/activepieces/activepieces:0.92.3 (linux/amd64): 471,843,650 B compressed; layers decompressed and counted: 1,456,418,304 B (מדידה · נקרא 14 באוק׳ 2026)
  27. Docker Hub: activepieces/activepieces tags (newest 0.92.3, 2026-10-12; same index digest as GHCR 0.92.3) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  28. activepieces repository: git tags (newest release tag 0.92.3; its docker-compose.yml pins 0.92.3) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  29. Docker Hub: library/redis tag 7.4.11 (linux/amd64 45,896,305 B compressed) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  30. redis/docker-library-redis v7.4.11: debian Dockerfile (redis uid/gid 999, VOLUME /data, EXPOSE 6379, redis-cli) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  31. redis/docker-library-redis v7.4.11: debian docker-entrypoint.sh (chown, then setpriv to redis) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  32. docker-library/postgres: 18/trixie Dockerfile (postgres uid/gid 999, VOLUME /var/lib/postgresql) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  33. docker-library/postgres: 18/trixie docker-entrypoint.sh (chown PGDATA, then gosu postgres) (מאגר רשמי · נקרא 14 באוק׳ 2026)
  34. PostgreSQL 18 documentation: 19.4 Resource Consumption (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  35. PostgreSQL 18 documentation: 19.3 Connections and Authentication (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  36. PostgreSQL 18 documentation: 19.10 Vacuuming (autovacuum settings) (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  37. PostgreSQL 18 documentation: 19.5 Write Ahead Log (max_wal_size) (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  38. PostgreSQL 18 documentation: 51.2 How Connections Are Established (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  39. Docker Official Image postgres: documentation (docker-library/docs) (תיעוד רשמי · נקרא 10 באוק׳ 2026)
  40. Docker Hub: library/postgres tag 18.6 (compressed image sizes) (מאגר רשמי · נקרא 10 באוק׳ 2026)

כל אפליקציות ה-self-hosted