Self-hosting con Docker en AI PC: RAM real y config

Correr tus propios servicios de desarrollo en tu máquina, sin depender de GitHub ni Docker Hub, hoy es viable con tres contenedores livianos. El self-hosting de servicios de desarrollo con Docker (Gitea, un registry propio y un reverse proxy como Nginx Proxy Manager o Traefik) consume entre 1,5 y 2,5 GB de RAM en reposo según las mediciones de julio 2026, y arranca con un solo docker-compose up.

Un dev vietnamita publicó el 2 de julio de 2026 sus números corriendo este stack en una AI PC Copilot+. Los datos están buenos. La conclusión de que el NPU sirve para esto, no tanto (ya vamos a ver por qué).

El self-hosting es correr en tu propia infraestructura los servicios que normalmente alquilás como SaaS. En vez de subir tu código a GitHub y tus imágenes a Docker Hub, montás un Git server (Gitea), un almacén de imágenes (Docker Registry) y un reverse proxy que enruta todo por nombres de dominio locales. Con Docker Compose, esos tres servicios viven en contenedores aislados sobre tu equipo.

¿Qué es el self-hosting de servicios de desarrollo con Docker?

Ponele que estás laburando en un proyecto con dos compañeros y no querés que el código privado viva en un servidor ajeno. O que trabajás desde un lugar con internet flojo y necesitás clonar repos sin depender de la nube. Ahí es donde el self-hosting de servicios de desarrollo con Docker empieza a tener sentido.

Gitea es un servidor Git liviano, escrito en Go, que hace casi todo lo que hace GitHub (repos, issues, pull requests, CI básico) pero corriendo en tu máquina. El Docker Registry guarda tus imágenes de contenedor sin subirlas a un servicio público. Y el reverse proxy es el portero: recibe las peticiones y las manda al contenedor que corresponde. Lo explicamos a fondo en automatizar deployment con CI/CD moderno.

¿Para quién tiene sentido? Equipos chicos, desarrollo offline, testing local y cualquiera que priorice control y privacidad sobre comodidad. Eso sí: si sos vos solo con un proyecto y buena conexión, quizás el SaaS te alcance de sobra.

¿Por qué usar Docker en lugar de instalar los servicios directamente?

Podrías instalar Gitea a mano, configurar PostgreSQL, después pelearte con las versiones de Nginx en Windows y rezar para que todo conviva. Docker te evita ese baile.

• Reproducibilidad: el mismo docker-compose.yml levanta lo mismo en tu máquina y en la de tu compañero. Sin “en mi PC funciona”.
• Aislamiento: cada servicio corre en su contenedor. Si Gitea se rompe, el registry ni se entera.
• Versionado: cambiás la etiqueta de la imagen (gitea:1.22 a gitea:1.23) y probás sin desinstalar nada.

La contra es el overhead. Docker Desktop en Windows corre sobre WSL2, que se come su porción de RAM antes de que levantes un solo contenedor. En una máquina con 16 GB no lo vas a notar. En una con 8 GB, ojo.

¿Cómo configurar Gitea, Registry y Nginx Proxy con Docker Compose?

La idea es un solo archivo docker-compose.yml que declare los tres servicios, sus volúmenes (para que los datos sobrevivan a un reinicio) y los puertos. La estructura básica, según el ejemplo publicado en dev.to, define cada servicio con su imagen, monta un volumen persistente y expone el proxy hacia afuera. Te puede servir nuestra cobertura de elegir entre Jenkins y GitHub Actions.

• Gitea guarda repos y config en un volumen (ej. ./gitea-data) para no perder nada al bajar el contenedor.
• Registry monta ./registry-data:/var/lib/registry, donde quedan tus imágenes.
• Nginx Proxy lee el socket de Docker (/var/run/docker.sock) para enrutar automáticamente, y monta ./certs para los certificados.

Levantás todo con docker compose up -d, revisás que esté corriendo con docker ps y listo. Si algo no arranca, docker compose logs te dice dónde se cayó.

¿Cuánta RAM y CPU consume corriendo 24/7?

Acá viene lo bueno, porque son datos medidos, no estimaciones de folleto. Con los tres contenedores en reposo, el consumo se mantiene estable. En pico liviano no pasa de 3 GB de RAM.

Servicio	RAM en reposo	Rol
Gitea	300-500 MB	Servidor Git
Docker Registry	100-200 MB	Almacén de imágenes
Nginx Proxy	50-100 MB	Reverse proxy
Total (idle)	1,5-2,5 GB	Los tres juntos

Sobre equipos como el Intel Core Ultra 5 226V (NPU de 40 TOPS) o el AMD Ryzen AI 9 HX 370 (NPU de 50 TOPS), el host de Docker se mueve en esos números. Y acá el detalle que la nota original pasa medio de largo: ese NPU no se usa para nada de esto. Docker tira de CPU, RAM y disco. Los 40 o 50 TOPS de “inteligencia” del chip quedan de adorno mientras servís repos. Si comprás una AI PC pensando que el NPU va a acelerar tus contenedores, te vas a llevar una sorpresa.

¿Nginx Proxy Manager o Traefik? Diferencias reales

La pregunta que aparece siempre. Los dos son reverse proxy, los dos manejan SSL, y los dos hacen el laburo. La diferencia está en cómo los configurás y cuánto querés meter mano. En optimizar contenido para múltiples idiomas profundizamos sobre esto.

Aspecto	Nginx Proxy Manager	Traefik
Configuración	Interfaz web (clicks)	Archivos YAML / labels
Curva de aprendizaje	Suave	Empinada al principio
Auto-descubrimiento	Manual	Automático por labels de Docker
Mejor para	Empezar rápido, poca config	Setups dinámicos, muchos servicios

Si recién arrancás y querés ver algo funcionando en 10 minutos, Nginx Proxy Manager. Si vas a levantar y bajar servicios seguido y te copa que el proxy se entere solo, Traefik. Yo, para un lab de tres servicios, iría por Nginx Proxy Manager y me ahorraría el YAML. Para algo que escala, Traefik paga la curva.

Errores comunes (y cómo evitarlos)

• Olvidarte los volúmenes: si no montás un volumen persistente, al hacer docker compose down perdés todos los repos. Definí siempre el volumen antes de subir código real.
• Certificados autofirmados sin avisar al cliente: Git te va a tirar error de SSL. O importás el certificado, o configurás el cliente para confiar en él. No lo desactives en producción.
• Puertos bloqueados por el firewall de Windows: Docker expone el puerto pero Windows lo tapa. Si no accedés desde otra máquina de la red, revisá las reglas de entrada antes de volverte loco con el DNS.
• DNS local mal resuelto: si usás nombres tipo gitea.local, tenés que agregarlos al archivo hosts o el navegador no sabe adónde ir.

¿Qué está confirmado y qué no?

• Confirmado: el consumo de RAM (1,5-2,5 GB idle) sale de mediciones publicadas el 2 de julio de 2026 sobre hardware Copilot+ real.
• Confirmado: el stack de tres contenedores se levanta con Docker Compose y un solo comando.
• Sin verificar de forma independiente: la estabilidad exacta “24/7 durante meses” en una laptop. La nota original la afirma, pero no muestra un test de larga duración.
• Sin datos: temperatura precisa bajo carga sostenida. El artículo la menciona como preocupación, sin números concretos.

¿Es viable correr esto 24/7 en una AI PC Copilot+?

Para un entorno de desarrollo, sí. Una AI PC moderna con 16 GB o más aguanta los tres contenedores sin despeinarse, y te queda RAM de sobra para el navegador y el editor. El tema es la palabra “producción”.

Una laptop encendida todo el día se calienta, la batería sufre y cualquier reinicio de Windows te tira los servicios abajo. Si estos servicios los usa un equipo y no podés permitirte que se caigan, la respuesta ya no es tu máquina. Ahí conviene un servidor dedicado o un VPS con hosting que garantice uptime, donde el stack de Docker corre sin depender de que no cierres la tapa de la notebook. Monitoreá el consumo con docker stats y, si ves que la RAM se dispara, es la señal para mudar.

Preguntas Frecuentes

¿Cómo self-hosteo Gitea y un Docker registry en mi máquina?

Definís ambos servicios en un archivo docker-compose.yml con sus imágenes oficiales y volúmenes persistentes, y los levantás con docker compose up -d. Gitea queda como servidor Git y el registry como almacén de imágenes, cada uno en su contenedor.

¿Cuánta RAM necesito para tres servicios en Docker?

Entre 1,5 y 2,5 GB en reposo para Gitea, Registry y un reverse proxy, sin contar lo que consume Docker Desktop y WSL2 en Windows. Con 16 GB de RAM total vas sobrado; con 8 GB vas a estar justo. Relacionado: ejecutar agentes sin depender de APIs.

¿El NPU de una AI PC acelera los contenedores Docker?

No. El NPU (40-50 TOPS) está pensado para tareas de inferencia de IA, no para servir repos ni enrutar tráfico. Docker se apoya en CPU, RAM y disco, así que el NPU queda sin uso mientras corren estos servicios.

¿Cuál es la diferencia entre Nginx Proxy Manager y Traefik?

Nginx Proxy Manager se configura por una interfaz web con clicks, ideal para empezar rápido. Traefik se configura por archivos YAML y labels de Docker, con auto-descubrimiento de servicios, mejor para setups dinámicos con muchos contenedores.

¿Es seguro exponer estos servicios a internet?

Solo con SSL bien configurado, autenticación fuerte y el firewall filtrando puertos. Para uso local no hace falta abrir nada hacia afuera. Si necesitás acceso remoto, una VPN es más segura que exponer los puertos directo a internet.

Conclusión

Montar tu propio Gitea, registry y reverse proxy con Docker dejó de ser un proyecto de fin de semana para volverse algo que armás en una tarde, con un consumo de RAM medido y predecible. Los números de julio 2026 lo confirman: 1,5 a 2,5 GB en reposo, tres contenedores, un comando.

Lo que no cambió es la vieja regla: una laptop es un lab, no un servidor. Usá el self-hosting para desarrollar con control y privacidad, elegí Nginx Proxy Manager si querés simpleza o Traefik si querés automatización, y el día que esto lo use un equipo de verdad, mudalo a infraestructura pensada para estar prendida. Y no compres una AI PC por el NPU si tu plan es servir contenedores: para eso, el chip ni se despeina.

Fuentes

• dev.to – Self-host de servicios dev con Docker y reverse proxy en AI PC Copilot+ (mediciones de RAM, 2 jul 2026)
• Docker Compose – Documentación oficial
• Gitea – Documentación oficial del servidor Git
• Nginx Proxy Manager – Sitio oficial
• Traefik – Reverse proxy y load balancer