Memoria del servidor
Disco del servidor
Procesos en vivo (PM2)
| Proceso | Estado | Memoria | CPU | Reinicios | Activo desde |
|---|
Herramientas y plataformas del ecosistema
Principio de diseño
Todos los proyectos comparten los mismos cimientos (sistema, conexiones, seguridad, despliegue) pero cada uno es distinto en su negocio. Un cambio en la forma de autenticar o guardar datos se aplica igual en todos; la lógica propia de cada rubro vive solo en su proyecto.
Los archivos base (conexión a base de datos, autenticación, cliente de API) no se editan por proyecto. Si algo hay que mejorar ahí, se mejora en la plantilla wnexio-base y se propaga a todos.
Stack estándar
| Runtime | Node.js + Express |
| Base de datos | PostgreSQL (una base por proyecto) — o SQLite en herramientas personales de bajo tráfico |
| Conexión | Pool de conexiones en src/db.js |
| Autenticación | JWT (sesión) + bcrypt (contraseñas) |
| Seguridad | helmet + rate limiting + CORS |
| Frontend | HTML/JS plano + cliente común js/api.js, sin framework ni build step |
| Configuración | Archivo .env por proyecto |
| Despliegue | FileBrowser/SFTP + PM2 + Nginx (Hetzner) — sin CI/CD |
| Proceso | Un usuario del sistema operativo por proyecto (no root) — PM2 corre bajo ese usuario |
| Acceso al servidor | SSH solo por llave — login por contraseña desactivado |
| Red | Firewall del servidor: solo 22 (SSH), 80 y 443 (web) abiertos al público |
| DNS/CDN | Cloudflare — un registro explícito por subdominio (sin comodín) |
Seguridad reforzada (actualizado 31-ago-2026)
Tras un incidente de seguridad en el servidor original (un rootkit instalado explotando login SSH por contraseña abierto a internet), el servidor nuevo se construyó desde cero con estas protecciones de fábrica:
| Un usuario por proyecto | Cada app corre aislada — si una se compromete, no puede tocar el código ni los datos de las demás |
| Sin login por contraseña | Solo se entra con llave SSH — elimina los ataques de fuerza bruta (el servidor viejo recibió 17,000+ intentos en 3 semanas) |
| Firewall de red | Ningún puerto de aplicación (3000-3070) queda expuesto directo a internet, solo Nginx |
| Actualizaciones automáticas | Parches de seguridad del sistema operativo se instalan solos |
| DNS explícito | Sin comodín — un subdominio que no se creó a propósito, no responde nada |
Hetzner genera automáticamente un archivo (/etc/ssh/sshd_config.d/50-cloud-init.conf) con PasswordAuthentication yes al crear cualquier servidor nuevo — y ese archivo se carga antes que la configuración propia, ganándole la prioridad en silencio. El login por contraseña seguía activo pese a que la configuración principal decía lo contrario. Se corrigió y se verificó con una prueba real (forzar solo contraseña, confirmar que se rechaza). Revisar este archivo específico en cualquier servidor nuevo de Hetzner futuro — no basta con confiar en el archivo principal de sshd_config.
Estructura de carpetas (plantilla base)
proyecto/
├── server.js arranque: seguridad + monta rutas
├── package.json
├── .env configuración (no se sube al repo)
├── database/
│ └── schema.sql definición de tablas
├── src/
│ ├── db.js conexión a base de datos (idéntico siempre)
│ ├── middleware/
│ │ └── auth.js JWT + roles (idéntico siempre)
│ └── routes/ un archivo por módulo de negocio
├── public/ frontend (landing + panel)
│ ├── js/api.js cliente de API (idéntico siempre)
│ └── panel/ pantallas del sistema
└── scripts/
└── seed.js crea el primer administrador
Servidor
wnexio-server-2 · Hetzner VPS Helsinki · acceso SSH solo por llave, sin contraseña. Cada proyecto corre bajo su propio usuario del sistema, con PM2 independiente, detrás de Nginx en su propio subdominio de wnexio.com (Cloudflare, registro DNS explícito).
Migración desde el servidor original (comprometido por un ataque de fuerza bruta en agosto 2026) — 6 de 9 proyectos ya migrados: wnexio-panel, finanzas-obras, industriastato, dra-delimar, takeoff, chvtenis. Cada uno migrado con datos reales preservados (bases de datos y archivos subidos), verificados con conteos exactos antes/después.
obra-nuevo, obra-proxy y práctica-inglés se quedan fuera del servidor nuevo por decisión del usuario — código y datos ya respaldados en local (carpetas obra-nuevo/database_backup/, obra-proxy/). Cuando se apague el servidor viejo, obra.wnexio.com y obra2.wnexio.com dejarán de estar accesibles hasta que se decida desplegarlos de nuevo.
| Fecha | Proyecto | Categoría | Concepto | Monto | Periodicidad |
|---|