Pampling utiliza una infraestructura centralizada basada en un servidor local Ubuntu, donde se ejecutan contenedores Docker gestionados por Coolify. Todas las aplicaciones comparten la misma infraestructura base, aunque cada equipo puede elegir el stack tecnológico que mejor se adapte a su proyecto.
¿Vas a diseñar algo nuevo? Antes de seguir, lee Capacidad y límites de la infraestructura: ahí está lo que el servidor puede y no puede sostener.
Todos los proyectos de Pampling usan estos componentes. No son negociables:
| Componente | Tecnología | Descripción |
|---|---|---|
| Servidor | Ubuntu 24.04 LTS (192.168.1.10) | Servidor físico en red local, 40 cores / 219 GB RAM |
| Deploy | Coolify vía API REST | Gestión y despliegue de contenedores Docker |
| Base de datos | PostgreSQL (u otro motor) | Un contenedor independiente por aplicación, no compartido |
| Build system | Nixpacks o Dockerfile | Ambos son válidos y están en uso — ver nota abajo |
| Repositorio | Bitbucket (workspace pampling) |
Control de versiones, deploy keys |
| Herramienta IA | Claude Code (Anthropic) | Desarrollo asistido por IA |
| Parámetro | Valor |
|---|---|
| Host | 192.168.1.10 (uso interno, scripts y SSH) |
| Sistema | Ubuntu 24.04 LTS |
| Panel Coolify | https://coolify.pampl.ing |
| API Coolify | https://coolify.pampl.ing/api/v1 |
Usa siempre el dominio (
coolify.pampl.ing), nunca la IP ni el puerto directo. El dominio es estable ante cambios de infraestructura y funciona igual desde dentro y fuera de la oficina; la IP:puerto no.
Nixpacks detecta automáticamente el lenguaje de un proyecto y construye la imagen sin necesidad de un Dockerfile. Es cómodo para empezar rápido, pero no es el único camino válido: hoy más de la mitad de nuestras aplicaciones usan Dockerfile propio, típicamente porque necesitan más control sobre el proceso de build o dependencias del sistema que Nixpacks no resuelve bien.
Usa Nixpacks si tu proyecto es sencillo y sigue las convenciones estándar de su lenguaje. Usa Dockerfile si necesitas control fino sobre la imagen.
Cada aplicación que necesita persistencia tiene su propio contenedor de base de datos, creado y gestionado desde Coolify. No se comparte una única instancia de PostgreSQL entre aplicaciones.
Esto es importante para el sistema de backups: las bases de datos se detectan automáticamente por una etiqueta (coolify.type=database) que Coolify asigna a estos contenedores, así que cualquier base de datos creada desde la interfaz de Coolify queda respaldada sin configuración adicional.
| Servicio | Acceso | URL |
|---|---|---|
| Coolify (admin) | Público, autenticado | https://coolify.pampl.ing |
| Wiki.js (docs) | Público | https://wiki.pampl.ing |
| Apps desplegadas | Público (subdominio) | https://nombre.pampl.ing |
Los subdominios de
pampl.ingson la única vía de acceso externo — solo los puertos 80 y 443 están abiertos al exterior. Coolify gestiona los certificados SSL automáticamente vía Let's Encrypt.
Esta es la combinación de tecnologías que recomendamos para proyectos nuevos. La mayoría de aplicaciones existentes usan este stack, por lo que hay más ejemplos, documentación y soporte interno.
| Capa | Tecnología recomendada | Alternativas válidas |
|---|---|---|
| Backend | Python 3.12 + FastAPI + Uvicorn | Node.js, Go, o cualquier lenguaje que Nixpacks/Docker soporten |
| Frontend | HTML/CSS/JS vanilla + ApexCharts | React, Vue, Svelte — cualquier framework JS |
| Estilos | Design system Pampling (ver Guía de Estética) | Tailwind, Bootstrap — respetando la paleta de colores |
No es obligatorio usar Python/FastAPI. Si un proyecto tiene requisitos que encajan mejor con otra tecnología, úsala. Lo importante es que se despliegue en Coolify y siga las convenciones de infraestructura.
Para proyectos Python/FastAPI:
proyecto/
├── backend/
│ ├── main.py # App FastAPI, rutas, static files
│ │ # incluye endpoint /api/health (ver checklist)
│ ├── database.py # Conexión PostgreSQL
│ └── routers/ # Endpoints agrupados por dominio
├── frontend/
│ ├── css/
│ ├── js/
│ └── *.html
├── requirements.txt # Dependencias (en la raíz para Nixpacks)
├── Procfile # web: uvicorn backend.main:app --host 0.0.0.0 --port 8000
├── CLAUDE.md # Info del proyecto (compartido, ver checklist)
└── CLAUDE.local.md # Credenciales locales (gitignored)
Importante: el fichero de dependencias (
requirements.txt,package.json, etc.) debe estar en la raíz del proyecto. Nixpacks lo busca ahí para detectar el lenguaje y resolver las dependencias.
Para otros stacks, adaptar la estructura manteniendo:
Procfile con el comando de arranqueCLAUDE.md del proyecto (ver Checklist de CLAUDE.md)Usa la Checklist: aplicación nueva — resume, en formato accionable, los puntos que ya han causado incidentes reales (healthcheck, ubicación de datos, secretos, backups).