Cómo Migrar tu Stack de IA a un VPS Central sin Perder el Hilo

Cómo Migrar tu Stack de IA a un VPS Central sin Perder el Hilo

Cómo Migrar tu Stack de IA a un VPS Central sin Perder el Hilo

Cuando trabajas con múltiples máquinas —laptop, servidores de staging, VPS de producción— es solo cuestión de tiempo antes de que tu entorno se fragmente. Un día tu laptop tiene 3 commits que el servidor no sabe que existen. Al día siguiente, el servidor tiene cambios que olvidaste sincronizar. Y en algún punto, nadie sabe cuál es la fuente de verdad.

Eso es exactamente el problema que resuelve una sesión de infraestructura bien ejecutada. En este artículo documentamos el proceso de consolidar un stack completo de IA —agentes Claude, bases de datos vectoriales RAG, memory files y transcripciones— en un único servidor central. Sin drama, sin pérdida de datos.

---

El Problema: Dos Máquinas, Dos Verdades

Antes de la migración, el estado era el siguiente:

  • Servidor central (VPS4): 5 commits adelante del equipo local. Tenía integraciones activas de 2FA, analytics y mejoras al sistema de agentes.
  • Laptop local: Tenía commits de una API de agregación de datos que el servidor no conocía.
  • Resultado: divergencia. Ninguna de las dos máquinas tenía el código completo.

El primer paso de cualquier migración es el diagnóstico honesto: ¿qué tiene cada máquina? ¿Cuál es más completa? ¿Cuál debe ser el nuevo master?

En cada máquina, revisar estado del repo

git log --oneline -10 git status

Comparar con remoto

git fetch origin git log HEAD..origin/main --oneline

En este caso, el servidor central tenía más trabajo activo y menor deuda técnica. Decisión: el VPS central es la nueva fuente de verdad.

---

Fase 1: Sincronizar el Código de la Aplicación

Con dos ramas divergentes, el merge es necesario. La estrategia:

  1. Hacer push del trabajo local a una rama temporal en GitHub.
  2. En el servidor, hacer pull de esa rama.
  3. Resolver conflictos manualmente (fueron mínimos, ya que tocaban módulos distintos).
  4. Hacer push al main con el historial limpio.
  5. Desde laptop: subir rama de trabajo

    git checkout -b local-work-noc148 git push origin local-work-noc148

    Desde el servidor: integrar

    git fetch origin git merge origin/local-work-noc148 git push origin main

Resultado: repositorio unificado en GitHub, servidor como master activo.

---

Fase 2: Migrar los Memory Files de Claude

Cuando usas Claude Code con memoria persistente, los archivos `.md` de topic memory acumulan contexto valioso: decisiones técnicas, bugs aprendidos, estados de proyectos. Son irreemplazables.

En este caso, 31 archivos de memoria vivían solo en la laptop. El proceso de migración:

Comprimir en laptop

tar -czf memory_backup.tar.gz \ ~/.claude/projects/mi-proyecto/memory/

Transferir al servidor

scp memory_backup.tar.gz usuario@servidor:~/

Extraer en servidor

tar -xzf memory_backup.tar.gz -C ~/
Lección clave: los memory files no son código, son conocimiento operacional. Deben vivir donde vive el agente activo. Si el servidor es tu centro de operaciones, ahí deben estar.

---

Fase 3: Migrar ChromaDB y el Stack RAG

Esta fue la parte más pesada: una base de datos vectorial con 267 MB de embeddings, 33,429 chunks, cubriendo contenido de 4 canales de YouTube y múltiples fuentes de conocimiento especializado.

El proceso:

Verificar tamaño antes de transferir

du -sh ~/chromadb/

267M /home/usuario/chromadb/

Transferir con rsync (reanudable si se corta)

rsync -avz --progress \ ~/chromadb/ \ usuario@servidor:~/chromadb/

Verificar en servidor

python3 -c " import chromadb client = chromadb.PersistentClient(path='/home/usuario/chromadb') collections = client.list_collections() print(f'Colecciones: {len(collections)}') for col in collections: print(f' - {col.name}: {col.count()} chunks') "

Posteriormente, una query de prueba confirmó que el RAG respondía correctamente en el servidor. Sin reindexar, sin regenerar embeddings. La base de datos vectorial es portátil siempre que uses el mismo modelo de embeddings.

Dependencias a verificar antes de migrar ChromaDB

En el servidor destino

pip install chromadb sentence-transformers

Verificar versiones compatibles

python3 -c "import chromadb; print(chromadb.__version__)" python3 -c "from sentence_transformers import SentenceTransformer; print('OK')"

---

Fase 4: Transcripciones y Bases de Conocimiento

Además del RAG principal, el stack incluía directorios de transcripciones de múltiples fuentes:

  • +32 transcripts de un canal especializado en automatización
  • +35 transcripts de contenido sobre liderazgo y negocios
  • +10 transcripts de seguridad informática
  • +51 y +58 transcripts de otros canales adicionales

Y directorios completos de conocimiento estructurado:

  • Base de conocimiento de desarrollo personal (165 MB)
  • Proyectos de tesis académica
  • Recursos de construcción y cálculo
  • Workflows de n8n documentados
  • Recursos de IA Generativa

Para este volumen, `rsync` con compresión es la herramienta correcta:

rsync -avz --progress \
~/MasterProject/ObsidianVault/Claude-Code-Docs/ \
usuario@servidor:~/MasterProject/ObsidianVault/Claude-Code-Docs/

---

La Regla que No Se Puede Saltarse: Secrets Manuales

Durante la sesión, el proceso automatizado bloqueó correctamente la copia de archivos `.env`. Y así debe ser.

Regla de oro: los archivos con credenciales, API keys y tokens nunca se mueven de forma automatizada ni se incluyen en repositorios. El usuario debe copiarlos manualmente, con intención explícita:

Esto lo ejecuta el operador, manualmente, cuando decide hacerlo

scp scripts/.env usuario@servidor:~/MasterProject/scripts/.env scp .env usuario@servidor:~/MasterProject/.env

Este es un punto donde muchos equipos cometen errores: automatizan demasiado y terminan con secrets en logs, en historial de git, o en pipes de CI/CD. La fricción manual en este punto es intencional y protectora.

---

Resultado: Un Centro de Operaciones Unificado

Al final de la sesión, el estado era:

| Componente | Estado |

|---|---|

| Código de aplicación | ✅ Mergeado y en GitHub |

| Memory files de Claude | ✅ 31 archivos en servidor |

| ChromaDB RAG | ✅ 33,429 chunks funcionales |

| Transcripciones | ✅ +186 archivos migrados |

| KBs especializadas | ✅ 5 directorios migrados |

| Secrets (.env) | ⏳ Pendiente manual |

El servidor central es ahora la única fuente de verdad. La laptop pasa a ser un terminal de acceso, no un entorno de desarrollo independiente.

---

Takeaways Clave

1. Define tu fuente de verdad antes de empezar. La confusión entre máquinas viene de no tener una respuesta clara a "¿cuál es el master?". Una vez decidido, todo fluye mejor. 2. RAG es portátil si mantienes consistencia de modelos. No necesitas reindexar al migrar ChromaDB, siempre que uses el mismo modelo de embeddings en origen y destino. Esto ahorra horas de procesamiento. 3. Automatiza todo excepto los secrets. La fricción en el manejo de credenciales es una feature, no un bug. El proceso debe forzar intención humana explícita al mover archivos sensibles.
Regresar al blog

Deja un comentario