איזה שרת Git בניהול עצמי לבחור: Forgejo, Gitea או cgit

איזה שרת Git בניהול עצמי כדאי להריץ

שרת Git בניהול עצמי אינו מוצר יחיד, והזיכרון (RAM) בשרת ה-VPS שלכם קובע איזו גרסה תוכלו להריץ. Git אינו זקוק ל-daemon משלו: מאגר (repository) מסוג bare יחד עם חשבון SSH הוא כבר שרת עובד, גם על השרת הקטן ביותר שניתן לשכור. כל מה שמעבר לכך הוא יישום אינטרנט שאתם בוחרים להריץ לצד ה-Git, וכל עלייה ברמת המורכבות דורשת זיכרון שייתכן שאין ב-VPS קטן.

קיימים ארבעה שלבים. מאגר bare מעל SSH, ללא שירות נוסף שמאזין ברקע. cgit, ממשק אינטרנט מהיר לקריאה בלבד ללא מסד נתונים. Forgejo או Gitea, פלטפורמת פיתוח מלאה הכוללת חשבונות, ניהול משימות (issues) ו-pull requests, הצורכת כמה מאות מגה-בייטים. GitLab, הדורש שרת גדול משמעותית מהאחרים.

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

כמה זיכרון RAM כל אפשרות באמת צורכת

רק שניים מהפרויקטים הללו מפרסמים דרישות חומרה. התייחסו לנתון מפורסם כאל רף מינימלי ולא כאל הבטחה, ומדדו את המופע שלכם לאחר שהוא רץ, בעזרת systemd-cgtop או ps -o rss= -C forgejo.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea מתעדת 1 GB של זיכרון RAM עם 2 ליבות CPU ככמות שמספיקה בדרך כלל לצוותים ופרויקטים קטנים, ומציינת ש-Raspberry Pi 3 מספיק לעומסי עבודה קטנים. GitLab מתעדת 16 GB כבסיס להתקנת צומת בודד, ו-8 GB כרף התחתון למה שהדף שלהם מכנה סביבה מוגבלת זיכרון. Forgejo אינה מפרסמת דרישות חומרה כלל. היא מהווה fork של Gitea ומתנהגת באופן דומה, לכן הנתון של Gitea הוא המדריך המפורסם הקרוב ביותר שיש לכם.

המשמעות של זה בשרת VPS עם 1 GB זיכרון: מאגרים (repositories) חשופים ו-cgit יפעלו ויישאר מקום פנוי, כיוון שאף אחד מהם לא מריץ שירות תושב (resident service). Forgejo או Gitea יתחילו וישרתו צוות קטן על גבי SQLite, אך אתם נמצאים על הרף המינימלי המתועד, לכן השאירו את PostgreSQL ואת ה-CI (אינטגרציה רציפה) מחוץ לשרת הזה. אם ממשק האינטרנט נעלם ללא שגיאה, הריצו את sudo dmesg -T | grep -i oom וחפשו שורה כמו Out of memory: Killed process 1181 (forgejo), שמשמעותה היא ש-kernel out of memory killer סיים את התהליך. GitLab על שרת עם 1 GB אינה בעיית כוונון. היא פשוט לא תרוץ.

דרגה 0: מאגר (repository) חשוף מעל SSH

ל-Git אין daemon רשת שצריך להפעיל. git push מעל SSH מריץ את git-receive-pack בצד המרוחק כתהליך Unix רגיל, לכן כל חשבון שניתן לגשת אליו באמצעות מפתח הוא כבר Git remote. צרו חשבון אחד עבור המאגרים, ושמרו את המאגרים מחוץ לתיקיית הבית שלו, כיוון שב-Ubuntu 24.04 תיקיית בית חדשה נוצרת עם הרשאות 0750, וצפייה דרך האינטרנט שתוסיפו בהמשך לא תוכל לקרוא את תוכנה.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare יוצר מאגר ללא עותק עבודה (working copy), וזה מה ששרת אמור להחזיק. דחיפה (push) למאגר שיש לו עותק עבודה נדחית עם refusing to update checked out branch: refs/heads/main, וזו הטעות הנפוצה ביותר בדרגה זו.

כעת העניקו לחשבון מפתח ושכפלו (clone) אותו.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

דחיפה ראשונה שהצליחה מסתיימת ב-* [new branch] main -> main. דחיפה שמסתיימת ב-git@vps.example.com: Permission denied (publickey) לא עברה אימות, לכן קראו את לוג השרת עם sudo journalctl -u ssh -n 20. שורה המציגה Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys משמעותה שהרשאות הקובץ שגויות, כיוון ש-sshd מתעלם מקובץ מפתח שמשתמשים אחרים יכולים לכתוב אליו.

לאחר מכן, בטלו את הגישה ל-shell עבור החשבון.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell מקבל רק את הפקודות המעטות ש-Git שולח מעל SSH, לכן התחברות אינטראקטיבית כעת תיעצר עם הודעה במקום להציג prompt:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

זהו השרת כולו. אין מסד נתונים ואין תהליך web שצריך לשדרג. מה שאתם מוותרים עליו הוא כל מה שפלטפורמת ניהול קוד (forge) מספקת: אין דפדפן קבצים, אין מערכת מעקב אחר בעיות (issue tracker), אין pull requests ואין הרשאות ברמת המשתמש. כל מפתח בקובץ זה יכול לקרוא ולכתוב לכל מאגר שבבעלות המשתמש git.

רמה 1: cgit מספק תצוגת אינטרנט ללא מסד נתונים

cgit הוא תוכנית CGI‏ (Common Gateway Interface) הכתובה ב-C. שרת האינטרנט מריץ אותה פעם אחת עבור כל בקשה; היא קוראת את המאגרים ישירות מהדיסק ואינה שומרת מצב משל עצמה. הפצת Ubuntu 24.04 כוללת אותה ברכיב ה-universe.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

הפנו אותה אל ספריית המאגרים ב-/etc/cgitrc:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path סורק את הספרייה ומציג כל מאגר שהוא מוצא, כך שמאגר bare חדש מופיע ללא צורך בתצורה נוספת. cache-size הוא מספר הדפים השמורים ב-cache, וה-caching נשאר כבוי כל עוד הערך הוא אפס. קראו את מה שהחבילה שלכם כבר הציבה ב-/etc/cgitrc לפני שתוסיפו שורות, כיוון שהחבילות של Debian ו-Ubuntu כוללות הגדרות ברירת מחדל משלהן.

כל רשומה מציגה את השורה הראשונה של קובץ ה-description במאגר, לכן מאגר bare חדש יופיע כ-Unnamed repository; edit this file 'description' to name the repository.. תקנו זאת פעם אחת עבור כל מאגר:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

כדאי להכיר שתי מגבלות לפני שמסתמכים על כלי זה. cgit הוא לקריאה בלבד ואין בו מנגנון התחברות, לכן כל מה שנמצא תחת scan-path הוא ציבורי: הרחיקו מאגרים פרטיים מספרייה זו, או הציבו אימות HTTP בסיסי לפני האתר כולו. בנוסף, ה-CGI רץ תחת המשתמש של שרת האינטרנט, לכן משתמש זה חייב הרשאות מעבר ב-/srv/git וקריאה לכל מאגר. ספרייה שאין לו הרשאת כניסה אליה תופיע כאינדקס ריק במקום כהודעת שגיאה.

דרג 2: Forgejo או Gitea לניהול Issues ו-Pull Requests

Forgejo ו-Gitea מבוססים על אותו רעיון: קובץ binary יחיד בשפת Go המפעיל פלטפורמת פיתוח הכוללת משתמשים, ארגונים, Issues, Pull Requests, גרסאות (releases), מאגר חבילות ומערכת CI מובנית. ההתקנה מורכבת מה-binary וממסד נתונים SQLite בלבד, ולכן הם מתאימים לחומרה ש-GitLab לא תוכל להריץ. קובץ ה-Compose להלן הוא זה המופיע בתיעוד של Forgejo, עם תגית ה-image המצוינת בו נכון לאוגוסט 2026.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

הפקודה curl אמורה להדפיס שורת סטטוס HTTP. לפני שתסיימו את הגדרת ההרצה הראשונה, ייתכן שתקבלו הפניה (redirect) ל-/install, מה שמעיד על כך שהשירות פעיל. אם המכולה (container) קורסת במקום זאת, הסיבה הנפוצה היא בעיית בעלות: הספרייה ./forgejo חייבת להיות בבעלות ה-UID (מזהה משתמש) המוגדר ב-USER_UID, אחרת התהליך לא יוכל לכתוב לספריית הנתונים שלו. המדריך Docker Compose ב-VPS מכסה את מבנה הקבצים הזה ואת כללי הבעלות על ה-volumes במלואם.

שתי תשובות בדף ההגדרה הראשוני קובעות אם כתובות ה-clone יעבדו. פורט ה-SSH חייב להיות 222, כיוון שקובץ ה-Compose ממפה את פורט 222 במארח לפורט 22 במכולה, וה-domain חייב להיות השם שהמשתמשים יקלידו בפועל. טעות באחד מהם תגרום לכך שכל דף מאגר יציג פקודת clone שתיכשל עבור כל מי שיעתיק אותה. לאחר מכן, שניהם מופיעים בסעיף [server] בתוך app.ini, תחת המפתחות SSH_PORT, SSH_DOMAIN ו-ROOT_URL.

עבור מופע ציבורי, חשפו את פורט ה-web בכתובת ה-loopback בלבד ('127.0.0.1:3000:3000') והציבו לפניו nginx לצורך TLS (אבטחת שכבת תעבורה). Gitea מותקן באותה דרך מתוך ה-image של gitea/gitea, או כ-binary יחיד עם יחידת systemd אחת וקובץ app.ini אחד; הגרסה היציבה הנוכחית שלו היא 1.27.1 נכון לאוגוסט 2026.

הישארו עם SQLite כל עוד אתם יכולים. הוא שומר על המופע כתהליך אחד וקובץ אחד, והוא שורד אתחול ללא צורך בשירות נוסף לניטור. PostgreSQL מצדיק את עלותו כאשר כמה אנשים כותבים בו-זמנית, כיוון ש-SQLite מבצע סריאליזציה לכתיבות, והרצות CI ארוכות כותבות ללא הפסקה. שני הפרויקטים מאפשרים להעביר מופע קיים ל-PostgreSQL בשלב מאוחר יותר, כך שזו אינה החלטה סופית.

Forgejo או Gitea: מה ההבדל בפועל

השושלת משותפת. Gitea פוצלה מ-Gogs בשנת 2016. בסוף שנת 2022 עברו השליטה בדומיין ובסימן המסחרי של Gitea לידי חברה בשם Gitea Ltd, ומספר מתחזקים יחד עם Codeberg הקימו את Forgejo. הפרויקט Forgejo מופץ על ידי Codeberg e.V., עמותה ללא מטרות רווח הרשומה בגרמניה, ובשנת 2024 הוא עבר מרישיון MIT לרישיון GPLv3 (GNU general public license version 3). הפרויקט Gitea נשאר תחת רישיון MIT ומפותח עם תמיכה מסחרית מאחוריו.

ביום-יום, מערכות התכונות דומות מאוד. הנתיב ביניהן אינו כזה. הגרסה Forgejo v10.0, מינואר 2025, הייתה המהדורה האחרונה שיכלה לקלוט מסד נתונים של Gitea ישירות, וזאת רק מגרסה Gitea v1.22 ומטה. נכון לאוגוסט 2026, Gitea נמצאת בגרסה 1.27.1, כך שאין דרך נתמכת לביצוע מעבר ישיר (in-place) ממופע Gitea נוכחי ל-Forgejo. בחרו באחד מהם לפני שאתם ממלאים אותו בנתונים, והתייחסו לכל מעבר עתידי כאל ייצוא וייבוא מחדש.

כלל אצבע לבחירה: אם הממשל התאגידי חשוב לכם, או שאתם רוצים שהפרויקט יישאר תחת ארגון ללא מטרות רווח, הריצו את Forgejo. אם אתם מעדיפים בסיס התקנות רחב יותר ואפשרות לתמיכה מסחרית, הריצו את Gitea. שניהם מתוחזקים בקוד פתוח ומתעדכנים בתדירות גבוהה: Forgejo משחררת גרסה יציבה בכל שלושה חודשים וגרסת LTS (תמיכה לטווח ארוך) בכל שנה; נכון לאוגוסט 2026, הגרסה הנוכחית היא v16.0.2 וגרסת ה-LTS היא v15.0.6.

דרג 3: העלות של GitLab לפני שמתחילים לעבוד

GitLab CE היא מחלקה אחרת של תוכנה. מופע (instance) אחד הוא אוסף של שירותים הפועלים יחד: Puma עבור יישום ה-web, Sidekiq עבור משימות רקע, PostgreSQL, Redis, Gitaly עבור גישה למאגרים, ו-nginx בחזית. חבילת ה-Omnibus מתקינה את כולם יחד, מה שהופך את ההתקנה לפשוטה ואת רף צריכת הזיכרון לגבוה.

דף הדרישות של GitLab מגדיר 16 GB של RAM ו-8 vCPU כבסיס להתקנה על שרת יחיד, כאשר 8 GB מצוינים כרף תחתון בסביבות מוגבלות זיכרון. אותו דף מנחה לבטל את ה-swap, כיוון ששימוש ב-swap תחת עומס פוגע משמעותית בביצועי המופע. אלו הנתונים הרשמיים נכון לאוגוסט 2026, והם עלו עם השנים, לכן יש לעיין בדף שוב לפני שקובעים את גודל השרת.

בתמורה לתקציב הזה מקבלים יכולות ממשיות: registry למכולות, registry לחבילות, הרשאות ברמת פירוט גבוהה, תכונות תאימות וביקורת, ו-CI שנבחן בהיקפים גדולים. אם אף אחד בצוות שלכם לא יכול לציין פריט מהרשימה הזו שהם זקוקים לו ברבעון הקרוב, אתם משלמים על VPS גדול יותר מבלי לקבל דבר בתמורה.

מודל הגישה ב-SSH: משתמש git אחד ומפתחות רבים

כל שכבה כאן מבצעת אימות באותה הדרך. קיים חשבון Unix אחד בשם git, וכל מפתח ציבורי מוכנס לתוך ~/.ssh/authorized_keys של אותו חשבון. האימות מתבצע באמצעות המפתח. ההרשאות נקבעות לפי האפשרויות שאתם כותבים לפני המפתח באותה שורה.

שורה פשוטה של מפתח מעניקה למחזיק בו את כל ההרשאות של אותו חשבון. פקודה כפויה (forced command) מצמצמת את הגישה ל-Git בלבד:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

האפשרות restrict, הזמינה החל מ-OpenSSH 7.2, מבטלת במילה אחת העברת פורטים (port forwarding), העברת סוכן (agent forwarding), וכן הקצאת X11 ו-PTY (מסוף וירטואלי). הפקודה command= מחליפה את הבקשה של הלקוח בפקודה שציינתם, ו-Git עדיין עובד מכיוון שהוא שולח את הבקשה שלו בתוך $SSH_ORIGINAL_COMMAND.

מערכת ניהול מאגרים (forge) כותבת את הקובץ הזה עבורכם, וזהו ההבדל האמיתי בין שכבה 0 לשכבה 2. Forgejo ו-Gitea כותבים מחדש את authorized_keys עם שורה אחת לכל מפתח רשום, כאשר כל שורה נושאת פקודה כפויה המזהה את המפתח לפי ה-id שלו במסד הנתונים:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

הפקודה הכפויה הזו היא הדרך שבה חשבון Unix משותף הופך להרשאות לפי משתמש: key-3 מודיע למערכת הניהול איזה משתמש מתחבר, והיא בודקת את הרשאות המשתמש מול המאגר לפני שמתבצעת העברת אובייקטים כלשהי. אל תערכו ידנית את הקובץ הזה בשרת שמנוהל על ידי מערכת ניהול מאגרים, כיוון שהוא נכתב מחדש מתוך מסד הנתונים והשורה שלכם תימחק. מפתחות פריסה (deploy keys) פועלים באותו מנגנון: מפתח פריסה הוא מפתח SSH רגיל הרשום מול מאגר יחיד, בדרך כלל לקריאה בלבד, כאשר הבדיקה מתבצעת בתוך מערכת הניהול במקום ב-sshd.

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

האם ניתן להריץ GitHub Actions על שרת Git עצמאי?

ניתן להריץ תהליכי עבודה (workflows) הכתובים בתחביר של GitHub Actions, אך לא ניתן להריץ את GitHub עצמו. ב-Forgejo, התכונה Forgejo Actions זמינה כברירת מחדל החל מגרסה v1.21 והיא קוראת קובצי workflow מתוך .forgejo/workflows בכל מאגר. Gitea Actions פועל באותו אופן וקורא מתוך .gitea/workflows. שתי המערכות דורשות תוכנה נוספת, ה-runner, המותקנת ורשומה מול ה-instance שלכם באמצעות token מהגדרות הניהול. פעולות (actions) רבות שפורסמו ירוצו ללא שינוי; כל פעולה שקוראת ל-GitHub API או מצפה לתשתית שמתארחת ב-GitHub לא תעבוד.

היערכו לשתי השלכות. ה-runner מפעיל מכולה (container) עבור כל משימה, לכן הוא זקוק למנוע מכולות ולתקציב זיכרון משלו; זו הסיבה שהוא לא אמור לשבת על אותו שרת של 1 GB שבו נמצא ה-forge. בנוסף, ה-runner מבצע כל פקודה שמופיעה בקובץ ה-workflow, כפי שמצוין במפורש בתיעוד של Forgejo: ה-runner מבצע הרצת קוד מרחוק (remote code execution). הקצו לו מארח (host) נפרד ככל הניתן, או לכל הפחות משתמש ללא הרשאות מיוחדות (unprivileged user) ו-token רישום המוגבל למאגר אחד בלבד.

אם המאגרים שלכם נשארים ב-GitHub ואתם רק רוצים להריץ את החישובים על חומרה שבשליטתכם, מדובר בתצורה שונה עם שלבים אחרים: runner של GitHub Actions המתארח עצמאית מתחבר למאגר ב-GitHub ואינו זקוק לאף אחד מהשלבים הללו. אם אתם עדיין שוקלים את העלויות של עזיבת הפלטפורמה, מה GitHub באמת נותן לכם מפריד בין אירוח ה-Git לבין הרשת שסביבו.

גיבויים: מאגרים הם רק חצי מהמצב

מאגר (repository) מסוג bare הוא ספרייה, לכן העתקה שלו מעתיקה את כל תוכנו. שיבוט מסוג mirror ממכונה אחרת מהווה גיבוי אמיתי, והוא מתעדכן במקומו:

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

פעולה זו מושכת כל ref וכל אובייקט. היא אינה מושכת hooks בצד השרת או את הקובץ description, לכן שמרו גם עותק ברמת הקבצים של הספרייה אם אתם משתמשים ב־hooks.

פלטפורמת ניהול קוד (forge) שומרת issues, pull requests, משתמשים, מפתחות והרשאות בתוך מסד הנתונים שלה, ועותק של המאגרים בלבד משליך את כל המידע הזה. שני הפרויקטים מפיצים פקודת dump שכותבת את מסד הנתונים, המאגרים, התצורה והקבצים המצורפים לארכיון אחד:

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

תחת Docker אותה פקודה רצה בתוך המכולה, ונתיב התצורה תלוי ב־image, לכן בדקו היטב לפני ההקלדה:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

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

בחירה לפי תרחיש

אדם אחד עם מחשב נייד ושרת VPS, ללא צורך בדפדפן: השתמשו ב-bare repositories מעל SSH. אין שירות נוסף שרץ ואין מה לשדרג.

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

צוות שמבצע ביקורת קוד הדדית ועוקב אחר משימות: השתמשו ב-Forgejo או ב-Gitea, על שרת עם 2 GB RAM ומעלה. העבירו את ה-CI runner לשרת שני ברגע שהעומס על המשימות הופך לממשי.

ארגון הזקוק ל-container registry ולתיעוד פעולות (audit trails), עם תקציב של 16 GB RAM לשרת: השתמשו ב-GitLab. מתחת לתקציב זה, אל תתקינו אותו.

המעבר בין שלושת השלבים הראשונים הוא זול, כיוון שבכולם המאגרים הם ספריות Git רגילות על הדיסק. התחילו בשלב הנמוך ביותר שעונה על הצרכים שלכם. אם אתם בוחנים אילו שירותים נוספים ראויים למקום על אותו שרת, הרשימה הקצרה של שירותים שכדאי לארח עצמאית מציבה שרת Git לצד שירותים אחרים המתחרים על זיכרון ה-RAM הזמין.

FAQ

האם VPS עם 1 GB RAM יכול להריץ את Forgejo או Gitea?

כן, עבור צוות קטן, בשימוש ב-SQLite, ובתנאי שאין שירותים כבדים אחרים על השרת. התיעוד של Gitea מציין כי 1 GB של RAM ושני ליבות CPU מספיקים בדרך כלל לצוותים ופרויקטים קטנים, ו-Forgejo הוא פיצול (fork) של Gitea בעל דרישות דומות. אין להוסיף PostgreSQL או CI runner לאותו שרת. אם השירות נעלם ללא שגיאה בלוג שלו, הריצו את sudo dmesg -T | grep -i oom: שורה המציינת את התהליך שנסגר מעידה על כך ש-kernel out of memory killer סיים אותו, והפתרון הוא שדרוג למסלול עם משאבים רבים יותר ולא שינוי הגדרות.

מה ההבדל בין Forgejo ל-Gitea?

הם חולקים היסטוריית קוד ורוב התכונות זהות. Gitea פוצלה מ-Gogs בשנת 2016, ו-Forgejo פוצלה מ-Gitea בסוף 2022 לאחר שהשליטה בסימן המסחרי של Gitea עברה לחברה מסחרית. Forgejo מופץ על ידי Codeberg e.V., עמותה ללא מטרות רווח בגרמניה, תחת רישיון GPLv3; Gitea נשאר תחת רישיון MIT עם תמיכה מסחרית. ההבדל המעשי הוא בנתיב ההגירה. גרסה Forgejo v10.0, מינואר 2025, הייתה הגרסה האחרונה שיכלה לקלוט מסד נתונים של Gitea ישירות, ורק מ-Gitea v1.22 ומטה, כך שאין נתיב מעבר נתמך להחלפה ישירה של מופע Gitea קיים.

האם ניתן להריץ workflows של GitHub Actions על שרת Git בניהול עצמי?

Forgejo Actions ו-Gitea Actions מריצים שניהם workflows שנכתבו בתחביר YAML של GitHub Actions, הנקראים מתוך .forgejo/workflows ו-.gitea/workflows. עליכם להתקין תוכנת runner נפרדת ולרשום אותה מול המופע שלכם. פעולות (actions) רבות שפורסמו עובדות ללא שינוי, אך כל מה שקורא ל-GitHub API לא יעבוד. ה-runner מריץ קוד שרירותי מהמאגרים שלכם ומפעיל מכולה (container) לכל משימה, לכן הקצו לו מארח משלו, או לפחות משתמש ללא הרשאות מיוחדות, והרחיקו אותו משרת 1 GB שכבר מריץ את ה-forge.

כיצד מגבים שרת Git בניהול עצמי?

עבור מאגרים חשופים (bare repositories), הפקודה git clone --mirror ממכונה אחרת מעתיקה כל ref ואובייקט, ו-git remote update בתוך אותו מראה (mirror) מרענן אותו. עבור Forgejo או Gitea, המאגרים הם רק חלק מהמצב, כיוון שנושאים (issues), בקשות משיכה (pull requests), משתמשים ומפתחות נמצאים במסד הנתונים. השתמשו בכלי הגיבוי המובנה, sudo -u git forgejo dump -c /etc/forgejo/app.ini, או באותה פקודה בתוך המכולה עבור התקנת Docker. העתיקו את הארכיון מחוץ לשרת, ובצעו שחזור פעם אחת על מכונה חלופית כדי לוודא שהתהליך עובד.