El HTTPS del panel de ZimaOS no protege automáticamente todas las aplicaciones de Docker. Las aplicaciones que escuchan en sus propios puertos necesitan HTTPS nativo o un proxy inverso. La URL aleatoria de un repositorio de GitHub tampoco es una fuente válida para la tienda de aplicaciones de ZimaOS: el repositorio debe seguir el protocolo actual de la tienda.
El hilo de origen de abril de 2026 combinaba estas dos preguntas de principiantes. La respuesta clara es separarlas: proxy inverso para el TLS de las aplicaciones, y una tienda compatible o Compose personalizado para el software que falta.
Por qué el HTTPS del panel no protege las aplicaciones
La configuración HTTPS de ZimaOS protege el nombre de host del panel. Una aplicación de Docker en http://SERVER:8080 sigue siendo un servicio independiente. La guía sobre el proxy inverso HTTPS explica esta diferencia.
Usa un proxy inverso para el HTTPS de las aplicaciones
https://app.example.com
↓
Proxy inverso / TLS
↓
http://app-container:portNginx Proxy Manager o Caddy pueden terminar el TLS y reenviar las solicitudes a una aplicación.
El HTTPS local y el HTTPS público son diferentes
Para uso exclusivo en la LAN, pueden funcionar el DNS interno y una CA local. Los dominios públicos necesitan certificados válidos y reglas deliberadas de acceso remoto y seguridad.
Por qué una URL sin más de GitHub produce un error
La tienda de aplicaciones espera un formato de tienda compatible, no código fuente arbitrario de una aplicación.
Protocolo actual de la tienda de aplicaciones de ZimaOS
La guía para desarrolladores de la tienda de aplicaciones de ZimaOS actual define una tienda v2 con store-config.json, supported-languages.json, un árbol Apps/ y un resultado dist/ generado.
Para una sola aplicación, usa Compose personalizado
Si solo necesitas un proyecto, no hace falta crear una tienda completa. Importa o crea un archivo Docker Compose con los puertos, volúmenes y metadatos x-casaos correctos. La referencia actual sobre Docker Compose y x-casaos documenta el formato.
Presta atención a los puertos 80 y 443
Los proxies inversos suelen necesitar los puertos 80/443, que quizá ya estén siendo utilizados por ZimaOS. Comprueba quién los está utilizando antes de desplegar.
Elige el nombre del proxy inverso antes de configurar el TLS
Decide si los usuarios abrirán app.home.arpa, un dominio privado o un dominio público. Los certificados validan nombres, por lo que configurar el TLS antes de decidir los nombres DNS suele provocar advertencias y entradas de proxy duplicadas.
No pongas detrás de un proxy una aplicación a la que no puedas acceder directamente
Antes de añadir un host de proxy, abre la aplicación backend en su dirección HTTP normal. Si http://SERVER:PORT ya no funciona, añadir HTTPS solo ocultará el problema original detrás de un error del proxy.
Usa un paquete para una sola aplicación antes de crear una tienda completa
Una tienda de terceros resulta útil cuando mantienes muchas aplicaciones para instalarlas repetidamente. Para una sola aplicación que falta, Compose personalizado es más sencillo de probar, actualizar y auditar. Crea un repositorio únicamente cuando necesites distribuir un catálogo, metadatos, recursos y actualizaciones repetibles.
Valida Compose antes de publicar
La documentación actual para desarrolladores de ZimaOS espera un Docker Compose válido junto con los metadatos x-casaos de nivel superior. Prueba primero la pila de Compose y después añade los metadatos del catálogo; no depures al mismo tiempo el tiempo de ejecución de los contenedores y el empaquetado de la tienda.
Mantén privada la interfaz de administración del proxy
Si implementas Nginx Proxy Manager u otro proxy inverso, la interfaz de administración debe permanecer en la LAN o en una VPN privada. El tráfico público solo debe llegar a los puertos HTTP/HTTPS previstos del proxy, no al puerto de administración.
Del mismo modo, no expongas una aplicación privada simplemente porque ahora tienes un certificado válido. El TLS protege el transporte; no sustituye la autenticación ni el control de acceso de red.
Preguntas frecuentes
¿El HTTPS de ZimaOS cubre todas las aplicaciones?
No. Cada endpoint de aplicación necesita su propio HTTPS o un proxy inverso.
¿Puedo añadir cualquier repositorio de GitHub a la tienda de aplicaciones?
No. Debe ser una tienda compatible o una aplicación empaquetada como Compose.
¿Necesito un dominio público para el HTTPS local?
No. El DNS interno y los certificados locales de confianza pueden funcionar.
¿Cuál es la forma más sencilla de instalar una aplicación que falta?
Usa una aplicación Docker Compose personalizada actual.
