Migración de VPS
Levanta una copia en Vertra Cloud, mueve variables y datos, prueba en la dirección de la plataforma y solo entonces apunta el DNS. La VPS antigua sigue atendiendo hasta que decidas.
Un servidor propio da control, y trabajo con él: sistema, actualizaciones, proceso, certificado, copias de seguridad. En un PaaS entregas el código y la plataforma se ocupa del resto.
Actualizar el sistema operativo, aplicar parches y vigilar el servidor es rutina de VPS. En el PaaS, las versiones de los lenguajes las mantiene la plataforma, con actualizaciones de seguridad.
systemd, pm2 o supervisor existen para eso. En Vertra Cloud el contenedor se reinicia automáticamente cuando la aplicación se cae, en todas las aplicaciones.
El certificado SSL/TLS se emite y se renueva antes de caducar, con redirección de HTTP a HTTPS por defecto, también en dominio propio (según el plan).
Snapshots de aplicación y de base de datos, con restauración y descarga en zip. Antes de eliminar o reiniciar una base de datos, la plataforma hace sola un snapshot de seguridad.
La comparación cubre las tareas que más pesan en la rutina de quien mantiene una VPS.
| Tarea | En la VPS | En Vertra Cloud |
|---|---|---|
| Sistema operativo | Lo actualizas y lo vigilas tú. | La plataforma mantiene el entorno de ejecución. |
| Versión del lenguaje | Instalar y actualizar a mano. | Elige la versión en el panel, entre 13 lenguajes. |
| Mantener la app en pie | systemd, pm2 o supervisor. | Reinicio automático del contenedor. |
| HTTPS | Certbot, renovación y redirecciones. | SSL/TLS automático, con redirección de HTTP a HTTPS. |
| Despliegue | scp, rsync o git pull en el servidor. | Zip, GitHub, CLI o extensión de VS Code. |
| Base de datos | Instalar, configurar y actualizar el motor. | PostgreSQL, MongoDB, Redis y MySQL gestionados, con TLS obligatorio. |
| Copias de seguridad | Un script y almacenamiento por tu cuenta. | Snapshots de aplicación y de base de datos. |
| Logs | journalctl, archivos de log y SSH. | Logs en vivo en el panel. |
| Disco | Lo que tenga el servidor. | 10 GB por aplicación. |
A cambio, dejas de administrar el servidor: cada aplicación corre en un contenedor aislado, y lo que no cabe en ese modelo hay que adaptarlo antes de migrar.
Mover no exige reescribir la aplicación. La secuencia es levantar una copia, mover configuración y datos, probar y solo entonces mover el tráfico.
El puerto viene de PORT y el servidor escucha en 0.0.0.0. Los secretos vienen de variables de entorno. El comando de inicio no depende de un Procfile ni de un archivo de la VPS, y nada importante se guarda solo en el disco local. Un Procfile con web: node server.js pasa a ser START=node server.js en el vertracloud.config.
Sube el .zip, importa el repositorio de GitHub o ejecuta vertra upload. Mantén la VPS activa y no toques el DNS todavía.
Vuelve a crear las variables en Configuración, dejando fuera PORT y HOST, que define la plataforma. Es un buen momento para cambiar los secretos en vez de copiarlos.
Crea la base de datos y usa las herramientas del propio motor: pg_dump y pg_restore, mongodump y mongorestore, mysqldump. En Redis, vuelve a crear las claves que importan o deja que la caché se caliente de nuevo. La conexión exige TLS y certificado de cliente.
Usa la dirección *.vertraweb.app y ejercita los flujos que importan mientras sigues la pestaña de logs.
Pon la aplicación antigua en modo solo lectura o mantenimiento, haz una última sincronización de los datos y apunta el DNS a Vertra Cloud con un dominio personalizado. Baja el TTL del registro a unos minutos el día anterior y mantén la VPS unos días como plan B antes de apagarla.
Por lo general, no. Lo que suele cambiar es poco: el puerto viene de PORT, los secretos pasan a variables de entorno y el comando de inicio entra en la configuración (un Procfile pasa a ser START= en el vertracloud.config). El código sigue igual.
No tiene por qué. El orden seguro es levantar una copia, probarla en la dirección de la plataforma y solo después cambiar el DNS, con la VPS antigua atendiendo hasta entonces. Bajar el TTL del DNS antes del cambio hace que el cambio, o la vuelta atrás, se propague más rápido.
Exporta con la herramienta del motor, crea una base de datos nueva e importa: pg_dump y pg_restore en PostgreSQL, mongodump y mongorestore en MongoDB, mysqldump en MySQL. La conexión exige TLS y certificado de cliente, así que la cadena de conexión de la aplicación cambia.
La plataforma ejecuta 13 lenguajes, entre ellos Node.js, Python, Go, Rust, Java, PHP, Ruby, Deno, .NET y Elixir. Al subir un zip, los proyectos Next.js, Nuxt, SvelteKit, Remix, Astro y Vite ya llegan con los comandos de build y de inicio sugeridos.
Dejas de administrar la máquina. A cambio, cada aplicación corre en un contenedor aislado, con terminal y logs en el panel, y la plataforma se ocupa del sistema y de los certificados.
Sí. El dominio personalizado recibe SSL automático tras validar el DNS, y la redirección de HTTP a HTTPS viene activada por defecto. El dominio propio depende del plan; consulta la página de planes.
Pruebas todo en la dirección de la plataforma, y la VPS sigue atendiendo hasta el cambio de DNS.
Empezar la migración