A stack de produtividade para programadores auto-hospedada: substituir GitHub, Vercel e Sentry num único VPS em 2026

Aos preços de tabela atuais, uma equipa de 3 pessoas que use GitHub Team, Vercel Pro, Sentry Team, Linear Basic e Notion Plus começa em cerca de 158 $ por mês, antes de 1Password, encargos de utilização e extras. Uma stack auto-hospedada bem delimitada pode cortar essa fatura de forma substancial, mas a comparação justa inclui um VPS maior do que o mínimo laboratorial de 4 GB e o tempo de manutenção de que toda a gente se esquece.

Este guia destina-se ao programador ou à equipa pequena que já concluiu que «a fatura de SaaS é irritante» e que «manter código privado e fluxos de trabalho de desenvolvimento em infraestrutura de terceiros é desconfortável», e que agora quer saber o que executar em concreto. A stack tem quatro camadas: código, construir e implementar, executar e documentar. Cada camada recebe uma ferramenta recomendada, uma alternativa, o custo em recursos e o modo de falha. O âmbito é a utilização privada e em equipa num único VPS. Alojamento de e-mail, DNS, autenticação virada para o cliente e Kubernetes ficam fora do âmbito, por razões que indicaremos onde for devido.

A versão curta

Se só ler os pontos:

• Código: Forgejo por omissão. Use GitLab CE apenas se quiser git, CI/CD, registo e questões num só produto; a base atual do GitLab em nó único é de 16 GB de RAM, ficando os 8 GB reservados para ambientes com memória limitada.
• Construir e implementar: 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.
• Execute: Vaultwarden para as credenciais partilhadas, Uptime Kuma para a monitorização, GlitchTip para o registo de erros e Portainer ou Dockge para a gestão de contentores. O GlitchTip é uma implementação muito mais pequena do que o Sentry auto-hospedado, cujo mínimo oficial é de 16 GB de RAM mais 16 GB de swap.
• Documentar: Docmost para a documentação e OpenProject (ou Plane) para o acompanhamento de questões. O AFFiNE serve a equipas que preferem um modelo Notion em estilo de tela.
• Dimensionamento: Trate 4 GB como um tamanho de laboratório para alguns serviços leves, 8 GB como um piloto reduzido sem OpenProject, Plane ou compilações locais, e 16 GB como o ponto de partida prático para a stack completa baseada em Forgejo deste guia. A base de 8 vCPU e 16 GB do GitLab aplica-se ao próprio GitLab, pelo que uma stack numa só máquina baseada em GitLab exige capacidade adicional ou testes de carga à parte.
• Onde perde: Projetos de código aberto públicos com contribuidores externos. O efeito de rede do GitHub é real, e auto-hospedar custa-lhe visibilidade.

Pré-requisitos

Antes de continuar a ler, este guia parte do princípio de que:

• Um VPS Linux com Docker e Docker Compose instalados. Conte com cerca de 16 GB de RAM para a stack completa baseada em Forgejo; 8 GB chegam para um piloto reduzido que deixe de fora as ferramentas de gestão de projetos mais pesadas e as compilações locais.
• De 30 a 60 minutos de atenção por camada na implementação inicial.
• À-vontade para ler um ficheiro Compose e ajustar variáveis de ambiente.
• Disponibilidade para manter uma janela de atualização regular, aplicar correções de segurança sem demora e verificar as cópias de segurança em vez de apenas as configurar.

Se algum desses pontos for impeditivo, o pacote SaaS é mesmo a resposta certa para a sua equipa. É uma posição defensável, não um fracasso.

Camada 1, código: Forgejo, Gitea ou GitLab CE

Três opções viáveis, três pontos diferentes na curva de recursos e governação. Para quem começa a auto-hospedar em 2026, a recomendação é Forgejo primeiro.

O Forgejo foi desenhado para infraestrutura modesta e oferece pull requests, acompanhamento de questões, quadros de projeto, wikis, registos de pacotes e Forgejo Actions. Os seus fluxos de trabalho usam um formato ao estilo do GitHub Actions, mas a compatibilidade não é absoluta; teste todas as ações de terceiros de que o seu pipeline dependa.

Escolha o Gitea apenas se já depender de uma funcionalidade exclusiva dele ou se as suas ferramentas estiverem fixadas a uma versão do Gitea. Não há nada de errado com o código. A comparação oficial do Forgejo refere que o fork surgiu na sequência da transferência, em outubro de 2022, dos domínios e da marca do Gitea para uma empresa com fins lucrativos sem aprovação da comunidade; o anúncio de licenciamento do Forgejo regista a GPL v3+ para as versões a partir da v9.0.

Escolha o GitLab CE se quiser um único produto para git, CI/CD, registo de contentores e acompanhamento de questões, e se puder suportar o seu mínimo de recursos. Os requisitos atuais do GitLab definem 16 GB de RAM e 8 vCPU como base de nó único; os 8 GB destinam-se a ambientes com memória limitada. O Gitea é suficientemente leve para correr uma instância privada pequena em cerca de 1 a 2 GB de RAM, e o Forgejo é comparável, mas o dimensionamento em produção de ambos continua a depender dos repositórios, dos runners e dos utilizadores em simultâneo.

A questão do CI merece destaque. O Gitea Actions foi concebido para ser em larga medida compatível com o GitHub Actions, ao passo que o Forgejo Actions procura deliberadamente a familiaridade em vez da compatibilidade total. Muitos fluxos de trabalho exigem apenas pequenas alterações, mas as imagens de runner, as permissões, os contextos, as etiquetas e as ações de terceiros podem comportar-se de forma diferente. Teste cada fluxo e cada ação de que o seu pipeline dependa antes de migrar.

Uma ressalva aplica-se às três opções. Este guia parte de uma utilização privada e em equipa, com a superfície de administração atrás de uma VPN ou de uma lista de IP permitidos. Os serviços git públicos enfrentam tráfego de bots, abusos e compromissos de visibilidade que uma implementação privada pequena não conhece. Para código aberto público, espelhe no GitHub pela visibilidade mantendo o Forgejo como fonte de verdade, se esse modelo de governação lhe importar.

Dimensione o servidor a partir da carga de trabalho, não dos nomes dos planos de um fornecedor. Um serviço Forgejo ou Gitea autónomo para uso privado leve pode começar por volta de 1 a 2 vCPU e 1 a 2 GB de RAM. Uma stack reduzida sem OpenProject, Plane ou compilações locais pode começar por volta de 4 vCPU e 8 GB de RAM. Para a stack completa baseada em Forgejo aqui descrita, comece por volta de 8 vCPU e 16 GB de RAM e valide-a depois sob carga real de CI e de aplicações. A base oficial do GitLab, 8 vCPU e 16 GB, aplica-se ao próprio GitLab, por isso não a tome como suficiente para o GitLab mais o resto desta stack. Use armazenamento SSD ou NVMe, orce à parte repositórios, imagens de contentor, registos, bases de dados e cópias de segurança, e mantenha 20 a 30% de capacidade livre para atualizações e picos de carga.

Principal conclusão da seção: O Forgejo é a recomendação por omissão para a camada de código em 2026; o Gitea continua sólido, e o GitLab CE só é a escolha integrada quando consegue suportar a sua base de 16 GB ou opera conscientemente numa configuração limitada a 8 GB.

Camada 2, construir e implementar: Coolify (com reservas), Dokku ou Docker Compose puro

Dito com franqueza: o Coolify é a opção PaaS recomendada para esta stack se executar a versão de produção mais recente, mantiver o painel de administração fora da internet pública e acompanhar os avisos de segurança. À data do controlo de qualidade, o GitHub assinala Coolify v4.3.0 como a mais recente. Trate a aplicação de correções e o isolamento do plano de administração como requisitos operacionais, não como reforço opcional.

Dica profissional: Restrinja o painel e a API do Coolify com uma firewall, uma VPN ou um proxy de acesso de confiança. As aplicações implementadas podem continuar a receber tráfego público; o objetivo é reduzir a exposição do plano de controlo administrativo.

A alternativa para programadores a solo é o Dokku, um PaaS compacto com implementações por git push ao estilo Heroku e suporte a buildpacks. Tem menos superfície do que o Coolify e, em consequência, menos funcionalidades. Isso faz dele uma «escolha aborrecida» defensável para um ou dois programadores que não precisem de um painel.

A terceira opção a que recorrem os operadores experientes é nada de PaaS, apenas Docker Compose. Se a sua equipa já escreve ficheiros Compose e prefere ver as peças em movimento, esta é uma resposta perfeitamente sensata. Acrescente o Dockge ou o Portainer como camada de interface para gerir stacks quando quiser reiniciar com um clique em vez de docker compose restart. O compromisso é operacional: sem ambientes de pré-visualização, sem automatização de TLS integrada, sem implementações sem interrupção a não ser com trabalho. Essas funcionalidades ganham-se a escrever scripts; no Coolify vêm prontas, com o historial de segurança que lhes está associado.

LER

Melhores alternativas self-hosted ao Heroku e Vercel: Coolify, Dokku e mais

O guia da Cloudzy sobre as melhores ferramentas de CI/CD aprofunda o pipeline de construção para equipas que precisam de um runner à parte, algo de que muitas equipas pequenas dispensam assim que têm o Forgejo Actions ou o CI/CD do GitLab.

Principal conclusão da seção: O Coolify só é o PaaS recomendado na versão estável atual e com o plano de administração restringido; o Dokku é a escolha conservadora a solo; Docker Compose puro continua a ser uma terceira opção defensável.

Camada 3, executar: Vaultwarden, Uptime Kuma, GlitchTip e a gestão de contentores

É aqui que vive a maior discrepância de recursos desta stack. Os requisitos oficiais do Sentry auto-hospedado indicam como mínimo 4 núcleos de CPU, 16 GB de RAM, 16 GB de swap e 20 GB de disco livre, sendo recomendados 32 GB de RAM. O guia de instalação do GlitchTip recomenda 512 MB de RAM, exige PostgreSQL e torna o Valkey opcional. Para uma equipa pequena num só VPS, o GlitchTip é a opção por omissão prática.

As outras quatro ferramentas desta camada contam-se depressa.

O Vaultwarden é um gestor de palavras-passe compatível com o Bitwarden que suporta as aplicações móveis e as extensões de navegador do Bitwarden, além da partilha em equipa. A sua pegada real depende dos utilizadores, dos anexos e da base de dados escolhida. A comparação da Cloudzy de gestores de palavras-passe auto-hospedados aprofunda o compromisso quando precisa de permissões mais estruturadas, controlos de auditoria ou de um modelo de segurança diferente.

O Uptime Kuma é a pequena ferramenta de monitorização e alertas: verificações HTTP, TCP, ping, push e de expiração de certificados, além de páginas de estado opcionais. As notificações podem seguir por chat, e-mail ou webhooks. O consumo varia com o número de monitores e a retenção; alertar à segunda falha consecutiva é uma forma prática de abafar oscilações breves.

O GlitchTip é o registador de erros. A maioria das integrações do SDK do Sentry consegue reportar para um DSN do GlitchTip, mas a paridade de funcionalidades não é completa; teste a monitorização de desempenho, os source maps, os alertas e qualquer integração que a sua equipa considere crítica.

Escolha o Portainer ou o Dockge como interface de contentores. O Portainer abrange casos de gestão de contentores mais amplos; o Dockge mantém-se focado no Docker Compose. Para uma stack pequena só com Compose, o Dockge assenta melhor. Passe para o Portainer apenas quando precisar desse âmbito mais alargado.

Uma ergonomia útil do Compose para esta camada: mantenha cada ferramenta no seu próprio subdiretório com o seu próprio compose.yml, partilhe uma rede Docker apenas onde for preciso tráfego entre ferramentas, e ponha um único proxy inverso à frente para terminar o 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"

Dica profissional: Uma cópia de segurança só está comprovada quando o serviço pode ser restaurado e os seus dados validados. Uma vez por mês, restaure um serviço representativo num ambiente de teste isolado, arranque-o, autentique-se, inspecione registos e anexos, e confirme que a aplicação se comporta normalmente. Listar os ficheiros restaurados prova apenas que o arquivo é legível, não que a base de dados, os volumes, as permissões e o estado da aplicação podem ser recuperados com êxito.

Principal conclusão da seção: O GlitchTip cumpre o essencial do registo de erros com uma implementação drasticamente mais pequena do que o Sentry auto-hospedado, mas valide as funcionalidades e integrações do Sentry que a sua equipa usa de facto.

Camada 4, documentar: Docmost, AFFiNE e o acompanhamento de questões com OpenProject ou Plane

A interface do Notion é boa, até que um wiki em crescimento torna a navegação e a pesquisa lentas. Para uma equipa pequena, a divisão recomendada é Docmost para a documentação e o wiki, com OpenProject para o acompanhamento de questões. Substitua o OpenProject pelo Plane se a sua equipa quiser especificamente um modelo visual ao estilo do Linear e não se importar de gerir a sua implementação auto-hospedada suportada.

O Docmost é aqui o substituto auto-hospedado mais próximo do Notion, sem fingir ser o Notion. O seu editor por blocos, a hierarquia de páginas e as permissões de equipa assentam num wiki interno convencional. Dimensione esta camada pelos editores em simultâneo, pelos anexos e por saber se o PostgreSQL e o Redis partilham o mesmo anfitrião. O AFFiNE é a alternativa para equipas que preferem um modelo de tela e quadro branco às páginas encaixadas. Ambos são sensatos; escolha um.

O OpenProject cobre o acompanhamento de questões para equipas à-vontade com um fluxo ao estilo do Jira: épicos, pacotes de trabalho, sprints e registo de tempo. O Plane é a alternativa com a forma do Linear, com uma interface centrada nas questões, mais rápida, e uma pegada operacional diferente.

Reconheçamos com honestidade: a rapidez do Linear centrada no teclado é mesmo boa, e o Plane não reproduz todas as interações. Se o fluxo da sua equipa assenta na memória muscular do menu de comandos do Linear, o atrito da migração é real. Não tem de ser impeditivo, mas é um custo verdadeiro.

Principal conclusão da seção: O Docmost cobre o papel da documentação interna, ao passo que o OpenProject ou o Plane trata do acompanhamento de questões; a diferença de experiência com o teclado face ao Linear é o único ponto em que esta camada lhe pede uma cedência.

Quanto custa esta stack e em que é que ela corre

O ponto de partida prático para a stack completa baseada em Forgejo numa só máquina ronda os 8 vCPU e 16 GB de RAM. Trate 2 vCPU e 4 GB de RAM como um tamanho de laboratório para alguns serviços leves, e 4 vCPU e 8 GB de RAM como um piloto reduzido que deixa de fora o OpenProject, o Plane e as compilações locais. Os requisitos reais dependem dos utilizadores em simultâneo, da atividade de CI, do crescimento da base de dados, dos anexos, do armazenamento de imagens, dos registos e da retenção, por isso valide a stack sob carga real e mantenha 20 a 30% de capacidade livre. O escalão inicial de 16 GB consegue acomodar os seguintes serviços para uma equipa de 2 a 3 programadores pouco carregada, sujeito a testes de carga:

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

Um servidor de 4 GB só serve para alguns serviços leves. Um servidor de 8 GB é melhor tratado como um piloto reduzido sem OpenProject, Plane ou compilações locais. Comece a stack completa baseada em Forgejo nos 16 GB e acrescente capacidade quando correr GitLab, compilações em simultâneo, Plane, períodos de retenção longos ou cargas de base de dados mais pesadas. O pacote SaaS da mesma equipa inclui:

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

Com base nas tarifas base publicadas em cada página de preços (incluindo as tarifas de faturação anual quando aplicável). Os cinco produtos com preço somam cerca de 158 $ por mês para três pessoas: GitHub Team a 4 $ por utilizador nos primeiros 12 meses, três lugares de programador do Vercel Pro a 20 $ cada, Sentry Team a partir de 26 $, Linear Basic a 10 $ por utilizador, e Notion Plus a 10 $ por utilizador. Encargos de utilização, impostos, extras e 1Password ficam à parte. A infraestrutura ainda pode sair bastante mais barata, mas a comparação não significa nada sem o tempo de quem a opera.

Quando aumentar: a base do GitLab em nó único é de 8 vCPU e 16 GB de RAM. Várias compilações em simultâneo podem exigir capacidade adicional mesmo sem GitLab. O Sentry auto-hospedado também começa nos 16 GB de RAM mais 16 GB de swap e recomenda 32 GB, razão pela qual este guia recomenda o GlitchTip para a stack numa só máquina.

O custo sem preço é o tempo de operação. Como estimativa de planeamento, reserve 1 a 2 horas por mês para atualizações e verificação de cópias de segurança, mais uma passagem semanal breve pelos avisos de segurança dos projetos que executa. O número real depende do volume de alterações, da resposta a incidentes e do quanto automatiza. Não é zero, e pertence ao modelo de custos.

O método de implementação muda a comodidade, não os requisitos de operação. Quer use um ficheiro Compose oficial quer um modelo de um catálogo: fixe as versões das imagens, defina limites de CPU e memória, guarde os dados dos serviços em volumes nomeados e teste tanto as cópias como os restauros. Juntar a stack toda num só anfitrião cria também um domínio de falha partilhado, por isso isole os serviços críticos quando uma paragem ou a exposição de credenciais tiver grande impacto.

Se quiser implementar esta stack, compare os nossos planos de cloud VPS por CPU, RAM, armazenamento SSD ou NVMe, tráfego incluído e região, e depois aplique o quadro de dimensionamento acima. Para uma instalação mais rápida, veja o nosso catálogo de aplicações num clique, mas fixe na mesma as versões, defina limites de recursos e verifique as cópias de segurança antes de entrar em produção.

Principal conclusão da seção: Use 4 GB para um laboratório pequeno, 8 GB para um piloto reduzido e cerca de 8 vCPU com 16 GB de RAM como ponto de partida prático da stack completa baseada em Forgejo. Acrescente capacidade para GitLab, compilações em simultâneo, ferramentas de gestão de projetos mais pesadas e bases de dados que crescem.

Onde auto-hospedar esta stack falha mesmo

Quatro modos de falha, ditos sem rodeios, porque o resto deste guia foi um argumento a favor da abordagem.

Modo de falha 1: o efeito de rede do GitHub nos projetos de código aberto públicos. O git auto-hospedado é o certo para código privado. É o errado para projetos cujo valor todo depende de contribuidores externos o encontrarem. O GitHub é onde os programadores olham primeiro. Pull requests, forks, estrelas, o sinal implícito de confiança de estar no github.com, as integrações com ferramentas de terceiros, tudo isso. Se o seu projeto for de código aberto público, o padrão honesto é espelhar no GitHub pela visibilidade mantendo a fonte de verdade no Forgejo. Não espere que uma instância auto-hospedada substitua a visibilidade do GitHub para trabalho público. Não vai.

Modo de falha 2: tráfego de bots e scrapers nas instâncias Git públicas. Os serviços Forgejo e Gitea expostos ao público precisam de controlos antiabuso, limites de taxa, monitorização e capacidade suficiente para tráfego imprevisível. Este guia parte de uma utilização privada e em equipa, com a superfície de administração atrás de uma VPN ou de uma lista de IP permitidos. Uma forja verdadeiramente pública obedece a outro modelo de ameaça e de capacidade.

Modo de falha 3: o peso da manutenção. «O departamento de informática é você» é o lugar-comum, e é em boa parte verdade. As atualizações partem coisas. Os ficheiros Compose desviam-se. Os certificados expiram. As cópias de segurança falham em silêncio, das formas mais indignas. Os avisos de 2026 do Coolify são um lembrete útil de que a cadência de correções importa. Se não conseguir comprometer-se com uma janela de manutenção antes de avançar, o pacote SaaS é honestamente a resposta certa.

Modo de falha 4: a perda de integrações. Ações de terceiros no GitHub, implementações de pré-visualização do Vercel ligadas a pull requests do GitHub, as integrações de alerta alojadas do Sentry com o PagerDuty e o Linear, o vasto catálogo de integrações do Notion. A maioria tem equivalentes auto-hospedados (Forgejo Actions, implementações por webhook do Coolify, notificações do GlitchTip, n8n como cola entre fluxos), mas as substituições nem sempre são um para um. Faça um protótipo do fluxo que mais importa antes de comprometer a equipa com a migração. A integração que dá por garantida é a que tem mais probabilidade de o surpreender.

Principal conclusão da seção: Esta stack funciona para código privado, equipas pequenas e operadores dispostos; não funciona para a visibilidade de código aberto público, para equipas que não querem mexer em nada, nem para expectativas de manutenção zero.

A stack do operador

Quatro camadas, quatro recomendações, ditas com honestidade. Código: Forgejo. Construir e implementar: Coolify com o plano de administração restringido, ou Dokku, ou Compose. Executar: Vaultwarden, Uptime Kuma, GlitchTip, Portainer ou Dockge. Documentar: Docmost e OpenProject (ou Plane). Comece um piloto reduzido nos 8 GB e a stack completa baseada em Forgejo nos 16 GB. Acrescente capacidade para GitLab, compilações em simultâneo, bases de dados mais pesadas ou carga aplicacional sustentada.

Se está a migrar, comece pelo Uptime Kuma e por um serviço interno não crítico. Dão-lhe uma forma de menor risco de aprender a cadência operacional (atualizações, monitorização, verificação de cópias e renovação de certificados) antes de mover um fluxo de equipa ou um cofre de credenciais. Não faça do Vaultwarden a primeira implementação de teste: mova-o só depois de ter cópias cifradas fora do anfitrião, um teste de restauro bem-sucedido, administração restringida e MFA. Assim que essa cadência for fiável, passe ao Forgejo, depois ao Coolify, depois ao resto.

Para as equipas que escolhem especificamente o GitLab CE, decidam se o seu CI/CD nativo substitui um runner à parte ou se a vossa carga continua a precisar de capacidade de compilação dedicada.

Perguntas frequentes

Qual é a melhor alternativa auto-hospedada ao Gitea em 2026?

O Forgejo é a escolha recomendada para quem começa a auto-hospedar em 2026. A transferência, em outubro de 2022, da marca e do domínio do Gitea para uma empresa com fins lucrativos sem aprovação prévia da comunidade motivou o fork Forgejo no final de 2022. A partir da v9.0, as versões do Forgejo usam GPL v3+; as versões de correção anteriores v8.0 e v7.0 mantiveram-se sob MIT. No dia a dia, a paridade de funcionalidades é próxima.

É possível executar o Coolify com segurança em produção em 2026?

Sim, mas só com manutenção ativa e defesa em profundidade. Execute a versão estável mais recente já revista, acompanhe os novos avisos, restrinja as permissões da equipa e mantenha o painel e a API atrás de uma firewall, de uma VPN ou de uma camada de acesso de confiança. Não trate a beta.451, a beta.474 nem qualquer outro nível de correção histórico como um limiar seguro permanente.

De quanta RAM precisa realmente uma stack de desenvolvimento auto-hospedada completa?

Para uma equipa de 2 a 3 programadores, trate 4 GB como um tamanho de laboratório para alguns serviços leves e 8 GB como um piloto reduzido sem OpenProject, Plane ou compilações locais. Cerca de 8 vCPU e 16 GB de RAM são o ponto de partida prático para a stack completa baseada em Forgejo. A base de 8 vCPU e 16 GB do GitLab aplica-se ao próprio GitLab, ao passo que o Sentry auto-hospedado exige 16 GB de RAM mais 16 GB de swap e recomenda 32 GB. Valide a configuração final em condições de carga real.

Porquê GlitchTip em vez de Sentry auto-hospedado?

A diferença de recursos e de operação. O Sentry auto-hospedado exige pelo menos 16 GB de RAM mais 16 GB de swap e é uma implementação grande com vários serviços. O GlitchTip recomenda 512 MB para o seu serviço tudo-em-um, exige PostgreSQL e torna o Valkey opcional. Aceita o tráfego dos SDK do Sentry, mas a paridade de funcionalidades não é completa, por isso teste as funcionalidades e integrações de que depende.

Quanto custa realmente esta stack face aos equivalentes SaaS?

Trate 4 GB como um tamanho de laboratório para alguns serviços leves e 8 GB como um piloto reduzido sem OpenProject, Plane ou compilações locais. Cerca de 8 vCPU e 16 GB de RAM são o ponto de partida prático para a stack completa baseada em Forgejo. Aos preços base publicados, GitHub Team, Vercel Pro, Sentry Team, Linear Basic e Notion Plus somam cerca de 158 $ por mês para três pessoas, antes de 1Password, encargos de utilização, impostos e extras. Auto-hospedar pode sair bastante mais barato, mas o tempo de quem opera e a infraestrutura de cópias de segurança são custos reais.