Vercel Sandbox Drives: cómo crear espacios de trabajo persistentes

Vercel Sandbox Drives: la respuesta breve

Crea el Drive una sola vez con Drive.getOrCreate(), pásalo a Sandbox.create() bajo una ruta de montaje absoluta como /data y guarda dentro de esa ruta todos los archivos que deban persistir. Detén el primer sandbox antes de que otro solicite acceso de lectura y escritura. Si necesitas sandboxes paralelos para pruebas o revisiones, monta drive.snapshot(). Esos lectores reciben una vista congelada y no verán las escrituras posteriores.

Un Drive se parece más a una sala de proyecto desmontable que a un disco duro más grande dentro de una sola máquina. El sandbox es el equipo y el taller temporales; el Drive es el almacén cerrado que permanece cuando el equipo se retira y puede conectarse al siguiente taller.

Vercel propone los Drives para espacios de trabajo de agentes, memoria en disco, árboles de dependencias, conjuntos de datos, modelos y artefactos de compilación. Uno de los primeros usuarios también señaló que asignar un Drive a cada agente permitía reconectar sin reinstalar las dependencias. Ese es el beneficio que conviene comprobar: menos trabajo de preparación, no solo más almacenamiento.

Cómo configurar un espacio de trabajo persistente

Empieza con un proyecto de Vercel y autenticación local. Vercel recomienda usar un token OIDC para el desarrollo local. vercel env pull guarda ese token de desarrollo en .env.local, y el token caduca después de 12 horas. Un sistema externo de CI puede usar en su lugar un identificador de equipo, un identificador de proyecto y un token de acceso.

La versión estable de npm al momento de publicar es @vercel/sandbox 3.5.0. Parte de la documentación antigua del SDK de Vercel todavía habla de beta privada y recomienda el canal beta, pero la página actual sobre Drives y el lanzamiento del 23 de septiembre confirman la beta pública en los tres planes.

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

Ahora crea un Drive, móntalo, escribe un marcador y una pequeña caché, detén ese sandbox y lee ambos archivos desde uno nuevo:

import { Drive, Sandbox } from '@vercel/sandbox';

const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
  region: 'iad1',
});

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

persistent: false mantiene este ejemplo centrado en el Drive. Un sandbox persistente tiene su propio mecanismo de reanudación basado en snapshots, mientras que un Drive sigue siendo un directorio independiente que puede pasar de un sandbox a otro. Es posible combinar ambos cuando se necesita un entorno base reutilizable y una carpeta de proyecto que evolucione por separado.

Las cuatro comprobaciones que importan

El recorrido ideal demuestra la persistencia. Estas cuatro pruebas confirman cómo se comportará el diseño cuando varios trabajos utilicen el mismo espacio.

1. Comprueba que el espacio sobrevive a un sandbox nuevo

Escribe el marcador y la caché dentro de /data, detén el proceso escritor y crea otro sandbox con el mismo Drive. Lee los archivos desde /data. Los archivos que estén en otra ubicación del primer sandbox no demuestran que el Drive sea persistente.

Registra cuatro tiempos de tu propio trabajo: la creación del primer sandbox, la instalación inicial de dependencias, la primera detención y la creación de un sandbox nuevo con reutilización de la caché. La cifra útil es el tiempo de preparación que desaparece en la segunda ejecución. Un Drive que conserva los archivos pero no acorta el trabajo real puede resultar práctico, pero no habrá cambiado el presupuesto de cómputo.

2. Comprueba que un lector antiguo conserva su vista

Escribe un marcador inicial, detén el escritor y crea un lector con mounts: { '/data': workspace.snapshot() }. Déjalo en ejecución. Monta el Drive con lectura y escritura en otro sandbox, sustituye el marcador y detén el escritor. El lector que ya estaba activo debería seguir devolviendo el marcador original porque su vista quedó fijada al montarlo. Para ver el reemplazo, crea un nuevo lector de snapshot.

El modelo mental correcto es una fotografía, no un espejo en vivo. Llamar a snapshot() describe el montaje de solo lectura; la vista de un momento concreto se establece cuando el sandbox lector lo monta. Además, el Drive debe haber recibido al menos una escritura antes de poder montar un snapshot. Un Drive nunca escrito devuelve drive_not_initialized.

3. Comprueba que se rechaza un segundo escritor

Mantén activo un sandbox con acceso de lectura y escritura e intenta crear otro con el mismo tipo de acceso al mismo Drive. Vercel solo permite un montaje de lectura y escritura a la vez. No conviertas el fallo esperado en una avalancha de reintentos. Coloca un arrendamiento o una cola delante de los escritores, detén al propietario de forma ordenada y usa Drive.list() o currentSandboxName cuando necesites localizar la conexión.

La documentación de Vercel consultada no asigna un código de error estable a este caso de segundo escritor. Considera el fallo al crear el sandbox como el contrato y evita que la lógica de producción dependa de una cadena de error supuesta.

4. Comprueba que la región principal coincide

Crea el Drive en iad1 e intenta montarlo en un sandbox cuya región principal sea sfo1. Vercel documenta esa discrepancia como drive_region_mismatch. La región de un Drive no se puede cambiar después de crearlo, y solicitar con getOrCreate() el mismo nombre pero otra región o tamaño máximo produce un error conflict.

Configura la región en ambos objetos aunque iad1 sea el valor predeterminado. Una configuración explícita evita que un cambio posterior en el valor predeterminado del proyecto convierta un reinicio rutinario en un fallo de región.

Tras una prueba desechable, detén todos los escritores y lectores, confirma con Drive.list() o currentSandboxName que el Drive está desconectado y ejecuta await workspace.delete(). La eliminación borra los archivos de forma permanente, y Vercel la rechaza mientras haya un sandbox conectado.

La factura tiene cuatro componentes distintos

El almacenamiento del Drive no sustituye el cómputo del sandbox. Añade tres medidores de almacenamiento al medidor de cómputo existente. En iad1, las tarifas publicadas actualmente son:

Las tarifas cambian según la región. Las descargas de internet, como paquetes npm y repositorios Git, son gratuitas, pero la CPU y la memoria aprovisionada utilizadas para instalarlos sí se contabilizan. Por eso una caché de dependencias puede compensar el costo: elimina trabajo de preparación repetido, no cargos por descarga.

Este es un ejemplo útil para planificar en Pro o Enterprise, no un benchmark. Mantener un árbol de dependencias de 10 GB durante un mes completo cuesta $0.50. Leer el árbol completo en 100 ejecuciones suma 1,000 GB de lecturas lógicas, es decir, $1.50. Escribir una vez esos 10 GB cuesta $0.04. La parte correspondiente al Drive asciende a $2.04, antes de cómputo, memoria, transferencia o escrituras posteriores.

El propio ejemplo de precios de Vercel sitúa una ejecución de validación de código con IA de cinco minutos, 2 vCPU y 4 GB en unos $0.03 en iad1, suponiendo una utilización de CPU del 100%. No des por hecho que el Drive ahorrará todo ese importe. Mide el tramo de instalación que realmente elimina y compara el cómputo y la espera humana ahorrados con la factura de almacenamiento, lecturas y escrituras del Drive.

Hobby incluye 15 GB de almacenamiento para Drives, además de 30 GB mensuales tanto de lecturas como de escrituras. Por separado, cada Drive de Hobby tiene un máximo predeterminado de 1 GiB. Hobby no cobra excedentes: la creación de sandboxes nuevos se pausa al superar una cuota. En los planes de pago, un Drive tiene un máximo predeterminado de 1 TiB si se omite maxSize, y la cuota predeterminada se puede configurar hasta 16 TiB.

Siete casos de uso, ordenados por quién obtiene más valor

1. Un producto de agentes de programación con proyectos recurrentes

Asigna un Drive a cada espacio de trabajo del agente y guarda bajo el punto de montaje el repositorio, los archivos generados, las notas de tareas y la caché de paquetes. En el siguiente turno, conecta ese Drive a un sandbox nuevo. El equipo de producto evita reconstruir el mismo espacio después de cada ciclo de vida del sandbox y el usuario obtiene continuidad sin mantener el cómputo activo.

Es el caso más sólido porque la frecuencia de los reinicios y la preparación repetida se acumulan. La regla de un solo escritor también encaja de forma natural con un agente activo por espacio, mientras que las vistas previas y las pruebas pueden usar lectores congelados.

2. Un equipo de compilación que repite la misma instalación de dependencias

Llena un Drive desde un escritor controlado y permite que los trabajos posteriores monten snapshots de solo lectura del árbol de dependencias. El equipo sustituye instalaciones repetidas, consumo de CPU y esperas por una copia almacenada más los cargos de lectura. El modelo funciona mejor cuando las dependencias son grandes, cambian con menos frecuencia que las ejecuciones y la ruta de caché puede separarse del árbol de código fuente.

3. Un flujo de revisión con varios agentes

Haz que un coordinador escriba el repositorio candidato y, después, distribuye la revisión de seguridad, las pruebas, el linting y la comprobación de documentación entre lectores de snapshot. Todos los revisores parten del mismo estado y ninguno puede modificar el código compartido. La limitación es intencional: si un revisor necesita una edición posterior del coordinador, habrá que volver a crearlo con un snapshot nuevo.

4. Un equipo de datos que reutiliza un conjunto preparado

Utiliza un escritor para descargar, normalizar e indexar un conjunto de datos y monta después snapshots en sandboxes de análisis de corta duración. La preparación costosa solo ocurre una vez y los lectores simultáneos reciben una entrada consistente. Es una buena opción para evaluaciones repetibles, pero no para un conjunto de datos en vivo que todos los lectores pretendan actualizar en el mismo lugar.

5. Un agente de investigación que acumula archivos durante varias sesiones

Guarda en el Drive citas, texto extraído, tablas intermedias y un índice de búsqueda local. Un sandbox nuevo puede retomar el trabajo desde esa carpeta sin volver a rastrear e indexar las mismas fuentes. La ventaja es disponer de material de trabajo reproducible; el riesgo es tratar los archivos como verdad duradera sin un sistema independiente de respaldo o procedencia.

6. Una caché de modelos o herramientas para trabajos esporádicos

Prepara un Drive con pesos de modelos, compiladores u otras entradas de gran tamaño y enciende el cómputo solo cuando llegue un trabajo. La primera lectura con fallo de caché puede ser más lenta porque Vercel recupera los datos del almacenamiento duradero; las lecturas posteriores con acierto de caché funcionan a velocidad NVMe. El modelo compensa cuando mantener almacenados los bytes utilizados cuesta menos que dejar el cómputo inactivo.

7. Una plataforma educativa con proyectos reanudables

Asigna un Drive a cada proyecto, móntalo en un sandbox nuevo durante la sesión y desconéctalo al terminar. Los estudiantes conservan los archivos mientras la plataforma libera el cómputo. El límite de un escritor ayuda a impedir que dos sesiones activas editen el mismo proyecto, pero el producto todavía necesita sus propias reglas de identidad, respaldo y retención.

Dos productos que vale la pena construir

El volumen de búsqueda es una señal de demanda, no un pronóstico de ingresos. La pregunta útil es si esta capacidad elimina una tarea dolorosa para un grupo que ya busca una solución.

La opción más sólida: un gestor de arrendamientos para espacios de agentes

Crea un pequeño plano de control que asocie cada agente o proyecto de usuario con un Drive, conceda un arrendamiento temporal a un único escritor, cree sandboxes lectores congelados para pruebas y vistas previas, y muestre la región, el estado de conexión y el estado de eliminación. Los equipos que desarrollan agentes de programación pagarían por esta capa de coordinación porque el almacenamiento básico no decide quién controla al escritor.

Los datos de palabras clave de Estados Unidos muestran cerca de 8,100 búsquedas mensuales de “ai powered coding agent”, con intención comercial. El mercado adyacente ya acepta pagar por una plataforma: E2B ofrece Pro por $150 al mes más consumo, mientras que las sesiones persistentes de varios días se reservan para su nivel Enterprise personalizado. No es una comparación directa de precios, pero sí una referencia presupuestaria creíble para equipos que compran infraestructura de agentes.

La versión mínima vendible necesita una asociación entre Drive y espacio de trabajo, una cola de escritores con vencimiento, creación de lectores de snapshot, una vista de consumo y limpieza segura. La dificultad está en la ventaja competitiva. Vercel o un framework de agentes pueden integrar una capa superficial, así que el producto necesita políticas operativas, historial de auditoría, recuperación y portabilidad entre proveedores, no solo un botón más atractivo para getOrCreate().

Una capa de arranque rápido para entornos de desarrollo en la nube

Combina una plantilla de repositorio, una ruta de dependencias respaldada por Drive, un calentador de caché, una política explícita de región y telemetría del tiempo de preparación antes y después para equipos de plataforma. Vende el resultado como una forma de reducir los arranques en frío dentro de una infraestructura de Vercel existente, no como un entorno de desarrollo completo.

Los datos de palabras clave de Estados Unidos muestran cerca de 1,900 búsquedas mensuales de “cloud integrated development environment”, con un CPC de $9.03. Ese valor en búsqueda de pago sugiere que los proveedores compiten por esa audiencia. El MVP puede ser acotado: primero Node y pnpm, una región, una política de caché y un panel que separe almacenamiento, lecturas, escrituras, CPU activa y memoria.

La dificultad es el alcance. Un Drive aporta un único directorio persistente. No incluye un IDE, gestión de secretos, colaboración, gestión de imágenes, respaldo ni replicación entre regiones. Un producto que prometa una estación de trabajo completa en la nube basándose solo en este componente decepcionará a los compradores.

Límites que deberían cambiar el diseño

• Un escritor implica un propietario. Serializa las modificaciones. Los lectores de snapshot sirven para distribuir trabajo, no para editar en colaboración.
• Los lectores quedan congelados. Un lector en ejecución nunca recibe una escritura posterior. Vuelve a crearlo con un snapshot nuevo.
• El primer snapshot exige una escritura. Inicializa el Drive antes de arrancar sandboxes lectores.
• La región principal debe coincidir. El Drive permanece en una sola región y no se puede trasladar. Configura la región de forma explícita.
• Cada sandbox admite cuatro montajes. Todas las rutas deben ser absolutas y no pueden solaparse.
• Un Drive no es la máquina completa. Usa un snapshot del sandbox para un entorno completo y un Drive para un directorio que deba evolucionar de manera independiente.
• Las lecturas en frío pueden ser más lentas. Las lecturas con acierto de caché y las escrituras funcionan a velocidad NVMe, pero los fallos de caché que recurren al almacenamiento duradero no.
• La eliminación es definitiva. Vercel describe drive.delete() como permanente. Un Drive no debería ser el único respaldo.

También existe un conflicto vigente en la documentación. El lanzamiento del 23 de septiembre afirma que los sandboxes que montan Drives no pueden usar regiones de conmutación por error. La página sobre regiones, fechada el 22 de septiembre, dice que la conmutación por error puede cargar un Drive entre regiones con mayor latencia de lectura. Hasta que Vercel resuelva la contradicción, considera que la conmutación por error de Drives no es compatible con tu arquitectura y vuelve a probarla antes de depender de ella.

Si el trabajo solo necesita más espacio temporal durante una ejecución, un Drive no es la primera opción adecuada. Consulta la guía complementaria sobre el disco temporal de mayor tamaño de Vercel Sandbox y evita añadir persistencia al diseño.

La acción para el lunes

Elige para la próxima semana un flujo de agente que se reinicie con frecuencia. Coloca en un solo Drive únicamente los archivos del proyecto y la caché de dependencias, conserva un único escritor y ejecuta las cuatro comprobaciones anteriores. Registra el tiempo de preparación antes y después, además del almacenamiento, las lecturas, las escrituras, la CPU activa y la memoria del Drive como partidas separadas. Amplía el patrón solo si el reinicio más corto compensa la factura adicional de almacenamiento y la regla de coordinación.

Si necesitas diseñar e instrumentar para producción un espacio de trabajo duradero para agentes, desarrollo sistemas de IA para producción.