El stack de productividad para desarrolladores autoalojado: sustituir GitHub, Vercel y Sentry en un solo VPS en 2026

A los precios de lista actuales, un equipo de 3 personas que use GitHub Team, Vercel Pro, Sentry Team, Linear Basic y Notion Plus parte de unos 158 $ al mes, antes de 1Password, los cargos por uso y los complementos. Un stack autoalojado bien acotado puede recortar esa factura de forma notable, pero la comparación justa incluye un VPS mayor que el mínimo de laboratorio de 4 GB y el tiempo de mantenimiento que todo el mundo olvida.

Esta guía es para el desarrollador o el equipo pequeño que ya ha decidido que «la factura de SaaS es molesta» y que «mantener código privado y flujos de trabajo de desarrollo en infraestructura de terceros resulta incómodo», y ahora quiere saber qué ejecutar exactamente. El stack tiene cuatro capas: código, construir y desplegar, ejecutar y documentar. Cada capa recibe una herramienta recomendada, una alternativa, el coste en recursos y el modo de fallo. El alcance es el uso privado y en equipo sobre un solo VPS. El alojamiento de correo, el DNS, la autenticación de cara al cliente y Kubernetes quedan fuera del alcance, por razones que expondremos donde corresponda.

La versión corta

Si solo lees los puntos clave:

• Código: Forgejo por defecto. Usa GitLab CE solo si quieres git, CI/CD, registro e incidencias en un único producto; la base actual de GitLab en nodo único es de 16 GB de RAM, y los 8 GB quedan reservados para entornos con memoria limitada.
• Construir y desplegar: 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.
• Ejecuta: Vaultwarden para las credenciales compartidas, Uptime Kuma para la monitorización, GlitchTip para el seguimiento de errores y Portainer o Dockge para la gestión de contenedores. GlitchTip es un despliegue mucho más pequeño que Sentry autoalojado, cuyo mínimo oficial son 16 GB de RAM más 16 GB de swap.
• Documentar: Docmost para la documentación y OpenProject (o Plane) para el seguimiento de incidencias. AFFiNE encaja con equipos que prefieren un modelo tipo Notion sobre lienzo.
• Dimensionamiento: Considera 4 GB un tamaño de laboratorio para unos pocos servicios ligeros, 8 GB un piloto reducido sin OpenProject, Plane ni compilaciones locales, y 16 GB el punto de partida práctico del stack completo basado en Forgejo de esta guía. La base de 8 vCPU y 16 GB de GitLab se aplica a GitLab en sí, así que un stack de una sola máquina basado en GitLab exige capacidad adicional o pruebas de carga aparte.
• Dónde pierde: Los proyectos de código abierto públicos con colaboradores externos. El efecto de red de GitHub es real, y autoalojarte te cuesta visibilidad.

Requisitos previos

Antes de seguir leyendo, esta guía da por hecho:

• Un VPS Linux con Docker y Docker Compose instalados. Prevé unos 16 GB de RAM para el stack completo basado en Forgejo; 8 GB bastan para un piloto reducido que deje fuera las herramientas de gestión de proyectos más pesadas y las compilaciones locales.
• De 30 a 60 minutos de atención por capa para el despliegue inicial.
• Soltura para leer un archivo Compose y ajustar variables de entorno.
• Disposición a mantener una ventana de actualización periódica, aplicar los parches de seguridad sin demora y verificar las copias de seguridad en vez de limitarse a configurarlas.

Si alguno de esos puntos es un impedimento, el paquete SaaS es de verdad la respuesta correcta para tu equipo. Es una postura defendible, no un fracaso.

Capa 1, código: Forgejo, Gitea o GitLab CE

Tres opciones viables, tres puntos distintos en la curva de recursos y gobernanza. Para quien empieza a autoalojar en 2026, la recomendación es Forgejo primero.

Forgejo está pensado para infraestructura modesta y ofrece pull requests, seguimiento de incidencias, tableros de proyecto, wikis, registros de paquetes y Forgejo Actions. Sus flujos de trabajo usan un formato al estilo de GitHub Actions, pero la compatibilidad no es absoluta; prueba todas las acciones de terceros de las que dependa tu pipeline.

Elige Gitea solo si ya dependes de una función exclusiva de Gitea o tienes herramientas fijadas a una versión de Gitea. El código no tiene nada de malo. La comparativa oficial de Forgejo señala que el fork siguió al traspaso, en octubre de 2022, de los dominios y la marca de Gitea a una empresa con ánimo de lucro sin la aprobación de la comunidad; el anuncio de licencia de Forgejo deja constancia de la licencia GPL v3+ para las versiones a partir de la v9.0.

Elige GitLab CE si quieres un único producto para git, CI/CD, registro de contenedores y seguimiento de incidencias, y puedes permitirte su suelo de recursos. Los requisitos actuales de GitLab fijan 16 GB de RAM y 8 vCPU como base para un solo nodo; los 8 GB son para entornos con memoria limitada. Gitea es lo bastante ligero para sostener una instancia privada pequeña con 1 o 2 GB de RAM, y Forgejo es comparable, pero el dimensionado en producción de ambos sigue dependiendo de los repositorios, los runners y los usuarios simultáneos.

La cuestión del CI merece señalarse. Gitea Actions está pensado para ser en buena medida compatible con GitHub Actions, mientras que Forgejo Actions busca a propósito la familiaridad antes que la compatibilidad total. Muchos flujos de trabajo solo requieren cambios menores, pero las imágenes de runner, los permisos, los contextos, las etiquetas y las acciones de terceros pueden comportarse de otro modo. Prueba cada flujo y cada acción de la que dependa tu pipeline antes de migrar.

Una salvedad vale para las tres opciones. Esta guía presupone un uso privado y en equipo, con la superficie de administración detrás de una VPN o una lista de IP permitidas. Los servicios git públicos afrontan tráfico de bots, abusos y concesiones de visibilidad que un despliegue privado pequeño no sufre. Para código abierto público, replica en GitHub por visibilidad y conserva Forgejo como fuente de verdad si ese modelo de gobernanza te importa.

Dimensiona el servidor a partir de la carga de trabajo, no de los nombres de los planes de un proveedor. Un servicio Forgejo o Gitea aislado para uso privado ligero puede arrancar en torno a 1 o 2 vCPU y 1 o 2 GB de RAM. Un stack reducido sin OpenProject, Plane ni compilaciones locales puede arrancar en torno a 4 vCPU y 8 GB de RAM. Para el stack completo basado en Forgejo que aquí se describe, parte de unos 8 vCPU y 16 GB de RAM y valídalo después bajo carga real de CI y de aplicaciones. La base oficial de GitLab, 8 vCPU y 16 GB, se aplica a GitLab en sí, así que no la des por suficiente para GitLab más el resto de este stack. Usa almacenamiento SSD o NVMe, presupuesta aparte repositorios, imágenes de contenedor, registros, bases de datos y copias de seguridad, y deja entre un 20 y un 30% de capacidad libre para actualizaciones y picos de carga.

Conclusión clave de la sección: Forgejo es la recomendación por defecto para la capa de código en 2026; Gitea sigue siendo sólido, y GitLab CE es la opción integrada solo si puedes permitirte su base de 16 GB o si operas a sabiendas en una configuración limitada de 8 GB.

Capa 2, construir y desplegar: Coolify (con reservas), Dokku o Docker Compose puro

Dicho con honestidad: Coolify es la opción PaaS recomendada para este stack si ejecutas la última versión de producción, mantienes el panel de administración fuera de la internet pública y sigues los avisos de seguridad. En el momento del control de calidad, GitHub marca Coolify v4.3.0 como la más reciente. Trata los parches y el aislamiento del plano de administración como requisitos operativos, no como un endurecimiento opcional.

Consejo pro: Restringe el panel y la API de Coolify con un cortafuegos, una VPN o un proxy de acceso de confianza. Las aplicaciones desplegadas pueden seguir recibiendo tráfico público; el objetivo es reducir la exposición del plano de control administrativo.

La alternativa para desarrolladores en solitario es Dokku, un PaaS compacto con despliegues por git push al estilo de Heroku y soporte de buildpacks. Tiene menos superficie que Coolify y, en consecuencia, menos funciones. Eso lo convierte en una «elección aburrida» defendible para uno o dos desarrolladores que no necesitan un panel.

La tercera opción a la que recurren los operadores con experiencia es nada de PaaS, solo Docker Compose. Si tu equipo ya escribe archivos Compose y prefieres ver las piezas móviles, es una respuesta perfectamente razonable. Añade Dockge o Portainer como capa de interfaz para gestionar los stacks cuando quieras reiniciar con un clic en vez de con docker compose restart. La concesión es operativa: sin entornos de vista previa, sin automatización de TLS integrada, sin despliegues sin cortes salvo que te lo trabajes. Esas funciones se ganan escribiendo scripts; con Coolify vienen ya hechas, con el historial de seguridad que las acompaña.

LEER

Las mejores alternativas autoalojadas a Heroku y Vercel: Coolify, Dokku y más

La guía de Cloudzy sobre las mejores herramientas de CI/CD profundiza en la cadena de construcción para equipos que necesitan un runner aparte, algo de lo que muchos equipos pequeños prescinden una vez que tienen Forgejo Actions o el CI/CD de GitLab.

Conclusión clave de la sección: Coolify es el PaaS recomendado solo en la versión estable actual y con su plano de administración restringido; Dokku es la opción conservadora en solitario; Docker Compose puro sigue siendo una tercera opción defendible.

Capa 3, ejecutar: Vaultwarden, Uptime Kuma, GlitchTip y la gestión de contenedores

Aquí es donde vive la mayor brecha de recursos de este stack. Los requisitos oficiales de Sentry autoalojado indican como mínimo 4 núcleos de CPU, 16 GB de RAM, 16 GB de swap y 20 GB de disco libre, con 32 GB de RAM recomendados. La guía de instalación de GlitchTip recomienda 512 MB de RAM, exige PostgreSQL y deja Valkey como opcional. Para un equipo pequeño en un solo VPS, GlitchTip es la opción por defecto práctica.

Las otras cuatro herramientas de esta capa se cuentan en poco.

Vaultwarden es un gestor de contraseñas compatible con Bitwarden que admite las aplicaciones móviles y las extensiones de navegador de Bitwarden, además del uso compartido en equipo. Su huella real depende de los usuarios, los adjuntos y la base de datos elegida. La comparativa de Cloudzy de gestores de contraseñas autoalojados profundiza en la concesión cuando necesitas permisos más estructurados, controles de auditoría u otro modelo de seguridad.

Uptime Kuma es la pequeña herramienta de monitorización y alertas: comprobaciones HTTP, TCP, ping, push y de caducidad de certificados, más páginas de estado opcionales. Las notificaciones pueden ir por chat, correo o webhooks. El consumo varía con el número de monitores y la retención; alertar al segundo fallo consecutivo es una forma práctica de acallar las oscilaciones breves.

GlitchTip es el rastreador de errores. La mayoría de las integraciones del SDK de Sentry pueden reportar a un DSN de GlitchTip, pero la paridad de funciones no es completa; prueba la monitorización de rendimiento, los source maps, las alertas y cualquier integración que tu equipo considere crítica.

Elige Portainer o Dockge como interfaz de contenedores. Portainer abarca más casos de gestión; Dockge se ciñe a Docker Compose. Para un stack pequeño y solo con Compose, Dockge encaja mejor. Pásate a Portainer solo cuando necesites ese alcance más amplio.

Una ergonomía de Compose útil para esta capa: mantén cada herramienta en su propio subdirectorio con su propio compose.yml, comparte una red de Docker solo donde haga falta tráfico entre herramientas, y pon un único proxy inverso delante para terminar 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"

Consejo pro: Una copia de seguridad solo queda demostrada cuando el servicio puede restaurarse y sus datos validarse. Una vez al mes, restaura un servicio representativo en un entorno de pruebas aislado, arráncalo, autentícate, inspecciona registros y adjuntos, y confirma que la aplicación se comporta con normalidad. Listar los archivos restaurados solo demuestra que el archivo comprimido se puede leer, no que la base de datos, los volúmenes, los permisos y el estado de la aplicación puedan recuperarse con éxito.

Conclusión clave de la sección: GlitchTip cumple con lo esencial del seguimiento de errores con un despliegue muchísimo más pequeño que Sentry autoalojado, pero valida las funciones e integraciones de Sentry que tu equipo usa de verdad.

Capa 4, documentar: Docmost, AFFiNE y el seguimiento de incidencias con OpenProject o Plane

La interfaz de Notion está bien hasta que un wiki que crece hace que la navegación y la búsqueda se sientan lentas. El reparto recomendado para un equipo pequeño es Docmost para la documentación y el wiki, con OpenProject para el seguimiento de incidencias. Sustituye OpenProject por Plane si tu equipo quiere concretamente un modelo visual al estilo de Linear y se ve capaz de gestionar su despliegue autoalojado soportado.

Docmost es aquí el sustituto autoalojado más próximo a Notion, sin pretender ser Notion. Su editor por bloques, su jerarquía de páginas y sus permisos de equipo encajan con un wiki interno convencional. Dimensiona esta capa según los editores simultáneos, los adjuntos y si PostgreSQL y Redis comparten el mismo host. AFFiNE es la alternativa para equipos que prefieren un modelo de lienzo y pizarra a las páginas anidadas. Ambos son razonables; elige uno.

OpenProject cubre el seguimiento de incidencias para equipos cómodos con un flujo al estilo de Jira: épicas, paquetes de trabajo, sprints y control de tiempo. Plane es la alternativa al estilo de Linear, con una interfaz centrada en las incidencias, más rápida, y una huella operativa distinta.

Reconozcámoslo con honestidad: la velocidad de Linear centrada en el teclado es de verdad buena, y Plane no reproduce todas las interacciones. Si el flujo de tu equipo se apoya en la memoria muscular del menú de comandos de Linear, la fricción de la migración es real. No tiene por qué ser un impedimento, pero es un coste real.

Conclusión clave de la sección: Docmost cubre el papel de la documentación interna, mientras que OpenProject o Plane se ocupa del seguimiento de incidencias; la brecha de experiencia con el teclado frente a Linear es el único punto en que esta capa te pide ceder.

Lo que cuesta este stack y sobre qué corre

El punto de partida práctico para el stack completo basado en Forgejo en una sola máquina ronda los 8 vCPU y 16 GB de RAM. Considera 2 vCPU y 4 GB de RAM un tamaño de laboratorio para unos pocos servicios ligeros, y 4 vCPU y 8 GB de RAM un piloto reducido que deja fuera OpenProject, Plane y las compilaciones locales. Los requisitos reales dependen de los usuarios simultáneos, la actividad de CI, el crecimiento de la base de datos, los adjuntos, el almacenamiento de imágenes, los registros y la retención, así que valida el stack bajo carga real y deja entre un 20 y un 30% de capacidad libre. El nivel de partida de 16 GB puede alojar los siguientes servicios para un equipo de 2 o 3 desarrolladores poco cargado, sujeto a pruebas de carga:

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

Un servidor de 4 GB solo sirve para unos pocos servicios ligeros. A uno de 8 GB conviene tratarlo como un piloto reducido sin OpenProject, Plane ni compilaciones locales. Arranca el stack completo basado en Forgejo en 16 GB y añade capacidad cuando ejecutes GitLab, compilaciones simultáneas, Plane, periodos de retención largos o cargas de base de datos más pesadas. El paquete SaaS del mismo equipo incluye:

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

Tomando las tarifas base publicadas en cada página de precios (incluidas las tarifas de facturación anual cuando corresponde). Los cinco productos con precio suman unos 158 $ al mes para tres personas: GitHub Team a 4 $ por usuario los primeros 12 meses, tres puestos de desarrollador de Vercel Pro a 20 $ cada uno, Sentry Team desde 26 $, Linear Basic a 10 $ por usuario, y Notion Plus a 10 $ por usuario. Los cargos por uso, los impuestos, los complementos y 1Password van aparte. La infraestructura todavía puede salir bastante más barata, pero la comparación no significa nada sin el tiempo del operador.

Cuándo subir de talla: la base de GitLab en nodo único son 8 vCPU y 16 GB de RAM. Varias compilaciones simultáneas pueden exigir capacidad extra incluso sin GitLab. Sentry autoalojado también arranca en 16 GB de RAM más 16 GB de swap y recomienda 32, y por eso esta guía recomienda GlitchTip para el stack de una sola máquina.

El coste sin precio es el tiempo de operación. Como estimación de planificación, reserva de 1 a 2 horas al mes para actualizaciones y verificación de copias de seguridad, más un repaso semanal breve a los avisos de seguridad de los proyectos que ejecutas. La cifra real depende del volumen de cambios, la respuesta a incidentes y cuánto automatices. No es cero, y le corresponde estar en el modelo de costes.

El método de despliegue cambia la comodidad, no los requisitos de operación. Ya uses un archivo Compose oficial o una plantilla de un catálogo, fija las versiones de imagen, pon límites de CPU y memoria, guarda los datos de servicio en volúmenes con nombre y prueba tanto las copias como las restauraciones. Juntar todo el stack en un solo host crea además un dominio de fallo compartido, así que aísla los servicios críticos cuando una caída o una fuga de credenciales tendría mucho impacto.

Si quieres desplegar este stack, compara nuestros planes de cloud VPS por CPU, RAM, almacenamiento SSD o NVMe, cuota de transferencia y región, y luego aplica el marco de dimensionado de arriba. Para montarlo más rápido, echa un vistazo a nuestro catálogo de aplicaciones en un clic, pero fija igualmente las versiones, pon límites de recursos y verifica las copias antes de pasar a producción.

Conclusión clave de la sección: Usa 4 GB para un laboratorio pequeño, 8 GB para un piloto reducido y unos 8 vCPU con 16 GB de RAM como punto de partida práctico del stack completo basado en Forgejo. Añade capacidad para GitLab, compilaciones simultáneas, herramientas de gestión de proyectos más pesadas y bases de datos que crecen.

Dónde autoalojar este stack falla de verdad

Cuatro modos de fallo, dichos sin rodeos, porque el resto de esta guía ha sido un alegato a favor del enfoque.

Modo de fallo 1: el efecto de red de GitHub para los proyectos de código abierto públicos. El git autoalojado es lo correcto para código privado. Es lo incorrecto para proyectos cuyo valor entero depende de que colaboradores externos te encuentren. GitHub es donde los desarrolladores miran primero. Pull requests, forks, estrellas, la señal implícita de confianza de estar en github.com, las integraciones con herramientas de terceros, todo eso. Si tu proyecto es de código abierto público, el patrón honesto es replicar en GitHub por visibilidad y conservar la fuente de verdad en Forgejo. No esperes que una instancia autoalojada sustituya la capacidad de descubrimiento de GitHub para trabajo público. No lo hará.

Modo de fallo 2: el tráfico de bots y raspadores en las instancias Git públicas. Los servicios Forgejo y Gitea expuestos al público necesitan controles antiabuso, límites de tasa, monitorización y capacidad suficiente para un tráfico impredecible. Esta guía presupone un uso privado y en equipo, con la superficie de administración detrás de una VPN o una lista de IP permitidas. Una forja realmente pública responde a otro modelo de amenaza y de capacidad.

Modo de fallo 3: la carga de mantenimiento. «Tú eres el departamento de informática» es el tópico, y en buena medida es cierto. Las actualizaciones rompen cosas. Los archivos Compose se desvían. Los certificados caducan. Las copias de seguridad fallan en silencio de las formas más indignas. Los avisos de 2026 de Coolify son un recordatorio útil de que la cadencia de parches importa. Si no puedes comprometerte a una ventana de mantenimiento antes de firmar, el paquete SaaS es sinceramente la respuesta correcta.

Modo de fallo 4: la pérdida de integraciones. Las acciones de GitHub de terceros, los despliegues de vista previa de Vercel ligados a los pull requests de GitHub, las integraciones de alertas alojadas de Sentry con PagerDuty y Linear, el amplio catálogo de integraciones de Notion. La mayoría tiene equivalentes autoalojados (Forgejo Actions, despliegues por webhook de Coolify, notificaciones de GlitchTip, n8n como pegamento entre flujos), pero las sustituciones no siempre son uno a uno. Haz un prototipo del flujo que más importa antes de comprometer al equipo con la migración. La integración que das por sentada es la que más probabilidades tiene de sorprenderte.

Conclusión clave de la sección: Este stack funciona con código privado, equipos pequeños y operadores dispuestos; no funciona para la visibilidad del código abierto público, los equipos que no quieren tocar nada ni las expectativas de cero mantenimiento.

El stack del operador

Cuatro capas, cuatro recomendaciones, dichas con honestidad. Código: Forgejo. Construir y desplegar: Coolify con el plano de administración restringido, o Dokku, o Compose. Ejecutar: Vaultwarden, Uptime Kuma, GlitchTip, Portainer o Dockge. Documentar: Docmost y OpenProject (o Plane). Arranca un piloto reducido en 8 GB y el stack completo basado en Forgejo en 16 GB. Añade capacidad para GitLab, compilaciones simultáneas, bases de datos más pesadas o carga aplicativa sostenida.

Si vas a migrar, empieza por Uptime Kuma y un servicio interno no crítico. Ofrecen una forma de menor riesgo de aprender la cadencia operativa (actualizaciones, monitorización, verificación de copias y renovación de certificados) antes de mover un flujo de equipo o un almacén de credenciales. No hagas de Vaultwarden el primer despliegue de prueba: muévelo solo cuando tengas copias cifradas fuera del host, una prueba de restauración exitosa, administración restringida y MFA. Cuando esa cadencia sea fiable, pasa a Forgejo, luego a Coolify y luego al resto.

Para los equipos que eligen concretamente GitLab CE, decidid si su CI/CD nativo sustituye a un runner aparte o si vuestra carga sigue necesitando capacidad de compilación dedicada.

Preguntas frecuentes

¿Cuál es la mejor alternativa autoalojada a Gitea en 2026?

Forgejo es la opción recomendada para quien empieza a autoalojar en 2026. El traspaso, en octubre de 2022, de la marca y el dominio de Gitea a una empresa con ánimo de lucro sin aprobación previa de la comunidad provocó el fork Forgejo a finales de 2022. A partir de la v9.0, las versiones de Forgejo usan GPL v3+; las versiones de parche anteriores v8.0 y v7.0 siguieron bajo MIT. En el día a día, la paridad de funciones es cercana.

¿Se puede ejecutar Coolify con seguridad en producción en 2026?

Sí, pero solo con mantenimiento activo y defensa en profundidad. Ejecuta la última versión estable revisada, vigila los nuevos avisos, restringe los permisos del equipo y mantén el panel y la API detrás de un cortafuegos, una VPN o una capa de acceso de confianza. No tomes beta.451, beta.474 ni ningún otro nivel de parche histórico como un umbral seguro permanente.

¿Cuánta RAM necesita realmente un stack de desarrollo autoalojado completo?

Para un equipo de 2 o 3 desarrolladores, considera 4 GB un tamaño de laboratorio para unos pocos servicios ligeros y 8 GB un piloto reducido sin OpenProject, Plane ni compilaciones locales. Unos 8 vCPU y 16 GB de RAM son el punto de partida práctico del stack completo basado en Forgejo. La base de 8 vCPU y 16 GB de GitLab se aplica a GitLab en sí, mientras que Sentry autoalojado exige 16 GB de RAM más 16 GB de swap y recomienda 32. Valida la configuración final en condiciones de carga real.

¿Por qué GlitchTip en lugar de Sentry autoalojado?

La brecha de recursos y de operación. Sentry autoalojado exige al menos 16 GB de RAM más 16 GB de swap y es un despliegue grande con múltiples servicios. GlitchTip recomienda 512 MB para su servicio todo en uno, exige PostgreSQL y deja Valkey como opcional. Acepta el tráfico de los SDK de Sentry, pero la paridad de funciones no es completa, así que prueba las funciones e integraciones de las que dependas.

¿Cuánto cuesta realmente este stack frente a los equivalentes SaaS?

Considera 4 GB un tamaño de laboratorio para unos pocos servicios ligeros y 8 GB un piloto reducido sin OpenProject, Plane ni compilaciones locales. Unos 8 vCPU y 16 GB de RAM son el punto de partida práctico del stack completo basado en Forgejo. A los precios base publicados, GitHub Team, Vercel Pro, Sentry Team, Linear Basic y Notion Plus suman unos 158 $ al mes para tres personas, antes de 1Password, cargos por uso, impuestos y complementos. Autoalojar puede salir bastante más barato, pero el tiempo del operador y la infraestructura de copias son costes reales.