Lo stack di produttività per sviluppatori self-hosted: sostituire GitHub, Vercel e Sentry su un solo VPS nel 2026

Ai prezzi di listino attuali, un team di 3 persone che usa GitHub Team, Vercel Pro, Sentry Team, Linear Basic e Notion Plus parte da circa 158 $ al mese, prima di 1Password, dei costi a consumo e dei componenti aggiuntivi. Uno stack self-hosted delimitato con cura può ridurre sensibilmente quella bolletta, ma il confronto onesto include un VPS più grande della soglia da laboratorio di 4 GB e il tempo di manutenzione che tutti dimenticano.

Questa guida è per lo sviluppatore o il piccolo team che ha già deciso che «la bolletta SaaS è fastidiosa» e che «tenere codice privato e flussi di lavoro di sviluppo su infrastruttura di terzi mette a disagio», e ora vuole sapere che cosa eseguire nel concreto. Lo stack ha quattro livelli: codice, build e deploy, esecuzione e documentazione. Ogni livello riceve uno strumento consigliato, un'alternativa, il costo in risorse e la modalità di guasto. L'ambito è l'uso privato e di squadra su un singolo VPS. Hosting email, DNS, autenticazione rivolta ai clienti e Kubernetes restano fuori ambito, per ragioni che indicheremo dove è opportuno.

La versione breve

Se leggi solo i punti elenco:

• Codice: Forgejo come impostazione predefinita. Usa GitLab CE solo se vuoi git, CI/CD, registry e issue in un unico prodotto; l'attuale base di GitLab su nodo singolo è di 16 GB di RAM, mentre gli 8 GB sono riservati agli ambienti con memoria limitata.
• Build e deploy: 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.
• Esegui: Vaultwarden per le credenziali condivise, Uptime Kuma per il monitoraggio, GlitchTip per il tracciamento degli errori e Portainer o Dockge per la gestione dei container. GlitchTip è un deployment molto più piccolo di Sentry self-hosted, il cui minimo ufficiale è 16 GB di RAM più 16 GB di swap.
• Documentazione: Docmost per la documentazione e OpenProject (o Plane) per il tracciamento delle issue. AFFiNE è adatto ai team che preferiscono un modello Notion in stile canvas.
• Dimensionamento: Considera 4 GB una taglia da laboratorio per qualche servizio leggero, 8 GB un pilota ridotto senza OpenProject, Plane o build locali, e 16 GB il punto di partenza pratico per lo stack completo basato su Forgejo di questa guida. La base di 8 vCPU e 16 GB di GitLab vale per GitLab stesso, quindi uno stack tutto-in-una-macchina basato su GitLab richiede capacità aggiuntiva o test di carico a parte.
• Dove perde: I progetti open source pubblici con contributori esterni. L'effetto rete di GitHub è reale, e il self-hosting ti costa in reperibilità.

Prerequisiti

Prima di proseguire, questa guida presuppone:

• Un VPS Linux con Docker e Docker Compose installati. Prevedi circa 16 GB di RAM per lo stack completo basato su Forgejo; 8 GB bastano per un pilota ridotto che lasci fuori gli strumenti di project management più pesanti e le build locali.
• Da 30 a 60 minuti di attenzione per livello al primo deploy.
• Dimestichezza nel leggere un file Compose e nel modificare le variabili d'ambiente.
• La disponibilità a mantenere una finestra di aggiornamento regolare, ad applicare in fretta le correzioni di sicurezza e a verificare i backup invece di limitarsi a configurarli.

Se uno di questi punti è inaccettabile, il pacchetto SaaS è davvero la risposta giusta per il tuo team. È una posizione difendibile, non un fallimento.

Livello 1, codice: Forgejo, Gitea o GitLab CE

Tre opzioni valide, tre punti diversi sulla curva tra risorse e governance. Per chi inizia con il self-hosting nel 2026, la raccomandazione è prima Forgejo.

Forgejo è pensato per infrastrutture modeste e offre pull request, tracciamento delle issue, bacheche di progetto, wiki, registry di pacchetti e Forgejo Actions. I suoi workflow usano un formato in stile GitHub Actions, ma la compatibilità non è assoluta; testa ogni action di terze parti da cui dipende la tua pipeline.

Scegli Gitea solo se dipendi già da una funzione esclusiva di Gitea o se i tuoi strumenti sono fissati a una versione di Gitea. Alla codebase non c'è nulla da rimproverare. Il confronto ufficiale di Forgejo afferma che il fork è seguito al trasferimento, nell'ottobre 2022, dei domini e del marchio di Gitea a una società a scopo di lucro senza l'approvazione della comunità; l' annuncio sulla licenza di Forgejo registra la GPL v3+ per le versioni a partire dalla v9.0.

Scegli GitLab CE se vuoi un unico prodotto per git, CI/CD, registry dei container e tracciamento delle issue, e puoi permetterti la sua soglia minima di risorse. I requisiti attuali di GitLab fissano 16 GB di RAM e 8 vCPU come base su nodo singolo; gli 8 GB riguardano gli ambienti con memoria limitata. Gitea è abbastanza leggero da far girare una piccola istanza privata in circa 1-2 GB di RAM, e Forgejo è paragonabile, ma il dimensionamento in produzione di entrambi dipende comunque da repository, runner e utenti in contemporanea.

La questione della CI merita di essere segnalata. Gitea Actions è progettato per essere in gran parte compatibile con GitHub Actions, mentre Forgejo Actions punta deliberatamente alla familiarità più che alla piena compatibilità. Molti workflow richiedono solo piccole modifiche, ma immagini dei runner, permessi, contesti, label e action di terze parti possono comportarsi diversamente. Testa ogni workflow e ogni action da cui dipende la tua pipeline prima di migrare.

Una riserva vale per tutte e tre le opzioni. Questa guida presuppone un uso privato e di squadra, con la superficie di amministrazione dietro una VPN o una lista di IP consentiti. I servizi git pubblici affrontano traffico di bot, abusi e compromessi sulla reperibilità che un piccolo deployment privato non conosce. Per l'open source pubblico, replica su GitHub per la visibilità mantenendo Forgejo come fonte di verità, se quel modello di governance ti interessa.

Dimensiona il server sul carico di lavoro, non sui nomi dei piani di un provider. Un servizio Forgejo o Gitea a sé stante per un uso privato leggero può partire da circa 1-2 vCPU e 1-2 GB di RAM. Uno stack ridotto senza OpenProject, Plane o build locali può partire da circa 4 vCPU e 8 GB di RAM. Per lo stack completo basato su Forgejo descritto qui, parti da circa 8 vCPU e 16 GB di RAM, poi validalo sotto carico reale di CI e applicazioni. La base ufficiale di GitLab, 8 vCPU e 16 GB, vale per GitLab stesso, quindi non darla per sufficiente per GitLab più il resto di questo stack. Usa storage SSD o NVMe, metti a budget separatamente repository, immagini dei container, log, database e backup, e tieni libero il 20-30% della capacità per aggiornamenti e picchi di carico.

Punto chiave della sezione: Forgejo è la raccomandazione predefinita per il livello del codice nel 2026; Gitea resta solido, e GitLab CE è la scelta integrata solo se puoi permetterti la sua base di 16 GB o se operi consapevolmente in una configurazione vincolata a 8 GB.

Livello 2, build e deploy: Coolify (con riserve), Dokku o Docker Compose puro

Detto onestamente: Coolify è l'opzione PaaS consigliata per questo stack se esegui l'ultima release di produzione, tieni la dashboard di amministrazione fuori dalla rete pubblica e segui i bollettini di sicurezza. Al momento del controllo qualità, GitHub segna Coolify v4.3.0 come l'ultima versione. Considera l'applicazione delle patch e l'isolamento del piano di amministrazione requisiti operativi, non un irrobustimento facoltativo.

Consiglio pratico: Limita la dashboard e l'API di Coolify con un firewall, una VPN o un proxy di accesso fidato. Le applicazioni distribuite possono continuare a ricevere traffico pubblico; l'obiettivo è ridurre l'esposizione del piano di controllo amministrativo.

L'alternativa per gli sviluppatori singoli è Dokku, un PaaS compatto con deploy via git push in stile Heroku e supporto ai buildpack. Ha una superficie più ridotta di Coolify e, di conseguenza, meno funzioni. Questo ne fa una difendibile «scelta noiosa» per uno o due sviluppatori che non hanno bisogno di una dashboard.

La terza opzione a cui ricorrono gli operatori esperti è nessun PaaS, solo Docker Compose. Se il tuo team scrive già file Compose e preferisci vedere gli ingranaggi, questa è una risposta del tutto ragionevole. Aggiungi Dockge o Portainer come livello di interfaccia per gestire gli stack quando vuoi un riavvio con un clic invece di docker compose restart. Il compromesso è operativo: niente ambienti di anteprima, niente automazione TLS integrata, niente deploy senza interruzioni senza lavorarci. Quelle funzioni te le guadagni scrivendo script; con Coolify sono già pronte, con lo storico di sicurezza che si porta dietro.

LEGGI

Le migliori alternative self-hosted a Heroku e Vercel: Coolify, Dokku e altre

La guida di Cloudzy ai migliori strumenti CI/CD approfondisce la pipeline di build per i team che hanno bisogno di un runner separato, cosa di cui molti team piccoli fanno a meno una volta attivi Forgejo Actions o la CI/CD di GitLab.

Punto chiave della sezione: Coolify è il PaaS consigliato solo sull'attuale release stabile e con il piano di amministrazione limitato; Dokku è la scelta prudente per chi lavora da solo; Docker Compose puro resta una terza opzione difendibile.

Livello 3, esecuzione: Vaultwarden, Uptime Kuma, GlitchTip e gestione dei container

È qui che vive il divario di risorse più netto di questo stack. I requisiti ufficiali di Sentry self-hosted indicano come minimo 4 core di CPU, 16 GB di RAM, 16 GB di swap e 20 GB di disco libero, con 32 GB di RAM consigliati. La guida all'installazione di GlitchTip consiglia 512 MB di RAM, richiede PostgreSQL e rende Valkey opzionale. Per un piccolo team su un solo VPS, GlitchTip è la scelta predefinita pratica.

I quattro strumenti restanti di questo livello si raccontano in breve.

Vaultwarden è un gestore di password compatibile con Bitwarden che supporta le app mobili e le estensioni per browser di Bitwarden, oltre alla condivisione in team. La sua impronta reale dipende dagli utenti, dagli allegati e dalla scelta del database. Il confronto di Cloudzy tra gestori di password self-hosted approfondisce il compromesso quando ti servono permessi più strutturati, controlli di audit o un modello di sicurezza diverso.

Uptime Kuma è il piccolo strumento di monitoraggio e allerta: controlli HTTP, TCP, ping, push e scadenza dei certificati, più pagine di stato opzionali. Le notifiche possono passare da chat, email o webhook. Il consumo di risorse varia con il numero di monitor e la conservazione; allertare al secondo errore consecutivo è un modo pratico per smorzare gli sfarfallii brevi.

GlitchTip è il tracciatore di errori. La maggior parte delle integrazioni con gli SDK Sentry può inviare a un DSN GlitchTip, ma la parità di funzioni non è completa; testa il monitoraggio delle prestazioni, le source map, gli avvisi e ogni integrazione che il tuo team considera critica.

Scegli Portainer o Dockge come interfaccia per i container. Portainer copre casi d'uso di gestione più ampi; Dockge resta concentrato su Docker Compose. Per un piccolo stack basato solo su Compose, Dockge calza meglio. Passa a Portainer solo quando ti serve quella portata più larga.

Un'ergonomia di Compose utile per questo livello: tieni ogni strumento in una sua sottocartella con il suo compose.yml, condividi una rete Docker solo dove serve traffico tra strumenti, e metti davanti un unico reverse proxy per la terminazione TLS.

# /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"

Consiglio pratico: Un backup è dimostrato solo quando il servizio può essere ripristinato e i suoi dati validati. Una volta al mese, ripristina un servizio rappresentativo in un ambiente di test isolato, avvialo, autenticati, ispeziona record e allegati, e conferma che l'applicazione si comporti normalmente. Elencare i file ripristinati dimostra solo che l'archivio è leggibile, non che database, volumi, permessi e stato dell'applicazione possano essere recuperati con successo.

Punto chiave della sezione: GlitchTip svolge il lavoro essenziale di tracciamento degli errori con un deployment nettamente più piccolo di Sentry self-hosted, ma valida le funzioni e le integrazioni Sentry che il tuo team usa davvero.

Livello 4, documentazione: Docmost, AFFiNE e tracciamento delle issue con OpenProject o Plane

L'interfaccia di Notion va benissimo, finché un wiki che cresce non rende navigazione e ricerca lente. Per un piccolo team la suddivisione consigliata è Docmost per documentazione e wiki, con OpenProject per il tracciamento delle issue. Sostituisci OpenProject con Plane se il tuo team vuole nello specifico un modello visivo in stile Linear e se la sente di gestirne il deployment self-hosted supportato.

Docmost è qui il sostituto self-hosted più vicino a Notion, senza fingere di essere Notion. Il suo editor a blocchi, la gerarchia delle pagine e i permessi di squadra si adattano a un wiki interno classico. Dimensiona questo livello in base agli editor in contemporanea, agli allegati e al fatto che PostgreSQL e Redis condividano o meno lo stesso host. AFFiNE è l'alternativa per i team che preferiscono un modello a canvas e lavagna rispetto alle pagine annidate. Entrambi sono ragionevoli; scegline uno.

OpenProject copre il tracciamento delle issue per i team a proprio agio con un flusso in stile Jira: epiche, pacchetti di lavoro, sprint e rilevazione del tempo. Plane è l'alternativa dalla forma di Linear, con un'interfaccia più rapida e centrata sulle issue e un diverso impegno operativo.

Riconosciamolo onestamente: la velocità di Linear, tutta da tastiera, è davvero buona, e Plane non riproduce ogni interazione. Se il flusso di lavoro del tuo team poggia sulla memoria muscolare del menu comandi di Linear, l'attrito della migrazione è reale. Non è per forza un ostacolo insormontabile, ma è un costo vero.

Punto chiave della sezione: Docmost copre il ruolo della documentazione interna, mentre OpenProject o Plane si occupa del tracciamento delle issue; il divario nell'esperienza da tastiera rispetto a Linear è l'unico punto in cui questo livello ti chiede un compromesso.

Quanto costa questo stack e su cosa gira

Il punto di partenza pratico per lo stack completo basato su Forgejo in una sola macchina è circa 8 vCPU e 16 GB di RAM. Considera 2 vCPU e 4 GB di RAM una taglia da laboratorio per qualche servizio leggero, e 4 vCPU e 8 GB di RAM un pilota ridotto che lascia fuori OpenProject, Plane e le build locali. I requisiti reali dipendono dagli utenti in contemporanea, dall'attività di CI, dalla crescita del database, dagli allegati, dallo storage delle immagini, dai log e dalla conservazione, quindi valida lo stack sotto carico reale e tieni libero il 20-30% della capacità. Il livello di partenza da 16 GB può ospitare i seguenti servizi per un team di 2-3 sviluppatori poco carico, salvo verifica sotto carico:

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

Un server da 4 GB va bene solo per qualche servizio leggero. Un server da 8 GB conviene trattarlo come un pilota ridotto senza OpenProject, Plane o build locali. Avvia lo stack completo basato su Forgejo a 16 GB, e aggiungi capacità quando entrano in gioco GitLab, build in parallelo, Plane, periodi di conservazione lunghi o carichi di database più pesanti. Il pacchetto SaaS dello stesso team comprende:

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

Sulla base delle tariffe di listino pubblicate su ciascuna pagina prezzi (comprese le tariffe con fatturazione annuale, dove applicabile). I cinque prodotti a pagamento sommano circa 158 $ al mese per tre persone: GitHub Team a 4 $ per utente per i primi 12 mesi, tre postazioni sviluppatore di Vercel Pro a 20 $ ciascuna, Sentry Team a partire da 26 $, Linear Basic a 10 $ per utente, e Notion Plus a 10 $ per utente. Costi a consumo, tasse, componenti aggiuntivi e 1Password sono in più. L'infrastruttura può comunque costare sensibilmente meno, ma il confronto non ha senso senza il tempo di chi la gestisce.

Quando aumentare: la base di GitLab su nodo singolo è 8 vCPU e 16 GB di RAM. Più build in parallelo possono richiedere capacità aggiuntiva anche senza GitLab. Anche Sentry self-hosted parte da 16 GB di RAM più 16 GB di swap e ne consiglia 32, ed è per questo che la guida consiglia GlitchTip per lo stack tutto-in-una-macchina.

Il costo senza prezzo è il tempo di gestione. Come stima di pianificazione, metti in conto 1-2 ore al mese per aggiornamenti e verifica dei backup, più una breve scorsa settimanale ai bollettini di sicurezza dei progetti che esegui. Il numero reale dipende dal volume di modifiche, dalla risposta agli incidenti e da quanto automatizzi. Non è zero, e va messo nel modello di costo.

Il metodo di deploy cambia la comodità, non i requisiti operativi. Che tu usi un file Compose ufficiale o un modello del marketplace: fissa le versioni delle immagini, imposta limiti di CPU e memoria, tieni i dati dei servizi in volumi con nome, e testa sia i backup sia i ripristini. Riunire l'intero stack su un solo host crea anche un dominio di guasto condiviso, quindi isola i servizi critici quando un fermo o l'esposizione di credenziali avrebbe un impatto forte.

Se vuoi distribuire questo stack, confronta i nostri piani cloud VPS per CPU, RAM, storage SSD o NVMe, traffico incluso e regione, poi applica il criterio di dimensionamento visto sopra. Per un avvio più rapido, dai un'occhiata al nostro catalogo di app con un clic, ma fissa comunque le versioni, imposta limiti di risorse e verifica i backup prima della produzione.

Punto chiave della sezione: Usa 4 GB per un piccolo laboratorio, 8 GB per un pilota ridotto, e circa 8 vCPU con 16 GB di RAM come punto di partenza pratico per lo stack completo basato su Forgejo. Aggiungi capacità per GitLab, build in parallelo, strumenti di project management più pesanti e database che crescono.

Dove il self-hosting di questo stack fallisce davvero

Quattro modalità di guasto, dette senza giri di parole, perché il resto di questa guida è stato un'arringa a favore dell'approccio.

Modalità di guasto 1: l'effetto rete di GitHub nei progetti open source pubblici. Il git self-hosted è la scelta giusta per il codice privato. È quella sbagliata per progetti il cui valore dipende interamente dal fatto che contributori esterni ti trovino. GitHub è il primo posto in cui gli sviluppatori guardano. Pull request, fork, stelle, il segnale implicito di fiducia dato dall'essere su github.com, le integrazioni con strumenti di terze parti, tutto quanto. Se il tuo progetto è open source pubblico, lo schema onesto è replicare su GitHub per la visibilità mantenendo la fonte di verità su Forgejo. Non aspettarti che un'istanza self-hosted sostituisca la reperibilità di GitHub per il lavoro pubblico. Non lo farà.

Modalità di guasto 2: traffico di bot e scraper sulle istanze Git pubbliche. I servizi Forgejo e Gitea esposti al pubblico hanno bisogno di controlli anti-abuso, rate limit, monitoraggio e capacità sufficiente per traffico imprevedibile. Questa guida presuppone un uso privato e di squadra, con la superficie di amministrazione dietro una VPN o una lista di IP consentiti. Una forge davvero pubblica risponde a un altro modello di minaccia e di capacità.

Modalità di guasto 3: il peso della manutenzione. «L'ufficio IT sei tu» è il luogo comune, ed è in buona parte vero. Gli aggiornamenti rompono cose. I file Compose vanno alla deriva. I certificati scadono. I backup falliscono in silenzio, nei modi più indegni. I bollettini di sicurezza di Coolify del 2026 ricordano utilmente che la cadenza delle patch conta. Se non puoi impegnarti su una finestra di manutenzione prima di partire, il pacchetto SaaS è onestamente la risposta giusta.

Modalità di guasto 4: la perdita di integrazioni. Le action GitHub di terze parti, i deploy di anteprima di Vercel legati alle pull request GitHub, le integrazioni di alerting ospitate di Sentry con PagerDuty e Linear, l'ampio catalogo di integrazioni di Notion. La maggior parte ha equivalenti self-hosted (Forgejo Actions, deploy via webhook di Coolify, notifiche GlitchTip, n8n come collante tra i flussi), ma le sostituzioni non sono sempre uno a uno. Prototipa il flusso che conta di più prima di impegnare il team nella migrazione. L'integrazione che dai per scontata è quella che con più probabilità ti sorprenderà.

Punto chiave della sezione: Questo stack funziona per il codice privato, i team piccoli e gli operatori volenterosi; non funziona per la visibilità dell'open source pubblico, per i team che non vogliono metterci mano, né per l'aspettativa di zero manutenzione.

Lo stack dell'operatore

Quattro livelli, quattro raccomandazioni, dette con onestà. Codice: Forgejo. Build e deploy: Coolify con il piano di amministrazione limitato, oppure Dokku, oppure Compose. Esecuzione: Vaultwarden, Uptime Kuma, GlitchTip, Portainer o Dockge. Documentazione: Docmost e OpenProject (o Plane). Avvia un pilota ridotto a 8 GB e lo stack completo basato su Forgejo a 16 GB. Aggiungi capacità per GitLab, build in parallelo, database più pesanti o carico applicativo continuo.

Se stai migrando, comincia da Uptime Kuma e da un servizio interno non critico. Offrono un modo a rischio più basso per imparare la cadenza operativa (aggiornamenti, monitoraggio, verifica dei backup e rinnovo dei certificati) prima di spostare un flusso di lavoro di squadra o un archivio di credenziali. Non fare di Vaultwarden il primo deployment di prova: spostalo solo dopo aver messo in piedi backup cifrati fuori dall'host, un test di ripristino riuscito, un'amministrazione limitata e l'autenticazione a più fattori. Quando quella cadenza è affidabile, passa a Forgejo, poi a Coolify, poi al resto.

Per i team che scelgono nello specifico GitLab CE: stabilite se la sua CI/CD nativa sostituisce un runner separato o se il vostro carico richiede ancora capacità di build dedicata.

Domande frequenti

Qual è la migliore alternativa self-hosted a Gitea nel 2026?

Forgejo è la scelta consigliata per chi inizia con il self-hosting nel 2026. Il trasferimento, nell'ottobre 2022, del marchio e del dominio di Gitea a una società a scopo di lucro senza previa approvazione della comunità ha innescato il fork Forgejo a fine 2022. Dalla v9.0 le release di Forgejo usano la GPL v3+; le precedenti release di patch v8.0 e v7.0 sono rimaste sotto MIT. Nell'uso quotidiano la parità di funzioni è vicina.

Si può eseguire Coolify in produzione in sicurezza nel 2026?

Sì, ma solo con manutenzione attiva e difesa in profondità. Esegui l'ultima release stabile già esaminata, segui i nuovi bollettini, limita i permessi del team e tieni dashboard e API dietro un firewall, una VPN o un livello di accesso fidato. Non considerare beta.451, beta.474 o qualsiasi altro livello di patch storico una soglia di sicurezza permanente.

Quanta RAM serve davvero a uno stack di sviluppo self-hosted completo?

Per un team di 2-3 sviluppatori, considera 4 GB una taglia da laboratorio per qualche servizio leggero e 8 GB un pilota ridotto senza OpenProject, Plane o build locali. Circa 8 vCPU e 16 GB di RAM sono il punto di partenza pratico per lo stack completo basato su Forgejo. La base di 8 vCPU e 16 GB di GitLab vale per GitLab stesso, mentre Sentry self-hosted richiede 16 GB di RAM più 16 GB di swap e ne consiglia 32. Valida la configurazione finale in condizioni di carico reale.

Perché GlitchTip invece di Sentry self-hosted?

Il divario di risorse e di gestione. Sentry self-hosted richiede almeno 16 GB di RAM più 16 GB di swap ed è un deployment ampio con molti servizi. GlitchTip consiglia 512 MB per il suo servizio tutto-in-uno, richiede PostgreSQL e rende Valkey opzionale. Accetta il traffico degli SDK Sentry, ma la parità di funzioni non è completa, quindi testa le funzioni e le integrazioni da cui dipendi.

Quanto costa davvero questo stack rispetto agli equivalenti SaaS?

Considera 4 GB una taglia da laboratorio per qualche servizio leggero e 8 GB un pilota ridotto senza OpenProject, Plane o build locali. Circa 8 vCPU e 16 GB di RAM sono il punto di partenza pratico per lo stack completo basato su Forgejo. Ai prezzi base pubblicati, GitHub Team, Vercel Pro, Sentry Team, Linear Basic e Notion Plus sommano circa 158 $ al mese per tre persone, prima di 1Password, costi a consumo, tasse e componenti aggiuntivi. Il self-hosting può costare sensibilmente meno, ma il tempo di chi gestisce e l'infrastruttura di backup sono costi reali.