Migrar fuera de Zeabur: entrega esta guía a tu coding agent
Hemos recopilado cómo Zeabur ejecuta tus servicios y lo que ha estado haciendo por ti en un documento pensado para coding agents. Tu agent analiza tu configuración actual y decide contigo a dónde migrar.
Zeabur TeamEste artículo también está disponible en English, 繁體中文, 简体中文, 日本語 y Bahasa Indonesia.
TL;DR: Abre un coding agent como Claude Code o Codex y pega la siguiente frase. Si no tienes un coding agent, abre un ticket en Zeabur Support indicando tus servicios y tu fecha de vencimiento, y te ayudaremos con la migración.
Lee https://zeabur.com/blogs/migrate-from-zeabur.md y ayúdame a migrar mis servicios fuera de Zeabur.El agent hace inventario de tus servicios, pregunta por tus necesidades, recomienda opciones y te guía paso a paso en la migración. Te pedirá confirmación antes de cada paso que cambie algo. Para ver lo que lee el agent, cambia a la vista AGENT en la parte inferior de la página.
Esta guía se irá actualizando a medida que avance el cierre y según los problemas que nos reportéis. Antes de empezar, pide a tu agent que vuelva a leer la versión más reciente.
Según el anuncio de cierre: a partir del 1 de diciembre, los servidores dedicados se apagan en sus respectivas fechas de vencimiento; los servicios de los clústeres compartidos se suspenden desde el 1 de diciembre, aunque puedes reanudarlos manualmente para hacer copias de seguridad; el 31 de diciembre se detienen todos los servicios. Planifica según tu propia fecha de vencimiento y no esperes al último día.
¿Por qué dejarlo en manos de un agent?
Cada proyecto, nivel de experiencia y presupuesto es distinto. Hay quien solo quiere que su web siga funcionando, quien quiere control total de un servidor y quien busca algo que mantenga el flujo de Zeabur de «haces push y queda desplegado». Un único tutorial fijo no puede servir a todos.
Tu agent puede leer tu código e iniciar sesión en tu servidor, así que ve mucho más de lo que un artículo puede suponer. Hemos documentado lo que no puede deducir por sí mismo:
- Qué objetos de Kubernetes son tus servicios en Zeabur y dónde están los datos, las imágenes y las variables
- Lo que Zeabur ha estado haciendo por ti y que alguien tendrá que asumir tras la migración
- Los puntos donde las migraciones suelen fallar
El agent recomienda a dónde migrar y qué herramientas usar según tu situación. La decisión final es tuya.
¿Qué tipo de usuario eres?
| Tipo | Qué pasa con la máquina | Cómo lee el agent el estado actual |
|---|---|---|
| Servidor dedicado alquilado en Zeabur | Pertenece a la cuenta cloud de Zeabur y se elimina tras el vencimiento. Los datos del disco no se conservan. | Accede por SSH al servidor y lee k3s directamente |
| Tu propio servidor (vinculado a Zeabur) | Sigue siendo tuyo, pero los componentes de Zeabur instalados dejan de funcionar | Accede por SSH al servidor y lee k3s directamente |
| Clúster compartido | Los servicios se suspenden y después se detienen | Sin SSH; a través de la CLI y el panel de Zeabur |
La contraseña root del servidor dedicado se envió a tu correo al comprarlo. Si la has perdido, restablécela en el panel o inicia sesión con npx zeabur@latest server ssh.
¿Qué ha estado haciendo Zeabur por ti?
Tras la migración, cada uno de estos puntos necesita un nuevo responsable. El agent los tiene en cuenta uno por uno al planificar:
| Lo que hacía Zeabur | Después del cierre de Zeabur |
|---|---|
| Construye imágenes a partir de tu código en Git | Necesitas un Dockerfile o la función de build de la nueva plataforma |
| Guarda las imágenes en el registro de Zeabur | Ya no se pueden descargar y los servicios no arrancan tras un reinicio |
| Despliegue con cada push, historial de despliegues, rollback con un clic | Necesitas CI/CD o una plataforma con estas funciones |
Dominios *.zeabur.app | Dejan de funcionar; cambia a tu propio dominio |
| Emite y renueva certificados HTTPS | Necesitas un proxy inverso o la función de certificados de la plataforma |
Conecta servicios mediante .zeabur.internal | Sustitúyelo por la red del nuevo entorno |
| Inyecta variables entre servicios del mismo proyecto | Lleva contigo los valores reales |
| Copia de seguridad diaria de las bases de datos | Las copias también desaparecen; expórtalas y configura las tuyas |
| Logs, métricas, alertas de caídas y de recursos | Necesitas tu propio sistema de logs, monitorización y alertas |
| Miembros del equipo y permisos | Vuelve a configurarlos en la nueva plataforma |
Los fallos más habituales son las imágenes y las variables inyectadas. Las imágenes solo dan problemas cuando Zeabur ya ha cerrado; las variables rompen la conexión de tu aplicación con la base de datos en el momento de migrar.
Antes de empezar
- Un coding agent, como Claude Code o Codex
- Node.js en tu ordenador y la CLI de Zeabur con sesión iniciada en la cuenta propietaria del proyecto:
npx zeabur@latest auth login - Para servidores dedicados: acceso SSH al servidor
- Permiso para cambiar el DNS de tus dominios. Los dominios comprados en Zeabur se pueden transferir desde el Dashboard
- Tu fecha de vencimiento y una franja en la que aceptes tiempo de inactividad
Deja que el agent use la CLI con la que ya iniciaste sesión en tu ordenador. Un token de acceso de Zeabur tiene permisos sobre toda tu cuenta; pegarlo en un chat equivale a entregar la cuenta.
¿Cómo se desarrolla la migración?
- Inventario: el agent enumera el origen, los dominios y el volumen de datos de cada servicio, y si su imagen se puede exportar.
- Elegir destino: según tu experiencia, tu presupuesto y las funciones que te importan, el agent compara dos o tres opciones, como una plataforma gestionada tipo Railway, una plataforma autoalojada tipo Coolify, k3s o Docker Compose.
- Planificación y prueba: monta los servicios en el nuevo entorno, copia los datos una vez, prueba las funciones principales y restaura de verdad una copia de seguridad.
- Cambio definitivo: con tu aprobación, suspende las aplicaciones en Zeabur, sincroniza los datos por última vez y cambia tú mismo el DNS.
- Traspaso: el agent te explica cómo desplegar, hacer copias de seguridad y volver atrás en el nuevo entorno.
Migramos así un sitio Django en producción (PostgreSQL, Redis, la aplicación y nginx): el número de filas coincidió en las 28 tablas y el cambio definitivo supuso unos 6 minutos de inactividad, de los cuales unos 3 fueron de espera por los certificados.
¿Tienes problemas?
Pide al agent que resuma el estado actual y los mensajes de error, y envíanoslos a través de Zeabur Support junto con tu fecha de vencimiento para que podamos valorar la urgencia.