Ponemos la aplicación en un servidor que controlamos, con publicación reversible, copias de seguridad verificadas y un lugar donde se ve cuándo algo se ha caído.

Donde tú elijas, y verificamos que realmente esté ahí. Nuestros sistemas están en OVHcloud, Bucarest y en Microsoft Azure, Poland Central, ambas en el Espacio Económico Europeo, y la ubicación se confirmó consultando el servicio de metadatos de la máquina virtual y el registro de la dirección — no leyendo la documentación del proveedor. La verificación importa: para una transferencia dentro del Espacio Económico Europeo, el capítulo sobre transferencias de la Ley 195/2024 no se aplica y no se necesitan autorizaciones especiales. Fuera de él, aparece un dossier de garantías.

No siempre. Una plataforma gestionada es la elección correcta cuando el equipo es pequeño, el tráfico es irregular y nada del stack tiene requisitos de residencia. El servidor propio se convierte en el mejor argumento en tres situaciones: cuando los datos deben permanecer en una jurisdicción determinada, cuando el coste se vuelve imprevisible a escala, y cuando queréis poder llevaros todo e iros. También hicimos la migración inversa para un sistema propio: de una base de datos alojada en Estados Unidos a un stack autohospedado en la Unión Europea, con ocho contenedores — base de datos, autenticación, interfaz REST, tiempo real, almacenamiento, metadatos, panel y gate de acceso.

Se revierte, y preferiblemente sola. La versión anterior permanece en el disco junto a la nueva, y después de la publicación una comprobación solicita la página real y confirma que el archivo servido es el recién construido; si no, el script revierte automáticamente. Donde usamos el cambio atómico de enlace simbólico, la reversión es una sola operación. No es una descripción de folleto — el mecanismo ya capturó una publicación con un paquete viejo que quedó en el directorio de trabajo del runner y la anuló.

Diariamente allí donde la construimos — y lo subrayamos, porque una copia automática no aparece por sí sola cuando mueves una aplicación a un servidor. La copia se ejecuta a una hora fija, se recupera en el siguiente arranque si la máquina estaba apagada, y si la exportación sale vacía la ejecución se trata como un fallo. La copia también sale fuera de la máquina, a una región de la Unión Europea, con replicación, versionado, borrado reversible y expiración automática. La prueba de restauración forma parte de la entrega: una copia nunca restaurada es una suposición, no una copia.

Depende de lo que hayamos construido, y vale la pena decirlo sin florituras. Existen las comprobaciones de salud a nivel de contenedor y los puntos de estado de las aplicaciones; existe la alarma hacia un canal de mensajería, con limitación de frecuencia, donde la hemos construido. Un punto de comprobación del estado que nadie consulta no es monitorización — es una página. Si quieres monitorización de verdad, es una etapa separada, con un observador externo que consulta periódicamente y con un destinatario de la alerta que tiene permiso para ser despertado.

No, y es una decisión tomada con conocimiento de causa, no un descuido. La cadena de publicación construye y copia el código; eso es todo. Los cambios de esquema son archivos versionados en el repositorio, aplicados manualmente, con una copia de seguridad fresca detrás, y los componentes que mantienen su esquema en memoria se reinician después. Una migración aplicada automáticamente en producción por un proceso que no sabe qué hay en la tabla es la forma habitual en que se pierden datos de manera irreversible.

Con tres reglas. Las acciones externas se fijan a la huella completa del commit, no a la etiqueta — en marzo de 2026 una acción de uso masivo fue redirigida desde sus etiquetas hacia código malicioso y alcanzó a más de 23.000 repositorios en 24 horas. La copia de trabajo no conserva credenciales. La publicación no se hace con una clave de acceso almacenada en la plataforma de código, sino mediante un ejecutor propio que corre en la máquina objetivo, con permisos concedidos puntualmente. Reconocemos que no todos nuestros proyectos antiguos cumplen todavía las tres; su migración es un trabajo en sí mismo.

Sí, y el primer paso siempre es un inventario, no una modificación. Qué corre de verdad, bajo qué supervisor, con qué versiones, qué puertos están expuestos, qué copias de seguridad existen, si alguna se ha restaurado alguna vez, qué secretos han acabado en repositorios y en qué medida la configuración del repositorio todavía se parece al archivo del servidor. La última comprobación casi siempre produce algo: tenemos documentado, en un proyecto propio, un archivo de configuración editado directamente en producción, que dejó una copia de seguridad con marca de tiempo al lado.

Os vais por completo. La infraestructura está en vuestras cuentas con el proveedor desde el inicio, y la entrega incluye el repositorio con todas las configuraciones del servidor, el procedimiento de publicación y de reversión, el procedimiento de restauración probado y la lista de tareas programadas con lo que hace cada una. El bloqueo contra la eliminación accidental del grupo de recursos de producción se coloca desde la instalación. Si un proveedor condiciona vuestra salida a reescribir la infraestructura, ese era el problema, no la tecnología.