Esta página responde a una pregunta concreta: ¿esto que quiero construir encaja en nuestro servidor?
Está pensada para consultarla antes de diseñar una solución, no después de que falle. Si vas a crear una aplicación, elegir dónde guardar datos, o decidir una arquitectura, empieza por aquí.
Datos verificados el 12/08/2026. La infraestructura cambia: si un dato parece no cuadrar con la realidad, avisa a sistemas.
| Recurso | Cantidad | Comentario |
|---|---|---|
| CPU | 40 cores | Rara vez es el cuello de botella |
| RAM | 219 GB (~200 GB libres habitualmente) | Muy holgada. No suele ser una limitación real |
| Swap | 8 GB | Prácticamente sin usar |
Implicación práctica: puedes asumir que hay recursos de cómputo de sobra. Si tu aplicación necesita 2 GB de RAM, no es un problema. Si necesita 40 GB, habla con sistemas antes.
| Volumen | Capacidad | Uso actual | Para qué |
|---|---|---|---|
Sistema (/) |
1.1 TB | ~9% | SO, Coolify, configuración |
RAID 5 (/data-raid) |
1.67 TB útiles | ~16% | Docker, containerd, datos de apps |
Backups (/backups) |
558 GB | variable | Copias de seguridad |
/data-social |
549 GB | ~1% | Contenido de la app partners |
| Discos libres | 558 + 223 + 223 GB | — | Ampliación futura |
El RAID 5 está formado por 4 discos activos más un disco de reserva en caliente (hot spare). Tolera el fallo de un disco sin pérdida de datos y se reconstruye solo. Ahí viven Docker, containerd y los datos persistentes de las aplicaciones.
Implicación práctica: hay espacio de sobra para casos normales. Si tu aplicación va a manejar cientos de GB (vídeo, imágenes, datasets), habla con sistemas: probablemente se te asigne un disco dedicado, como se hizo con partners.
| Elemento | Valor |
|---|---|
| IP local | 192.168.1.10 |
| IP pública | 194.224.94.34 |
| Dominio | pampl.ing (wildcard *.pampl.ing) |
| Puertos abiertos al exterior | Solo 80 y 443 |
Implicación práctica: tu aplicación se expone como https://tu-app.pampl.ing a través del proxy. No puedes abrir puertos arbitrarios al exterior. Si necesitas un protocolo que no sea HTTP/HTTPS, habla con sistemas antes de diseñarlo.
Esta es la decisión que más se equivoca, y tiene consecuencias reales en el sistema de backups.
| Tipo de dato | Dónde va | ¿Entra en backup? |
|---|---|---|
| Base de datos (PostgreSQL, MySQL, Redis…) | Contenedor gestionado por Coolify | ✅ Sí, automático |
| Datos propios irreproducibles de la app (índices, ficheros generados por usuarios, configuración) | /data-raid/apps/<app>/ |
✅ Sí, diario |
| Datos voluminosos o reproducibles (cachés, miniaturas, medios descargados, modelos de IA) | Fuera de /data-raid/apps — pide ruta a sistemas |
❌ No |
| Ficheros que viven en otro servidor de la red | Montaje CIFS en /mnt/… |
❌ No (ya están en su origen) |
| Ficheros temporales | Dentro del contenedor | ❌ No |
Todo lo que se guarda en
/data-raid/apps/se copia íntegro cada noche, comprimido, con 15 días de retención.
Consecuencia: si metes ahí 4 GB de imágenes que se pueden regenerar, estás generando ~60 GB de backups inútiles que compiten por espacio con las copias de las bases de datos, que sí son irremplazables.
El criterio es simple: si el dato se puede volver a generar o descargar, no debe entrar en el backup.
Ejemplos reales de nuestro parque:
capturas.db de camaras-web → en /data-raid/apps, correcto: es la única copiathumbnails/ de la misma app → reproducibles desde las fotos originales, deberían estar fuerapartners → en /data-social (disco propio, fuera de backup): es re-descargableLos datos que deben sobrevivir a un redespliegue se configuran en Coolify → Storages → Directory Mount, no dentro del contenedor.
⚠️ Todo lo que escribas dentro del contenedor, fuera de un volumen, se pierde en el siguiente deploy. Es la causa más común de "he perdido los datos".
Son reales y están medidas. Ignorarlas es la causa de la mayoría de nuestros incidentes.
No hay redundancia de servidor ni failover. Si el servidor cae, caen las 91 aplicaciones.
El RAID protege contra el fallo de un disco, no contra el fallo del servidor, un corte de luz prolongado o un problema de red.
Qué implica: ninguna aplicación debe prometer un nivel de servicio que la infraestructura no puede sostener. Si un proceso es crítico para el negocio y no puede parar, hay que hablarlo antes de construirlo aquí.
Estado real: de 91 aplicaciones, solo 1 tiene límite de CPU y ninguna tiene límite de memoria.
Eso significa que una aplicación con una fuga de memoria o un proceso descontrolado puede consumir toda la RAM del servidor y provocar que el kernel empiece a matar procesos de forma impredecible — incluidos los de otras aplicaciones o el propio Coolify.
Hoy funciona porque hay mucho margen (219 GB), pero es una bomba de relojería.
Qué implica: si prevés que tu aplicación va a consumir bastante (procesamiento de imágenes, modelos de IA, builds pesados), dilo. Se le pone un techo y así un descontrol solo afecta a tu app, no al servidor.
Estado real: 10 de 91 aplicaciones tienen healthcheck configurado. 59 están en estado running:unknown.
Sin healthcheck, Coolify solo sabe que el contenedor existe, no que la aplicación funcione. Las consecuencias son graves:
Esto causó una caída de producción de 53 minutos el 12/08/2026.
Qué implica: toda aplicación nueva debe llevar un endpoint /api/health y tenerlo activado en Coolify. Ver Checklist de aplicación nueva.
Cuando un contenedor se elimina (en cada despliegue, o al limpiar), sus logs se borran con él. Y la API de Coolify sigue sin permitir leer los logs de una aplicación que no esté corriendo: devuelve 400 Application is not running. Eso no ha cambiado y no depende de nosotros.
Es exactamente al revés de lo que se necesita: los logs hacen falta sobre todo cuando la aplicación está caída. Fue la causa por la que la caída del 12/08/2026 (ver §3.3) tardó ~50 minutos en diagnosticarse.
Qué implica: no diseñes tu diagnóstico asumiendo que podrás leer los logs de un contenedor caído vía la API de Coolify — eso sigue sin funcionar. Ahora bien, existe un servicio en el servidor, docker-log-archiver, que captura logs y metadatos de cualquier contenedor en el instante en que muere, antes de que Docker lo destruya, con 30 días de retención. Ver Archivador de logs de contenedores para consultarlo. Si necesitas los logs de un contenedor que ya no existe, ese archivo es la vía, no la API.
Los backups se guardan en un disco del mismo servidor (/backups, en un disco independiente del RAID a propósito).
Eso protege contra:
Pero no protege contra:
Es una decisión consciente, no un olvido. Si tu aplicación maneja datos cuya pérdida sería inaceptable, plantéalo.
Cada noche se genera una copia completa. No hay deduplicación ni copias diferenciales. El coste en disco y en tiempo crece de forma lineal con el volumen de datos.
Qué implica: el volumen de datos que pongas en el scope de backup se multiplica por 15 (los días de retención). Ver §2.
Los dominios *.pampl.ing se resuelven a la IP interna (192.168.1.10) mediante un servidor DNS local (dnsmasq), porque el firewall corporativo no soporta hairpin NAT: un equipo de la oficina no puede alcanzar la IP pública del propio firewall.
Esto se rompe con facilidad:
192.168.1.10 como DNSSíntoma típico: "no puedo entrar a la aplicación, pero en modo incógnito sí funciona" o "a mí me funciona y a mi compañero no".
Qué implica: si tu aplicación la van a usar personas de la oficina, ten en cuenta que este problema existe y no es culpa de tu app. Ver la página de red y DNS para el diagnóstico.
Traefik (el proxy que da acceso a todas las aplicaciones) tiene varios ajustes manuales necesarios: HTTP/3 desactivado, cabecera Alt-Svc: clear, validación de certificados por TLS challenge, métricas de Prometheus.
Coolify regenera la configuración de Traefik cuando se auto-actualiza y revierte todos esos ajustes. Ha pasado varias veces y siempre provoca los mismos síntomas (fallos de certificado, timeouts en Chrome).
Qué implica: ninguna aplicación debe depender de un ajuste manual del proxy. Si necesitas algo especial de Traefik, habla con sistemas: hay que documentarlo para reaplicarlo tras cada actualización de Coolify.
El servidor usa una controladora RAID de hardware (Dell MegaRAID) y los nombres de dispositivo (/dev/sdX) no son estables: pueden cambiar en cada arranque.
Verificado empíricamente: un disco que era /dev/sdh pasó a ser /dev/sdi tras un reinicio.
Qué implica: nada debe referenciar un disco por su letra. Siempre por UUID o por etiqueta. Si un script o una monitorización usa /dev/sdh, tras un reinicio podría estar apuntando a otro disco completamente distinto. En el peor caso, escribiendo donde no debe.
Dentro de un team de Coolify, quien tiene acceso lo tiene a todo: puede ver, modificar y borrar cualquier aplicación o base de datos de ese team, incluidas las de otros compañeros.
No hay permisos por aplicación ni por proyecto.
Qué implica: ten cuidado con las operaciones destructivas. Antes de un borrado o de parar una aplicación, verifica que es la tuya.
En el corte de luz del 10/04/2026 el SAI no aguantó y el servidor se apagó de golpe. Al volver la corriente, arrancó automáticamente pero varios servicios no se recuperaron solos.
Qué implica: un corte de luz en la oficina puede tumbar el servicio. No es un escenario hipotético, ya ocurrió.
La API de Coolify devuelve, en el log de cada despliegue, la clave SSH privada con la que Coolify accede al servidor como root, en base64 y en claro. No es un fallo nuestro, es comportamiento de Coolify. Ver Aviso de seguridad: logs de deployment de Coolify antes de compartir un log de deploy con nadie fuera del equipo de sistemas.
Qué implica: nunca pegues un log de deployment completo en un ticket, chat o captura, y no pidas el permiso read:sensitive para un token de desarrollo pensando que así "verás mejor" los logs — es justo lo que hoy evita que esa clave circule.
Con el token de desarrollo y el acceso a Coolify:
*.pampl.ingEscribe a jose.moya@pampling.com para:
| Necesidad | Por qué requiere sistemas |
|---|---|
| Disco dedicado o volumen grande | Hay que formatear, montar y decidir si entra en backup |
| Montar un recurso de red (share SMB de otro servidor) | Requiere credenciales y configuración en el host |
| Límites de CPU/RAM para tu aplicación | Configuración a nivel de infraestructura |
| Abrir un puerto que no sea 80/443 | Firewall y router corporativo |
| Cambios en el proxy (Traefik), certificados o SSL | Configuración compartida por todas las apps |
| Acceso temporal a una base de datos desde fuera | Apertura controlada de puerto |
| Logs de una aplicación caída | Consulta el archivador de logs primero; si no basta, requiere acceso al servidor |
| Un usuario nuevo en Coolify | Gestión de accesos |
| Sacar datos del scope de backup | Configuración del sistema de copias |
| Dudas de capacidad ("¿aguanta el servidor esto?") | Mejor preguntar antes que descubrirlo en producción |
Criterio general: si afecta a algo que comparten todas las aplicaciones (proxy, red, discos, backups, recursos), pasa por sistemas. Si afecta solo a tu aplicación, adelante.
Preguntas rápidas para validar si una idea encaja:
¿Cuánto va a consumir?
Si es mucho (>4 GB RAM sostenidos, procesamiento continuo de CPU), avisa para ponerle límites.
¿Cuántos datos va a guardar y de qué tipo?
Distingue entre irreproducible (va a backup) y regenerable (fuera). Si son cientos de GB, hará falta disco dedicado.
¿Necesita algo que no sea HTTP/HTTPS?
Solo están abiertos los puertos 80 y 443. Cualquier otro protocolo hay que hablarlo.
¿Puede tolerar que el servidor caiga?
No hay alta disponibilidad. Si el proceso no puede parar nunca, esta infraestructura no es suficiente por sí sola.
¿Accede a bases de datos externas u Odoo?
Debe hacerlo a través del proxy globaldb, nunca con conexión directa.
¿Tiene endpoint de salud?
Obligatorio para que un despliegue roto no tumbe el servicio.
¿Tolera que un recurso de red falle?
Si lees de un montaje CIFS, las lecturas pueden devolver error si el servidor de origen cae. La app debe gestionarlo sin romperse.