Un servidor Ubuntu en producción necesita una base repetible. Los paquetes dependen de la carga, pero identidad, parches, exposición de red, supervisión, backups y telemetría son universales. Documenta la configuración como código o runbook para no preparar el siguiente servidor de memoria.
Empieza por propiedad e inventario
Registra proveedor, región, propósito, responsable, versión, direcciones públicas, dominios y renovaciones. Define qué datos puede procesar el host y dónde se almacenan. Mantén un inventario de dependencias y usa solo software con licencia correcta y fuentes de datos autorizadas.
Protege el acceso administrativo
Crea cuentas nominales, usa claves SSH y desactiva el acceso root directo y las contraseñas después de verificar las claves. Limita sudo, protege claves privadas y activa MFA en el proveedor. Mantén una vía de emergencia documentada y pruébala sin debilitar el acceso normal.
Actualiza y reduce exposición
Instala versiones soportadas, aplica parches y decide si las actualizaciones automáticas encajan. Elimina paquetes sin uso y escucha solo en interfaces necesarias. Configura firewall restrictivo, publica la aplicación mediante el proxy previsto y mantén bases de datos privadas. El rate limiting complementa la autenticación, no la sustituye.
Ejecuta servicios de forma predecible
Usa systemd o un supervisor apropiado con usuario sin privilegios, entorno explícito, límites de reinicio, orden de arranque y recursos acotados. No guardes secretos en repositorios ni historial. Valida la configuración antes de recargar y conserva artefactos versionados para volver atrás rápido.
Backups y recuperación
Copia bases de datos, uploads y configuración irreemplazable en almacenamiento separado. Cifra, define retención y monitoriza cada ejecución. Un log correcto no demuestra recuperación: restaura periódicamente en un entorno aislado y mide tiempo de recuperación y pérdida de datos aceptable.
Logs, métricas y alertas
Recoge disco, memoria, CPU, carga, red, servicios, caducidad de certificados, errores HTTP y salud de aplicación. Centraliza logs importantes con acceso y retención limitados. Cada alerta debe exigir acción, enlazar un runbook y probarse antes del lanzamiento.
Errores comunes
- mantener SSH por contraseña o root directo
- abrir todos los puertos a internet
- ejecutar la aplicación como root
- guardar secretos en el código
- confundir snapshots con backups probados
- actualizar sin rollback
- llenar disco con logs ilimitados
- lanzar sin alertas de certificados y servicios
Checklist práctica
- asignar responsable y documentar inventario
- verificar claves SSH y acceso de emergencia
- actualizar y eliminar servicios sin uso
- configurar firewall y bases privadas
- usar usuarios de mínimo privilegio
- guardar secretos fuera del repositorio
- configurar rotación de logs
- copiar a almacenamiento cifrado separado
- probar una restauración
- monitorizar salud y certificados
- documentar deploy y rollback
Cuándo tiene sentido contratar a una persona técnica
La ayuda senior compensa si una caída afecta ingresos, existen datos personales, varios servicios comparten host o nadie es responsable de recuperar. Un especialista puede revisar exposición, automatizar la base y probar backups sin alterar producción. Compara supervisores en PM2 vs Supervisor vs systemd.
Conclusión
Estar listo para producción es una disciplina de recuperación. Mantén el servidor mínimo, observable y reproducible. Consulta mis servicios de infraestructura o contacta conmigo.