פורסם

Woodpecker CI

מנוע CI/CD קל: השרת מקבל webhooks משרת ה-Git שלכם (Gitea, ‏Forgejo, ‏GitHub, ‏GitLab, ‏Bitbucket), וה-agents מריצים כל שלב ב-pipeline ב-container משלו. מתאים לצוות שכבר מארח את הקוד שלו ורוצה pipelines פשוטים ב-YAML על חומרה משלו.

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

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

רמה	מה זה אומר	דרישות האפליקציה	מומלץ
קלהערכה	עד 5 משתמשים ו-10 מאגרים, כ-20 pipelines ביום, workflow אחד בכל פעם (WOODPECKER_MAX_WORKFLOWS=1, ברירת המחדל) שמריץ lint ובדיקות יחידה; ‏SQLite.	1.25 vCPU · 4.95 GiB RAM · 14.3 GiB דיסק	1.62 vCPU · 7.44 GiB RAM · 25.875 GiB דיסק
בינוניהערכה	עד 20 משתמשים ו-50 מאגרים, כ-100 pipelines ביום, 2 workflows במקביל על agent אחד (MAX_WORKFLOWS=2) שמקמפלים קוד ובונים images של Docker; ‏SQLite.	4.5 vCPU · 15.5 GiB RAM · 31.4 GiB דיסק	5.52 vCPU · 20.1 GiB RAM · 45.54 GiB דיסק
כבדהערכה	עד 50 משתמשים ו-200 מאגרים, כ-400 pipelines ביום, 4 workflows במקביל על agent אחד עם builds מלאים ובדיקות אינטגרציה; ‏SQLite (מומלץ PostgreSQL, שלא נכלל בחישוב).	9 vCPU · 31 GiB RAM · 72.4 GiB דיסק	10.92 vCPU · 38.7 GiB RAM · 92.69 GiB דיסק

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

לחישוב ב-Stack Sizer

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

רמת תמיכה התקנה רשמית

אין תבנית Compose של ANAROQ: מתקינים בדרך הרשמית.

למה: ה-agent מפעיל כל שלב ב-pipeline על Docker daemon של המארח, ולכן ה-Compose הרשמי מחבר את ‎/var/run/docker.sock: גישה ששקולה ל-root, שה-Generator אף פעם לא כותב וה-Analyzer מסמן כ-AQ-VOL-001 ‏(high). צריך גם אפליקציית OAuth ב-forge ו-WOODPECKER_AGENT_SECRET משותף. תנו לו שרת או VM משלו: ‏pipelines מריצים קוד מהמאגר עם גישה ל-Docker של המארח ובלי מגבלות משאבים כברירת מחדל.

להתקנה הרשמית של Woodpecker CI

רכיבים

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

vCPU / GiB RAM / GiB דיסק
רכיב	קל	בינוני	כבד	מקורות
Woodpecker server (web UI, API, webhooks, scheduler) (app)	0.25 / 0.25 / 1.1	0.5 / 0.5 / 5.1	1 / 1 / 20.1	[2][3][12][20][27]
Woodpecker agent with its pipeline containers (Docker backend) (worker)	1 / 4.7 / 13.2	4 / 15 / 26.3	8 / 30 / 52.3	[4][5][12][19][22][24][26][27]

איך ההערכות מחושבות

Woodpecker server (web UI, API, webhooks, scheduler) · קל: אין מספר עומס רשמי; ה-README מציין כ-100 MB RAM במנוחה (0.093 GiB). ‏×2.5 ל-webhooks, לממשק, להזרמת הלוגים של workflow אחד שרץ ול-cache של SQLite ← 0.25 GiB ורבע ליבה. Disk: ‏image דחוס 21,255,672 B ‏(0.020 GiB) ועוד 61,089,280 B פרוס (0.057 GiB), ה-containerd store שומר את שניהם = ‏0.077 GiB. ‏0.077 ועוד 1 GiB למסד הנתונים (משתמשים, מאגרים ולוגים של pipelines, שנשמרים במסד כברירת מחדל) ← 1.1.
Woodpecker server (web UI, API, webhooks, scheduler) · בינוני: פי 2 מ-light: פי שניים workflows במקביל שמזרימים לוגים, יותר אירועי webhook ומשתמשים בממשק, וקובץ SQLite גדול יותר ב-cache ← 0.5 GiB וחצי ליבה. Disk: ‏image דחוס 21,255,672 B ‏(0.020 GiB) ועוד 61,089,280 B פרוס (0.057 GiB), ה-containerd store שומר את שניהם = ‏0.077 GiB. ‏0.077 ועוד 5 GiB למסד, בעיקר לוגים של pipelines ← 5.1.
Woodpecker server (web UI, API, webhooks, scheduler) · כבד: פי 2 מ-medium ל-4 הזרמות לוגים במקביל, כ-400 pipelines ביום ועד 50 משתמשים ← 1 GiB וליבה אחת; ‏SQLite כותב בטור, ולכן upstream ממליצים על PostgreSQL או MariaDB בהתקנות גדולות. Disk: ‏image דחוס 21,255,672 B ‏(0.020 GiB) ועוד 61,089,280 B פרוס (0.057 GiB), ה-containerd store שומר את שניהם = ‏0.077 GiB. ‏0.077 ועוד 20 GiB למסד ← 20.1.
Woodpecker agent with its pipeline containers (Docker backend) · קל: ה-containers של השלבים רצים במארח של ה-agent, והגודל שלהם תלוי ב-pipelines שלכם; ‏Woodpecker לא מפרסמים מספר. תקציב ל-workflow אחד (MAX_WORKFLOWS=1) בגודל ה-runner ‏ubuntu-slim של GitHub למשימות קלות: ‏1 CPU, ‏5 GB RAM ‏(4.657 GiB), ‏14 GB SSD ‏(13.039 GiB). ‏RAM: ‏4.657 ועוד 0.028 ל-agent במנוחה (30 MB) ← 4.7. Images: ‏agent דחוס 17,174,205 B ועוד 62,571,008 B פרוס = ‏0.074 GiB, ועוד plugin-git 2.10.1 (שלב ה-clone של כל workflow כברירת מחדל) 0.070 GiB = ‏0.144 GiB. ‏Disk: ‏0.144 ועוד 13.039 ← 13.2.
Woodpecker agent with its pipeline containers (Docker backend) · בינוני: ‏2 workflows בו-זמנית, כל אחד בגודל ה-runner הסטנדרטי של GitHub ל-Linux במאגרים פרטיים (2 CPU, ‏8 GB RAM = ‏7.451 GiB, ‏14 GB SSD = ‏13.039 GiB), כי קומפילציה ובניית images צריכות runner מלא. ‏vCPU: ‏2 × 2 = 4. ‏RAM: ‏2 × 7.451 ועוד 0.028 (agent במנוחה) = 14.93 ← 15. Images: ‏agent דחוס 17,174,205 B ועוד 62,571,008 B פרוס = ‏0.074 GiB, ועוד plugin-git 2.10.1 (שלב ה-clone של כל workflow כברירת מחדל) 0.070 GiB = ‏0.144 GiB. ‏Disk: ‏0.144 ועוד 2 × 13.039 ← 26.3.
Woodpecker agent with its pipeline containers (Docker backend) · כבד: ‏4 workflows בו-זמנית (MAX_WORKFLOWS=4), כל אחד בגודל runner סטנדרטי של GitHub ל-Linux במאגרים פרטיים (2 CPU, ‏7.451 GiB RAM, ‏13.039 GiB SSD). ‏vCPU: ‏4 × 2 = 8. ‏RAM: ‏4 × 7.451 ועוד 0.028 (agent במנוחה) = 29.832 ← 30. Images: ‏agent דחוס 17,174,205 B ועוד 62,571,008 B פרוס = ‏0.074 GiB, ועוד plugin-git 2.10.1 (שלב ה-clone של כל workflow כברירת מחדל) 0.070 GiB = ‏0.144 GiB. ‏Disk: ‏0.144 ועוד 4 × 13.039 ← 52.3. עבודה מקבילית נוספת עדיף לפזר על עוד agents.

פורטים

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

רכיב	פורט	חשיפה	שימוש	מקורות
Woodpecker server (web UI, API, webhooks, scheduler)	8000/tcp	ציבורי, דרך proxy	Web UI, API and forge webhooks (HTTP); serve through an HTTPS reverse proxy	[1][3][21]
Woodpecker server (web UI, API, webhooks, scheduler)	9000/tcp	פנימי בלבד	gRPC for agents; plain text by default, put TLS in front (h2c proxy) before remote agents use it	[1][3][4]
Woodpecker agent with its pipeline containers (Docker backend)	3000/tcp	פנימי בלבד	Agent health endpoint (/healthz) used by the image's HEALTHCHECK	[4][18][23]

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

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

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

רכיב	UID:GID	משתמש	מתחיל כ-root	כותב אל	מקורות
Woodpecker server (web UI, API, webhooks, scheduler)	1000:1000	`woodpecker`	לא	`/var/lib/woodpecker`	[10][14][16][21]
Woodpecker agent with its pipeline containers (Docker backend)	0:0	`root`	לא	`/etc/woodpecker`	[10][15][16][23]

Woodpecker server (web UI, API, webhooks, scheduler): מגרסה 3.0 ה-image של השרת רץ כ-woodpecker ‏(1000:1000) ו-‎/var/lib/woodpecker כבר בבעלותו, כך ש-named volume עובד; ‏bind mount מ-2.x צריך chown -R 1000:1000.
Woodpecker agent with its pipeline containers (Docker backend): ה-image של ה-agent לא מגדיר USER ונשאר root בכוונה: עם ה-backend של Docker הוא חייב להשתמש ב-socket של Docker שמחובר אליו. ב-‎/etc/woodpecker נשמר agent.conf עם המזהה שהשרת הקצה.

צמיחת אחסון

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

GiB לחודש
רכיב	קל	בינוני	כבד	מקורות
Woodpecker server (web UI, API, webhooks, scheduler)הנחה	0.117	0.586	2.344	[3]
Woodpecker agent with its pipeline containers (Docker backend)הנחה	1.953	4.883	9.766	[5]

על מה מספרי הצמיחה נשענים

Woodpecker server (web UI, API, webhooks, scheduler): לוגים של pipelines נשמרים במסד כברירת מחדל (WOODPECKER_LOG_STORE=database), ו-Woodpecker אף פעם לא מארכב או מוחק נתונים ישנים. הנחה: ‏0.2 MiB של לוגים ל-pipeline × 20 pipelines ביום × 30 יום; אין מקור שמציין גודל לוג.
Woodpecker server (web UI, API, webhooks, scheduler): לוגים של pipelines נשמרים במסד כברירת מחדל (WOODPECKER_LOG_STORE=database), ו-Woodpecker אף פעם לא מארכב או מוחק נתונים ישנים. הנחה: ‏0.2 MiB של לוגים ל-pipeline × 100 pipelines ביום × 30 יום; אין מקור שמציין גודל לוג.
Woodpecker server (web UI, API, webhooks, scheduler): לוגים של pipelines נשמרים במסד כברירת מחדל (WOODPECKER_LOG_STORE=database), ו-Woodpecker אף פעם לא מארכב או מוחק נתונים ישנים. הנחה: ‏0.2 MiB של לוגים ל-pipeline × 400 pipelines ביום × 30 יום; אין מקור שמציין גודל לוג.
Woodpecker agent with its pipeline containers (Docker backend): ה-agent אף פעם לא מוחק images של שלבים שהוא מוריד; הניקוי נשאר למארח. הנחה: ‏10 גרסאות image חדשות בחודש × 200 MiB, עד ש-cron במארח מריץ docker image prune ומוחק volumes יתומים בשם wp_*.
Woodpecker agent with its pipeline containers (Docker backend): ה-agent אף פעם לא מוחק images של שלבים שהוא מוריד; הניקוי נשאר למארח. הנחה: ‏25 גרסאות image חדשות בחודש × 200 MiB, עד ש-cron במארח מריץ docker image prune ומוחק volumes יתומים בשם wp_*.
Woodpecker agent with its pipeline containers (Docker backend): ה-agent אף פעם לא מוחק images של שלבים שהוא מוריד; הניקוי נשאר למארח. הנחה: ‏50 גרסאות image חדשות בחודש × 200 MiB, עד ש-cron במארח מריץ docker image prune ומוחק volumes יתומים בשם wp_*.

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

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

קודם גיבוי

עוצרים את השרת ומעתיקים את כל ה-volume של ‎/var/lib/woodpecker ‏(woodpecker.sqlite); אין ב-image ‏shell או sqlite3. עם PostgreSQL או MariaDB לוקחים dump בכלים של המסד עצמו. [1][3][14]

שלבי השדרוג

קוראים את עמוד ה-Migrations ואת ה-changelog של כל גרסה שמדלגים עליה, ואז לוקחים את הגיבוי שבהמשך. [10][11]
מגדירים את אותו tag חדש vX.Y.Z בשרת ובכל agent, ואז docker compose pull ו-docker compose up -d. מגרסה 3.18 השרת דוחה agents עם גרסת gRPC לא תואמת, ולכן משדרגים אותם יחד. [2][11]
השרת מריץ migrations על המסד בהפעלה; טבלת לוגים גדולה יכולה להאט את זה (למשל ניקוי הכפילויות בלוגים של 3.18). מחכים שה-container יהיה healthy ושה-agents יופיעו כמחוברים ב-Settings > Agents. [3][11][17]
מ-1.x עוברים קודם ל-2.x: ‏3.0 מקבל שדרוג רק מ-2.x. אחרי 2.x ← 3.x לוחצים על Repair all בהגדרות ה-admin כדי לחדש את ה-tokens של ה-webhooks, ומעבירים את ה-pipelines לתחביר של 3.x. [10][11]

חזרה לאחור

עוצרים את השרת ואת ה-agents, משחזרים את הגיבוי שנלקח לפני השדרוג, מצמידים את ה-tag הקודם בכולם ומריצים docker compose up -d. [3]נגזר‏upstream לא מתעדים downgrade. השרת משדרג את המסד אוטומטית בהפעלה, ולכן binary ישן על מסד שעבר migration אינו בטוח; שחזור הגיבוי מלפני השדרוג כן.

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

בגרסה 3.18.0: השרת דוחה agents עם גרסת פרוטוקול gRPC לא תואמת. ‏WOODPECKER_GRPC_VERIFY הפך ל-WOODPECKER_GRPC_SKIP_VERIFY עם משמעות הפוכה (true מדלג עכשיו על האימות), וקבוצות GitLab ב-WOODPECKER_ORGS מותאמות לפי הנתיב המלא. [3][10][11]
בגרסה 3.0.0: אין tag ‏latest; ה-images רצים כ-UID 1000 ‏(chown ל-bind mounts); אף plugin לא privileged כברירת מחדל, ולכן docker-buildx צריך להופיע ב-WOODPECKER_PLUGINS_PRIVILEGED; ה-webhooks צריכים Repair all; התמיכה המובנית ב-Let's Encrypt הוסרה; שדרוג רק מ-2.x. [10][11]
בגרסה 3.0.0: תחביר pipelines: ‏secrets: הוסר (משתמשים ב-environment עם from_secret), ‏environment חייב להיות map, ‏cron בתחביר הסטנדרטי של 5 שדות, ו-pipelines מ-forks ממתינים לאישור כברירת מחדל. [10][11]

מגבלות

המספרים של ה-agent כוללים את ה-containers של ה-pipelines, לפי תקציב מגודלי ה-runners של GitHub; הצורך האמיתי תלוי במה שה-pipelines בונים. המגבלות של ה-backend של Docker כבויות כברירת מחדל (WOODPECKER_BACKEND_DOCKER_LIMIT_MEM ו-_CPU_QUOTA = 0), כך ש-build כבד אחד יכול לתפוס את כל המארח. [4][5][26]
ל-Woodpecker אין חשבונות משלו: המשתמשים מתחברים דרך forge ‏(GitHub, ‏Gitea, ‏Forgejo, ‏GitLab או Bitbucket) עם אפליקציית OAuth שרושמים בו. אפשר להגדיר מהסביבה רק forge אחד; כמה forges יחד הם ניסיוניים. [3][7]
עם Gitea מהקטלוג: יוצרים ב-Gitea אפליקציית OAuth עם callback ‏https://<woodpecker-host>/authorize, מגדירים WOODPECKER_GITEA=true, ‏_URL, ‏_CLIENT ו-_SECRET, ובאותו מארח מחברים את ה-agent לרשת של Gitea ‏(WOODPECKER_BACKEND_DOCKER_NETWORK) ומאפשרים ב-Gitea ‏webhooks מקומיים. [6]
‏agent אחד מריץ כברירת מחדל workflow אחד בכל פעם (WOODPECKER_MAX_WORKFLOWS=1); לעבודה מקבילית מעלים את הערך או מוסיפים agents. ‏SQLite הוא ברירת המחדל; בהתקנות גדולות upstream ממליצים על PostgreSQL או MariaDB, שצריך ליצור בעצמכם ושלא נכללו בחישוב. [2][3][4]
ה-backend של Docker דורש מארח Linux ל-agent. ה-images של השרת ושל ה-agent נבנים ל-amd64, ל-arm64 ולארכיטקטורות Linux נוספות. [9]

אבטחה

ה-agent מחבר את ‎/var/run/docker.sock כדי להפעיל containers של שלבים. זו גישה ששקולה ל-root על המארח, בדיוק מה שה-Analyzer של ANAROQ מסמן כ-AQ-VOL-001 ‏(high); כאן היא נדרשת. מריצים את ה-agent על שרת או VM ייעודיים ובונים רק מאגרים שסומכים עליהם. [1][10]
ההרשמה סגורה כברירת מחדל, אבל דוגמת ה-Compose הרשמית מגדירה WOODPECKER_OPEN=true. משאירים false (או מגבילים עם WOODPECKER_ORGS) ומגדירים את ה-admins ב-WOODPECKER_ADMIN. [1][3]
מסמנים מאגר כ-trusted רק כשצריך: ‏pipelines מסוג trusted מקבלים הרשאות מורחבות כמו mount של volumes. משאירים את WOODPECKER_PLUGINS_PRIVILEGED ריק (ברירת המחדל ב-3.x) או מציינים tags מדויקים, ושומרים על אישור ל-pull requests מ-forks. [3][8][10]
‏WOODPECKER_AGENT_SECRET משותף לשרת ול-agents; יוצרים אותו עם openssl rand -hex 32. ‏gRPC על פורט 9000 בלי TLS כברירת מחדל: משאירים אותו פנימי, או שמים TLS לפניו לפני ש-agents מתחברים דרך האינטרנט. [1][3][4]
כברירת מחדל כל admin של מאגר יכול לרשום agent למאגרים שלו. אם מחזיקים secrets ברמת ה-instance, מגדירים WOODPECKER_DISABLE_USER_AGENT_REGISTRATION=true כדי שאף אחד לא יחבר agent זדוני שיקרא אותם. [3]

גיבוי

מגבים את ‎/var/lib/woodpecker: ‏woodpecker.sqlite מחזיק משתמשים, מאגרים, secrets ולוגים של pipelines, ו-Woodpecker לא מגבה בעצמו. מעתיקים כשהשרת עצור, או משתמשים ב-sqlite3 .backup במארח; אין sqlite3 ב-image. [1][3][14]
עם PostgreSQL או MariaDB מגבים בכלים של המסד עצמו. שומרים יחד עם הגיבוי את ערכי ה-‎.env ‏(WOODPECKER_AGENT_SECRET, ה-client וה-secret של ה-OAuth ב-forge); ב-‎/etc/woodpecker של ה-agent יש רק את המזהה שלו, ו-workspaces של pipelines הם זמניים. [1][3][4]