A saját üzemeltetésű fejlesztői produktivitási stack: a GitHub, a Vercel és a Sentry kiváltása egyetlen VPS-en 2026-ban

A jelenlegi listaárakon egy 3 fős csapat, amely GitHub Teamet, Vercel Prót, Sentry Teamet, Linear Basicet és Notion Plust használ, nagyjából havi 158 dollárnál kezd, az 1Password, a használatalapú díjak és a kiegészítők nélkül. Egy gondosan behatárolt, saját üzemeltetésű stack érdemben csökkentheti ezt a számlát, de a tisztességes összevetéshez hozzátartozik a 4 GB-os laborminimumnál nagyobb VPS és a karbantartási idő, amelyről mindenki megfeledkezik.

Ez az útmutató annak a fejlesztőnek vagy kis csapatnak szól, amely már eldöntötte, hogy „a SaaS-számla idegesítő”, és hogy „kellemetlen a privát kódot és a fejlesztői munkafolyamatokat harmadik fél infrastruktúráján tartani”, és most azt szeretné tudni, pontosan mit futtasson. A stack négy rétegből áll: kód, build és üzembe helyezés, futtatás, dokumentáció. Minden réteghez tartozik egy ajánlott eszköz, egy alternatíva, az erőforrásköltség és a hibamód. A hatókör a privát és csapatszintű használat egyetlen VPS-en. Az e-mail-hosting, a DNS, az ügyfél felé néző hitelesítés és a Kubernetes kívül esik rajta, olyan okokból, amelyeket a maguk helyén megnevezünk.

A rövid verzió

Ha csak a felsorolást olvassa el:

• Kód: Alapértelmezésben Forgejo. GitLab CE-t csak akkor válasszon, ha egyetlen termékben szeretné a gitet, a CI/CD-t, a registryt és a hibajegyeket; a GitLab jelenlegi egycsomópontos alapja 16 GB RAM, a 8 GB pedig a memóriában szűkös környezeteknek van fenntartva.
• Build és üzembe helyezés: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
• Futtassa: Vaultwarden a megosztott hitelesítő adatokhoz, Uptime Kuma a felügyelethez, GlitchTip a hibakövetéshez, Portainer vagy Dockge a konténerkezeléshez. A GlitchTip sokkal kisebb telepítés, mint a saját üzemeltetésű Sentry, amelynek hivatalos minimuma 16 GB RAM plusz 16 GB lapozóterület.
• Dokumentáció: Docmost a dokumentációhoz, OpenProject (vagy Plane) a hibakövetéshez. Az AFFiNE azoknak a csapatoknak való, amelyek a vászonszerű Notion-modellt kedvelik.
• Méretezés: Tekintse a 4 GB-ot laborméretnek néhány könnyű szolgáltatáshoz, a 8 GB-ot lecsupaszított próbaüzemnek OpenProject, Plane és helyi buildek nélkül, a 16 GB-ot pedig az útmutatóban leírt teljes, Forgejo alapú stack gyakorlati kiindulópontjának. A GitLab 8 vCPU/16 GB-os alapja magára a GitLabra vonatkozik, ezért egy GitLabra épülő, egydobozos stack további kapacitást vagy külön terheléses tesztet kíván.
• Hol veszít: Nyilvános, külső közreműködőkre építő nyílt forrású projektek. A GitHub hálózati hatása valóságos, és a saját üzemeltetés a megtalálhatóságot viszi el.

Előfeltételek

Mielőtt továbbolvasna, ez az útmutató feltételezi:

• Egy Linux VPS telepített Dockerrel és Docker Compose-zal. Számoljon nagyjából 16 GB RAM-mal a teljes, Forgejo alapú stackhez; 8 GB elég egy lecsupaszított próbaüzemhez, amelyből kimaradnak a nehezebb projektmenedzsment-eszközök és a helyi buildek.
• Rétegenként 30-60 perc figyelem az első üzembe helyezéshez.
• Magabiztosság egy Compose-fájl olvasásában és a környezeti változók módosításában.
• Hajlandóság rendszeres frissítési ablak tartására, a biztonsági javítások gyors telepítésére és a mentések ellenőrzésére, nem pusztán a beállításukra.

Ha bármelyik pont kizáró ok, akkor a SaaS-csomag valóban a helyes válasz a csapatának. Ez védhető álláspont, nem kudarc.

1. réteg, kód: Forgejo, Gitea vagy GitLab CE

Három életképes lehetőség, három különböző pont az erőforrás- és irányítási görbén. Aki 2026-ban vág bele a saját üzemeltetésbe, annak az ajánlás: először a Forgejo.

A Forgejo szerény infrastruktúrára készült, és kínál pull requestet, hibakövetést, projekttáblákat, wikiket, csomagregisztereket és Forgejo Actionst. A munkafolyamatai GitHub Actions stílusú formátumot használnak, de a kompatibilitás nem teljes; tesztelje az összes külső actiont, amelyre a folyamata épül.

A Gitea csak akkor jöjjön szóba, ha már függ egy kizárólag benne meglévő funkciótól, vagy az eszközei egy adott Gitea-verzióhoz vannak rögzítve. Magával a kódbázissal semmi baj. A Forgejo hivatalos összehasonlítása szerint a fork azt követte, hogy 2022 októberében a Gitea domainjeit és védjegyét a közösség jóváhagyása nélkül egy profitorientált cégre ruházták át; a Forgejo licencbejelentése a v9.0-tól kezdődő verziókra GPL v3+ licencet rögzít.

A GitLab CE-t akkor válassza, ha egyetlen termékben szeretné a gitet, a CI/CD-t, a konténerregisztert és a hibakövetést, és elbírja az erőforrásigényének alsó határát. A GitLab jelenlegi követelményei 16 GB RAM-ot és 8 vCPU-t szabnak meg egycsomópontos alapként; a 8 GB a memóriában szűkös környezeteké. A Gitea elég könnyű ahhoz, hogy egy kis privát példány nagyjából 1-2 GB RAM-ban elfusson, és a Forgejo is hasonló, de az éles méretezés mindkettőnél a repositoryktól, a runnerektől és az egyidejű felhasználóktól függ.

A CI kérdését érdemes külön kiemelni. A Gitea Actions úgy készült, hogy nagyrészt kompatibilis legyen a GitHub Actionsszel, míg a Forgejo Actions szándékosan az ismerősségre tör a teljes kompatibilitás helyett. Sok munkafolyamathoz csak apró módosítás kell, de a runner-image-ek, a jogosultságok, a kontextusok, a címkék és a külső actionök másképp viselkedhetnek. A migráció előtt tesztelje az összes munkafolyamatot és actiont, amelyre a folyamata épül.

Egy fenntartás mind a három lehetőségre áll. Ez az útmutató privát és csapatszintű használatot feltételez, ahol az adminisztrációs felület VPN vagy IP-engedélyezési lista mögött van. A nyilvános git-szolgáltatásokra botforgalom, visszaélés és a megtalálhatóság körüli kompromisszumok várnak, amelyeket egy kis privát telepítés nem ismer. Nyilvános nyílt forráskód esetén tükrözzön GitHubra a láthatóságért, a Forgejo pedig maradjon az igazság forrása, ha ez az irányítási modell számít önnek.

A szervert a terhelés alapján méretezze, ne a szolgáltató csomagneveiből. Egy önálló Forgejo- vagy Gitea-szolgáltatás könnyű, privát használatra elindulhat nagyjából 1-2 vCPU-val és 1-2 GB RAM-mal. Egy lecsupaszított stack OpenProject, Plane és helyi buildek nélkül elindulhat körülbelül 4 vCPU-val és 8 GB RAM-mal. Az itt leírt teljes, Forgejo alapú stackhez induljon nagyjából 8 vCPU-ról és 16 GB RAM-ról, majd validálja valódi CI- és alkalmazásterhelés alatt. A GitLab hivatalos 8 vCPU/16 GB-os alapja magára a GitLabra vonatkozik, tehát ne tekintse elegendőnek a GitLab plusz a stack többi részéhez. Használjon SSD- vagy NVMe-tárolót, a repositorykra, konténerképekre, naplókra, adatbázisokra és mentésekre külön tervezzen keretet, és hagyjon szabadon 20-30% kapacitást a frissítésekre és a terhelési csúcsokra.

A szakasz fő tanulsága: 2026-ban a kódréteg alapértelmezett ajánlása a Forgejo; a Gitea továbbra is szolid, a GitLab CE pedig csak akkor az integrált választás, ha elbírja a 16 GB-os alapját, vagy tudatosan üzemel egy 8 GB-ra korlátozott konfiguráción.

2. réteg, build és üzembe helyezés: Coolify (fenntartásokkal), Dokku vagy tiszta Docker Compose

Őszintén: a Coolify az ajánlott PaaS-megoldás ehhez a stackhez, ha a legfrissebb éles kiadást futtatja, a vezérlőpultot távol tartja a nyilvános internettől, és követi a biztonsági közleményeket. A minőségellenőrzés idején a GitHub a Coolify v4.3.0 Coolify v4.1.2-t jelöli legfrissebbként. A javítások telepítését és az adminisztrációs sík elszigetelését üzemeltetési követelménynek tekintse, ne opcionális megerősítésnek.

Profi tipp: Korlátozza a Coolify vezérlőpultját és API-ját tűzfallal, VPN-nel vagy megbízható hozzáférési proxyval. Az üzembe helyezett alkalmazások továbbra is fogadhatnak nyilvános forgalmat; a cél az adminisztratív vezérlősík kitettségének csökkentése.

Az egyedül dolgozó fejlesztők alternatívája a Dokku, egy tömör PaaS Heroku-stílusú, git push alapú üzembe helyezéssel és buildpack-támogatással. Felülete kisebb, mint a Coolify felülete, és ennek megfelelően a funkciókészlete is szerényebb. Ettől védhető „unalmas választás” egy-két fejlesztőnek, akiknek nem kell vezérlőpult.

A harmadik lehetőség, amelyhez a tapasztalt üzemeltetők nyúlnak: semmilyen PaaS, csak Docker Compose. Ha a csapata amúgy is Compose-fájlokat ír, és szereti látni a mozgó alkatrészeket, ez tökéletesen észszerű válasz. Tegyen mellé Dockge-ot vagy Portainert felületi rétegnek a stackek kezelésére, ha egy kattintásos újraindítást szeretne a docker compose restart helyett. A kompromisszum üzemeltetési: nincs előnézeti környezet, nincs beépített TLS-automatizálás, és nincs leállás nélküli üzembe helyezés sem munka nélkül. Ezeket a képességeket szkriptírással szerzi meg; a Coolify esetében készen kapja őket, a hozzájuk tartozó biztonsági előtörténettel együtt.

OLVASD

A legjobb önállóan hosztolt Heroku- és Vercel-alternatívák: Coolify, Dokku és társai

A Cloudzy útmutatója a legjobb CI/CD-eszközökről mélyebben tárgyalja a build-folyamatot azoknak a csapatoknak, amelyeknek külön runner kell; sok kis csapatnak erre már nincs szüksége, ha egyszer működik a Forgejo Actions vagy a GitLab CI/CD.

A szakasz fő tanulsága: A Coolify csak az aktuális stabil kiadáson és korlátozott adminisztrációs síkkal az ajánlott PaaS; a Dokku az óvatos, egyszemélyes választás; a tiszta Docker Compose pedig védhető harmadik lehetőség marad.

3. réteg, futtatás: Vaultwarden, Uptime Kuma, GlitchTip és konténerkezelés

Ebben a stackben itt lakik a legélesebb erőforrás-szakadék. A saját üzemeltetésű Sentry hivatalos követelményei minimumként 4 CPU-magot, 16 GB RAM-ot, 16 GB lapozóterületet és 20 GB szabad lemezt sorolnak fel, ajánlásként pedig 32 GB RAM-ot. A GlitchTip telepítési útmutatója 512 MB RAM-ot ajánl, PostgreSQL-t követel meg, a Valkeyt pedig opcionálissá teszi. Egy kis csapatnak egyetlen VPS-en a GlitchTip a gyakorlatias alapértelmezés.

Ennek a rétegnek a maradék négy eszköze rövid történet.

A Vaultwarden Bitwardennel kompatibilis jelszókezelő, amely támogatja a Bitwarden mobilalkalmazásait és böngészőbővítményeit, valamint a csapaton belüli megosztást. A tényleges erőforrásigénye a felhasználóktól, a mellékletektől és az adatbázis megválasztásától függ. A Cloudzy összehasonlítása a saját üzemeltetésű jelszókezelőkről mélyebben tárgyalja a kompromisszumot, ha strukturáltabb jogosultságokra, auditkontrollokra vagy más biztonsági modellre van szüksége.

Az Uptime Kuma az apró felügyeleti és riasztóeszköz: HTTP-, TCP-, ping-, push- és tanúsítványlejárat-ellenőrzések, valamint opcionális állapotoldalak. Az értesítések mehetnek csevegőn, e-mailben vagy webhookon. Az erőforrásigény a figyelők számával és a megőrzési idővel változik; a második egymást követő hibánál riasztani gyakorlatias módja a rövid kilengések elnyomásának.

A GlitchTip a hibakövető. A legtöbb Sentry SDK-integráció tud jelenteni egy GlitchTip-DSN felé, de a funkcióbeli egyenértékűség nem teljes; tesztelje a teljesítményfigyelést, a source mapeket, a riasztásokat és minden integrációt, amelyet a csapata kritikusnak tart.

Konténerfelületnek válassza a Portainert vagy a Dockge-ot. A Portainer szélesebb konténerkezelési eseteket fed le; a Dockge a Docker Compose-nál marad. Egy kis, csak Compose-t használó stackhez a Dockge tisztábban illeszkedik. Portainerre csak akkor váltson, ha kell a tágabb hatókör.

Hasznos Compose-szokás ehhez a réteghez: minden eszközt tartson külön alkönyvtárban, saját compose.yml-lel, Docker-hálózatot csak ott osszon meg, ahol eszközök közti forgalom kell, és tegyen elé egyetlen fordított proxyt a TLS lezárására.

# /opt/stack/glitchtip/compose.yml (excerpt)
services:
  web:
    image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
    environment:
      DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
      SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
      GLITCHTIP_DOMAIN: "https://errors.example.com"
      DEFAULT_FROM_EMAIL: "[email protected]"
    ports:
      - "127.0.0.1:8000:8000"

Profi tipp: Egy mentés csak akkor bizonyított, ha a szolgáltatás visszaállítható és az adatai ellenőrizhetők. Havonta egyszer állítson vissza egy jellemző szolgáltatást elszigetelt tesztkörnyezetbe, indítsa el, jelentkezzen be, nézze át a rekordokat és a mellékleteket, és győződjön meg róla, hogy az alkalmazás normálisan viselkedik. A visszaállított fájlok kilistázása csak azt bizonyítja, hogy az archívum olvasható, nem azt, hogy az adatbázis, a kötetek, a jogosultságok és az alkalmazás állapota sikeresen helyreállítható.

A szakasz fő tanulsága: A GlitchTip elvégzi a hibakövetés lényegi munkáját a saját üzemeltetésű Sentrynél drámaian kisebb telepítéssel, de ellenőrizze azokat a Sentry-funkciókat és -integrációkat, amelyeket a csapata ténylegesen használ.

4. réteg, dokumentáció: Docmost, AFFiNE és hibakövetés OpenProjecttel vagy Plane-nel

A Notion felülete rendben van, egészen addig, amíg egy növekvő wiki lomhává nem teszi a navigációt és a keresést. Kis csapatnak az ajánlott felosztás: Docmost a dokumentációhoz és a wikihez, OpenProject a hibakövetéshez. Cserélje az OpenProjectet Plane-re, ha a csapata kifejezetten Linear-szerű vizuális modellt szeretne, és vállalja annak támogatott, saját üzemeltetésű telepítését.

A Docmost itt a Notionhoz legközelebb álló, saját üzemeltetésű helyettesítő, anélkül hogy Notionnak adná ki magát. A blokkszerkesztője, az oldalhierarchiája és a csapatjogosultságai illenek egy hagyományos belső wikihez. Ezt a réteget az egyidejű szerkesztők, a mellékletek, és aszerint méretezze, hogy a PostgreSQL és a Redis ugyanazon a gépen van-e. Az AFFiNE azoknak a csapatoknak az alternatívája, amelyek a vászon- és táblamodellt kedvelik az egymásba ágyazott oldalak helyett. Mindkettő észszerű; válasszon egyet.

Az OpenProject azoknak a csapatoknak fedi le a hibakövetést, amelyeknek kényelmes a Jira-ízű munkafolyamat: epikek, munkacsomagok, sprintek és időnyilvántartás. A Plane a Linear-formájú alternatíva, gyorsabb, hibajegy-központú felülettel és más üzemeltetési lábnyommal.

Ismerjük el őszintén: a Linear billentyűzet-központú gyorsasága tényleg jó, és a Plane nem minden interakciót ad vissza. Ha a csapata munkafolyamata a Linear parancsmenüjéhez kötődő izommemóriára épül, a migrációs súrlódás valóságos. Nem feltétlenül kizáró ok, de valódi költség.

A szakasz fő tanulsága: A Docmost a belső dokumentáció szerepét tölti be, a hibakövetést pedig az OpenProject vagy a Plane viszi; a Linearhez képesti billentyűzetes használhatósági rés az egyetlen pont, ahol ez a réteg kompromisszumot kér.

Mennyibe kerül ez a stack, és min fut

Az egy gépbe zsúfolt, teljes Forgejo alapú stack gyakorlati kiindulópontja nagyjából 8 vCPU és 16 GB RAM. A 2 vCPU-t 4 GB RAM-mal tekintse laborméretnek néhány könnyű szolgáltatáshoz, a 4 vCPU-t 8 GB RAM-mal pedig lecsupaszított próbaüzemnek OpenProject, Plane és helyi buildek nélkül. A tényleges igény az egyidejű felhasználóktól, a CI-aktivitástól, az adatbázisok növekedésétől, a mellékletektől, a képtárolástól, a naplóktól és a megőrzési időtől függ, ezért validálja a stacket valódi terhelés alatt, és hagyjon szabadon 20-30% kapacitást. A 16 GB-os kezdőszint terheléses tesztelés fenntartásával a következő szolgáltatásokat bírja el egy enyhén terhelt, 2-3 fős fejlesztőcsapatnak:

• Forgejo
• Coolify
• Vaultwarden
• Uptime Kuma
• GlitchTip
• Docmost
• OpenProject
• Dockge

Egy 4 GB-os szerver csak néhány könnyű szolgáltatásra jó. Egy 8 GB-os gépet jobb lecsupaszított próbaüzemnek tekinteni OpenProject, Plane és helyi buildek nélkül. A teljes, Forgejo alapú stacket 16 GB-nál indítsa, és tegyen hozzá kapacitást, amint GitLab, párhuzamos buildek, Plane, hosszú megőrzési idők vagy nehezebb adatbázis-terhelés jön a képbe. Ugyanennek a csapatnak a SaaS-csomagja a következőket tartalmazza:

• GitHub Team
• Vercel Pro
• Sentry
• Linear
• Notion
• 1Password

Az egyes árlapokon közzétett alapdíjak alapján (ahol értelmezhető, az éves számlázású díjakkal együtt). Az öt fizetős termék együtt nagyjából havi 158 dollárt tesz ki három főre: GitHub Team az első 12 hónapban felhasználónként 4 dollár, három fejlesztői hely a Vercel Pro esetében egyenként 20 dollár, Sentry Team 26 dollártól, Linear Basic felhasználónként 10 dollár, valamint a Notion Plus felhasználónként 10 dollár. A használatalapú díjak, az adók, a kiegészítők és az 1Password ezen felül jönnek. Az infrastruktúra még mindig érdemben olcsóbb lehet, de az üzemeltető ideje nélkül az összevetésnek nincs értelme.

Mikor lépjen feljebb: a GitLab egycsomópontos alapja 8 vCPU és 16 GB RAM. Több párhuzamos build GitLab nélkül is kérhet plusz kapacitást. A saját üzemeltetésű Sentry szintén 16 GB RAM plusz 16 GB lapozóterületnél indul, és 32 GB-ot ajánl, ezért javasolja ez az útmutató az egydobozos stackhez a GlitchTip eszközt.

Az árcédula nélküli költség az üzemeltetési idő. Tervezési becslésként számoljon havi 1-2 órával a frissítésekre és a mentések ellenőrzésére, plusz heti egy rövid átfutással az általa futtatott projektek biztonsági közleményein. A valódi szám a változások mennyiségétől, az incidenskezeléstől és az automatizálás mértékétől függ. Nem nulla, és helye van a költségmodellben.

A telepítés módja a kényelmet változtatja meg, nem az üzemeltetési követelményeket. Akár hivatalos Compose-fájlt, akár piactéri sablont használ: rögzítse a képverziókat, állítson be CPU- és memóriakorlátokat, tartsa a szolgáltatásadatokat elnevezett kötetekben, és tesztelje a mentést és a visszaállítást is. A teljes stack egy gépre zsúfolása közös hibatartományt is teremt, ezért különítse el a kritikus szolgáltatásokat, ha a leállás vagy a hitelesítő adatok kiszivárgása nagyot ütne.

Ha üzembe szeretné helyezni ezt a stacket, hasonlítsa össze cloud VPS csomagjainkat CPU, RAM, SSD- vagy NVMe-tárhely, forgalmi keret és régió szerint, majd alkalmazza a fenti méretezési keretet. A gyorsabb induláshoz nézze meg az egykattintásos alkalmazáskatalógusunkat, de a verziókat akkor is rögzítse, állítson be erőforráskorlátokat, és élesítés előtt ellenőrizze a mentéseket.

A szakasz fő tanulsága: Kis laborhoz 4 GB, lecsupaszított próbaüzemhez 8 GB, a teljes, Forgejo alapú stack gyakorlati kiindulópontjaként pedig nagyjából 8 vCPU 16 GB RAM-mal. Tegyen hozzá kapacitást a GitLabhoz, a párhuzamos buildekhez, a nehezebb projektmenedzsment-eszközökhöz és a növekvő adatbázisokhoz.

Hol bukik meg valóban ennek a stacknek a saját üzemeltetése

Négy hibamód, kertelés nélkül megnevezve, hiszen az útmutató többi része végig e megközelítés melletti érvelés volt.

1. hibamód: a GitHub hálózati hatása nyilvános nyílt forrású projekteknél. A saját üzemeltetésű git privát kódhoz helyes választás. Olyan projektekhez viszont hibás, amelyek teljes értéke azon áll, hogy külső közreműködők rátalálnak-e. A fejlesztők először a GitHubra néznek. Pull requestek, forkok, csillagok, a github.com-on lét hallgatólagos bizalmi jelzése, a külső eszközök integrációi, mind. Ha a projektje nyilvános nyílt forráskód, a becsületes minta ez: tükrözzön GitHubra a láthatóságért, az igazság forrása pedig maradjon a Forgejo. Ne várja, hogy egy saját példány kiváltja a GitHub megtalálhatóságát a nyilvános munkában. Nem fogja.

2. hibamód: bot- és lehúzóforgalom a nyilvános Git-példányokon. A kifelé nyitott Forgejo- és Gitea-szolgáltatásokhoz kellenek visszaélés elleni kontrollok, sebességkorlátok, felügyelet és elegendő kapacitás a kiszámíthatatlan forgalomra. Ez az útmutató privát és csapatszintű használatot feltételez, ahol az adminisztrációs felület VPN vagy IP-engedélyezési lista mögött van. Egy valóban nyilvános forge más fenyegetés- és kapacitásmodell szerint működik.

3. hibamód: a karbantartás terhe. „Maga az informatikai osztály” elcsépelt mondat, és nagyrészt igaz. A frissítések eltörnek dolgokat. A Compose-fájlok elcsúsznak. A tanúsítványok lejárnak. A mentések csendben, a lehető legméltatlanabb módokon buknak el. A Coolify 2026-os közleményei jó emlékeztetők arra, hogy a javítási ütem számít. Ha nem tud előre elköteleződni egy karbantartási ablak mellett, őszintén szólva a SaaS-csomag a helyes válasz.

4. hibamód: az integrációk elvesztése. Külső GitHub Actionök, a GitHub pull requestekhez kötött Vercel-előnézeti üzembe helyezések, a Sentry felhős riasztási integrációi a PagerDutyval és a Linearrel, a Notion széles integrációs katalógusa. A legtöbbnek van saját üzemeltetésű megfelelője (Forgejo Actions, Coolify webhookos üzembe helyezései, GlitchTip-értesítések, n8n a munkafolyamatok összeragasztására), de a helyettesítés nem mindig egy az egyben megy. Készítsen prototípust a legfontosabb munkafolyamatból, mielőtt a csapatot migrációra kötelezi. Az az integráció fog a legnagyobb eséllyel meglepni, amelyet magától értetődőnek vesz.

A szakasz fő tanulsága: Ez a stack működik privát kódra, kis csapatokra és készséges üzemeltetőkre; nem működik nyilvános nyílt forrású láthatóságra, olyan csapatokra, amelyek hozzá sem akarnak nyúlni, sem a nulla karbantartás elvárására.

Az üzemeltető stackje

Négy réteg, négy ajánlás, őszintén megnevezve. Kód: Forgejo. Build és üzembe helyezés: Coolify korlátozott adminisztrációs síkkal, vagy Dokku, vagy Compose. Futtatás: Vaultwarden, Uptime Kuma, GlitchTip, Portainer vagy Dockge. Dokumentáció: Docmost és OpenProject (vagy Plane). A lecsupaszított próbaüzemet 8 GB-nál, a teljes, Forgejo alapú stacket 16 GB-nál indítsa. Tegyen hozzá kapacitást a GitLabhoz, a párhuzamos buildekhez, a nehezebb adatbázisokhoz vagy a tartós alkalmazásterheléshez.

Ha költözik, kezdje az Uptime Kuma eszközzel és egy nem kritikus belső szolgáltatással. Ezekkel kisebb kockázattal tanulhatja meg az üzemeltetési ritmust (frissítések, felügyelet, mentésellenőrzés és tanúsítványmegújítás), mielőtt egy csapatszintű munkafolyamatot vagy egy jelszótárolót mozdítana. A Vaultwardent ne az első próbatelepítésnek szánja: csak akkor költöztesse, ha már megvan a gépen kívüli titkosított mentés, a sikeres visszaállítási teszt, a korlátozott adminisztráció és a többtényezős hitelesítés. Ha ez a ritmus megbízhatóvá vált, jöhet a Forgejo, aztán a Coolify, aztán a többi.

Azoknak a csapatoknak, amelyek kifejezetten a GitLab CE-t választják: döntsék el, hogy a beépített CI/CD kiváltja-e a külön runnert, vagy a terhelésükhöz továbbra is dedikált buildkapacitás kell.

Gyakran ismételt kérdések

Mi a legjobb saját üzemeltetésű alternatíva a Gitea helyett 2026-ban?

A Forgejo az ajánlott választás azoknak, akik 2026-ban kezdenek saját üzemeltetésbe. A Gitea védjegyének és domainjének 2022 októberi átruházása egy profitorientált cégre, a közösség előzetes jóváhagyása nélkül, váltotta ki 2022 végén a Forgejo forkot. A v9.0-tól a Forgejo kiadásai GPL v3+ licencet használnak; a korábbi v8.0-s és v7.0-s javítókiadások MIT alatt maradtak. A mindennapokban a funkciók nagyjából egyenértékűek.

Futtatható-e a Coolify biztonságosan éles környezetben 2026-ban?

Igen, de csak aktív karbantartással és mélységi védelemmel. Futtassa a legfrissebb, átnézett stabil kiadást, kövesse az új közleményeket, korlátozza a csapat jogosultságait, a vezérlőpultot és az API-t pedig tartsa tűzfal, VPN vagy megbízható hozzáférési réteg mögött. Ne tekintse a beta.451-et, a beta.474-et vagy bármely más korábbi javítási szintet tartósan biztonságos küszöbnek.

Mennyi RAM kell valójában egy teljes, saját üzemeltetésű fejlesztői stacknek?

Egy 2-3 fős fejlesztőcsapatnál tekintse a 4 GB-ot laborméretnek néhány könnyű szolgáltatáshoz, a 8 GB-ot pedig lecsupaszított próbaüzemnek OpenProject, Plane és helyi buildek nélkül. A teljes, Forgejo alapú stack gyakorlati kiindulópontja nagyjából 8 vCPU és 16 GB RAM. A GitLab 8 vCPU/16 GB-os alapja magára a GitLabra vonatkozik, míg a saját üzemeltetésű Sentry 16 GB RAM-ot plusz 16 GB lapozóterületet követel, és 32 GB-ot ajánl. A végleges konfigurációt valódi terhelési körülmények közt validálja.

Miért GlitchTip a saját üzemeltetésű Sentry helyett?

Az erőforrás- és üzemeltetési szakadék miatt. A saját üzemeltetésű Sentry legalább 16 GB RAM-ot plusz 16 GB lapozóterületet kíván, és nagy, több szolgáltatásból álló telepítés. A GlitchTip a mindent egyben szolgáltatásához 512 MB-ot ajánl, PostgreSQL-t követel meg, a Valkeyt pedig opcionálissá teszi. Fogadja a Sentry SDK-forgalmat, de a funkcióbeli egyenértékűség nem teljes, ezért tesztelje azokat a funkciókat és integrációkat, amelyekre támaszkodik.

Mennyibe kerül valójában ez a stack a SaaS-megfelelőkhöz képest?

Tekintse a 4 GB-ot laborméretnek néhány könnyű szolgáltatáshoz, a 8 GB-ot pedig lecsupaszított próbaüzemnek OpenProject, Plane és helyi buildek nélkül. A teljes, Forgejo alapú stack gyakorlati kiindulópontja nagyjából 8 vCPU és 16 GB RAM. A közzétett alapárakon a GitHub Team, a Vercel Pro, a Sentry Team, a Linear Basic és a Notion Plus együtt nagyjából havi 158 dollár három főre, az 1Password, a használatalapú díjak, az adók és a kiegészítők nélkül. A saját üzemeltetés érdemben olcsóbb lehet, de az üzemeltető ideje és a mentési infrastruktúra valódi költségek.