Requisitos mínimos de infraestructura
Estos son los requisitos mínimos de infraestructura para instalar la aplicación y su costo mensual estimado.
| Componente | Requisito mínimo | Costo mensual estimado |
|---|---|---|
| Servidor | Linux x86_64 con acceso de administrador: 2 vCPU, 4 GB de RAM y 80 GB de disco SSD | $24 Referencia: Hostinger, sin impuestos |
| Base de datos | MongoDB Atlas en nivel gratuito (M0): 512 MB | $0 |
| Dominio | Un nombre público y acceso a su DNS | Sin costo adicional si ya lo tiene |
| Total | Servidor y base de datos | ≈ $24 |
Cómo nos repartimos el trabajo
WT monta la infraestructura y mantiene la aplicación; del lado del cliente hacen falta el dominio y, si desea la integración, el token de Monday.com.
| Tema | Cliente | WT |
|---|---|---|
| Servidor | Sin tareas de su lado | Montarlo: instalar Docker, nginx y certbot, y dejar listos los usuarios, los permisos y el HTTPS |
| Dominio | Elegir el nombre público y crear el registro DNS que WT indique | Indicar el nombre exacto y comprobar que resuelve al servidor |
| MongoDB | Sin tareas de su lado | Crear el clúster, la base y el usuario de la aplicación, y conectarlos al repositorio |
| Repositorio y despliegue | No necesita cuenta de GitHub | Mantener el repositorio, el workflow y la imagen, y apuntar el despliegue al servidor |
| Monday.com Opcional | Compartir el token de API de la cuenta que se integre | Guardarlo cifrado como secret de la aplicación |
Requisitos del servidor
El servidor necesita Linux x86_64 con Docker, nginx y certbot.
| Elemento | Requisito |
|---|---|
| Sistema operativo | Linux x86_64 (amd64) con systemd y bash; recomendamos Ubuntu o Debian LTS |
| Software | Docker con el plugin Compose v2, nginx, certbot, jq, openssl, flock y sudo |
| Recursos mínimos | 2 vCPU, 4 GB de RAM y 80 GB de disco SSD |
| Límite del contenedor | 0,5 CPU y 512 MB de RAM por aplicación (configurable) |
| Acceso | Un usuario con permisos de administrador (sudo o root) para la instalación |
Los recursos son orientativos; WT los ajusta según la carga prevista.
Qué crea la instalación en el servidor
- Los usuarios
deployyprovisioner, sin contraseña utilizable. - Las carpetas
/opt/platform(scripts),/srv/customer-apps(una carpeta por aplicación),/etc/nginx/platform-appsy/var/www/certbot. - Un archivo de permisos sudoers limitado a los scripts de WT y un hook que recarga nginx al renovar certificados.
- Una única línea
includeen la configuración de nginx.
No modifica la configuración de Docker, el firewall, sshd, las actualizaciones automáticas ni los sitios, contenedores o certificados que ya existan.
Red y DNS
Solo hace falta un registro DNS hacia el servidor; WT configura el resto de la red: el servidor recibe conexiones por los puertos 80, 443 y 22 y sale a GitHub, Let's Encrypt y su MongoDB.
Registro DNS
WT acuerda con usted el nombre exacto. Si prevé varias aplicaciones, puede crear un registro comodín (*.apps.su-dominio.com) en lugar de uno por aplicación.
Puertos de entrada
| Puerto | Uso |
|---|---|
| 443 | HTTPS de la aplicación |
| 80 | Redirección a HTTPS y validación de certificados de Let's Encrypt |
| 22 | SSH para desplegar. Las ejecuciones de GitHub Actions no tienen IP fija; si desea restringir por IP, se pueden usar runners propios, que WT puede configurar |
El puerto interno de la aplicación (rango 20000 a 29999) escucha solo dentro del servidor y permanece cerrado.
Salidas a internet
| Destino | Uso |
|---|---|
ghcr.io y pkg-containers.githubusercontent.com | Descarga de la imagen de la aplicación |
acme-v02.api.letsencrypt.org | Emisión y renovación de certificados |
| Host de su MongoDB (normalmente puerto 27017) | Conexión de la aplicación a su base |
api.monday.com | Integración con Monday.com Opcional |
MongoDB del cliente
La aplicación usa una base MongoDB propia en MongoDB Atlas; el nivel gratuito es suficiente.
- Replica set. Es un replica set, como todos los clústeres de Atlas, porque la aplicación usa transacciones. WT confirma la versión mínima compatible; las pruebas de WT usan MongoDB 8.
- Una base para la aplicación. Se llama
client_<proyecto>(minúsculas, números y guion bajo). - Un usuario con permisos mínimos.
app_<proyecto>, con el rolreadWritesolo sobre esa base. No tiene permisos administrativos. - Colecciones e índices. La aplicación los crea sola al arrancar, con sus migraciones.
- Acceso de red. La lista de acceso incluirá la IP pública del servidor, con conexión TLS.
- Qué se guarda. Usuarios, roles, permisos, notificaciones, auditoría y sesiones de la aplicación, más los datos propios de lo que se construya sobre ella.
WT carga la cadena de conexión en los secretos del repositorio, sin que usted tenga que compartirla. El nivel gratuito de Atlas no incluye respaldos; si los necesita, se acuerdan con WT.
Seguridad y datos
La aplicación queda aislada en su servidor y sus datos permanecen en su MongoDB.
- Contenedor. Se ejecuta sin privilegios de administrador, con sistema de archivos de solo lectura, sin capacidades adicionales y con límites de CPU y memoria. Solo escucha dentro del servidor; nginx es la única entrada HTTPS.
- SSH. La clave de despliegue es propia de la aplicación, tiene un comando forzado y no abre una terminal. La huella del servidor queda fijada en el repositorio.
- Imagen. Se despliega por huella de contenido (digest). El token temporal de descarga no se conserva en el servidor.
- Secretos. La cadena de conexión a su MongoDB se guarda como secret del repositorio, que no se puede leer después de guardarlo, y viaja cifrada por SSH al servidor en cada despliegue. En el servidor queda en un
.envcon permisos0600y nunca se imprime. - Acceso a los datos. El usuario de MongoDB solo puede leer y escribir en la base de esta aplicación.
Dónde vive cada dato
| Dato | Dónde vive |
|---|---|
| Código, ramas y Pull Requests | Repositorio del proyecto, en la cuenta de GitHub de WT |
| Imagen de la aplicación | Registro de contenedores de GitHub |
| Secretos de despliegue y cadena de conexión | Secrets del repositorio |
| Configuración, .env, logs y estado del despliegue | Su servidor, en /srv/customer-apps/<proyecto> |
| Datos de la aplicación | Su MongoDB |
Pasos de instalación
La instalación tiene seis pasos: los dos primeros son del cliente, los tres siguientes de WT y el último de ambos.
- Cliente
Crear las cuentas del servidor y de MongoDB Atlas, y dar acceso a WT.
- Cliente
Elegir el nombre público de la aplicación y crear el registro DNS que WT indique.
- WT
Monta el servidor y el clúster de MongoDB, con su base y su usuario.
- WT
Conecta el repositorio con el servidor y la base de datos, y publica la aplicación con HTTPS.
- WT
Lanza el primer despliegue y comprueba que la aplicación responde.
- Ambos
Validan el acceso, cambian la contraseña inicial del administrador de la aplicación y acuerdan cómo se dará el soporte.
Información que WT necesitará
WT necesita estos datos para montar y conectar la infraestructura; los accesos se comparten por un canal seguro.
- Cuentas del servidor y de MongoDB Atlas, con acceso para WT.
- Nombre público de la aplicación (
<proyecto>.<dominio-base>) y quién administra el DNS del dominio. - Correo para los avisos de certificados de Let's Encrypt.
- Política de respaldos y retención que desean.
- Token de API de Monday.com. Opcional
- Contacto técnico y contacto de seguridad.
Límites y puntos por confirmar
El repositorio de GitHub y la imagen de la aplicación permanecen en la cuenta de WT, que también mantiene y actualiza la herramienta de despliegue; la aplicación queda fijada a la versión de la plantilla con la que se creó.
Puntos que conviene acordar antes de empezar
- Vista previa de cambios del AI Developer. Hoy depende del servidor de WT. WT confirmará cómo se revisarán los cambios antes de desplegarlos a su servidor.
- Si su política exige restringir el puerto 22 por IP, usar runners propios de GitHub Actions.
- Política de respaldos y retención del servidor y de MongoDB.
- Versión de MongoDB y tamaño del servidor según la carga prevista.