Vercel Sandbox añade Drives: cuándo sí resuelven workspaces largos y cuándo siguen ganando los snapshots
Vercel lanzó Drives para Sandbox en private beta el 5 de junio de 2026. La novedad útil no es solo guardar archivos: es separar caché, workspace y estado compartido del ciclo de vida del sandbox para agentes que vuelven al mismo trabajo.
La persistencia sola no resuelve todo. Un agente puede reanudar un sandbox, sí, pero eso no siempre significa que ya tienes una estrategia limpia para separar caché, datos pesados, workspace compartido y estado temporal.
Por eso el anuncio de Drives para Vercel Sandbox del 5 de junio de 2026 sí merece atención. Vercel describe los drives como almacenamiento persistente y montable con ciclo de vida independiente del sandbox. En otras palabras: el compute puede morir, pero el volumen sigue ahí para montarse otra vez después.
La pregunta correcta no es “si persiste”, sino “qué persiste”
Vercel ya venía empujando sandboxes persistentes y snapshots. Drives cambia la conversación porque obliga a distinguir entre tipos de estado.
La documentación oficial pone la diferencia bastante clara:
- drive: un directorio montado para caché, datos compartidos o salida del agente;
- snapshot: el filesystem completo del sandbox;
- sandbox persistente: reanudación automática del estado guardado.
Ese matiz importa mucho para builders que ya trabajan con agentes largos. No todo debe vivir en el mismo saco.
Dónde sí tiene sentido usar drives
La doc de Vercel recomienda drives para tres patrones bastante concretos:
- agent workspace que crece con el tiempo;
- shared cache de dependencias o builds;
- pre-seeding de datos para prender compute solo cuando hace falta.
Mi lectura es simple: si tu agente vuelve al mismo repo, recompila lo mismo o arrastra datasets pesados, un drive puede ahorrarte reinstalar y rehidratar en cada sesión.
Además, durante la beta privada, Vercel deja varias señales útiles:
- hasta 4 drives por sandbox;
- hasta 1 TiB por drive;
- y uso pensado para caché y casos no críticos mientras madura la feature.
El punto importante es la comparación contra snapshots
La mejor parte de la documentación no es el lanzamiento. Es la tabla de comparación.
Vercel diferencia drives y snapshots por performance, tamaño, expiración y uso recomendado. El resumen operativo sería este:
- si quieres estado completo del sandbox y lecturas/escrituras consistentes, mira snapshots;
- si quieres datos grandes o compartidos con ciclo de vida más durable, mira drives;
- si quieres combinar ambos, también se puede.
Esa distinción le evita a muchos equipos un error común: usar un solo mecanismo de persistencia para problemas distintos.
El tradeoff todavía es muy real
No conviene esconder lo que Vercel también deja explícito:
- los drives siguen en private beta;
- son single reader, single writer por ahora;
- y recomiendan no tratarlos como base de datos crítica en esta etapa.
Eso baja bastante el entusiasmo fácil. Sirven más como herramienta de arquitectura para workspaces y cachés que como capa universal de estado compartido.
También hay una diferencia práctica que vale búsqueda cualificada:
vercel sandbox drivesvercel sandbox snapshotsworkspace persistente agentescache sandbox agent
La gente que busca eso no está comparando logos. Está intentando decidir cómo reducir costo y fricción sin romper aislamiento.
Mi regla práctica
Yo lo evaluaría así:
- si el agente recompila o reinstala demasiado, prueba drives;
- si necesitas clonar el filesystem entero para reanudar exacto, usa snapshots;
- si el dato es crítico o necesita lectores concurrentes, todavía no apostaría por drives en beta;
- si el flujo mezcla ambos problemas, separa estado completo y caché desde el diseño.
Esta noticia conversa bien con Vercel vuelve persistentes sus sandboxes, porque ahora la capa de persistencia ya no es una sola decisión sino un conjunto de decisiones más finas. Y si aún no has ordenado el contrato básico de tools y validación, empieza por el curso gratis.
La conclusión corta: Drives hace más serio el runtime de agentes en Vercel porque separa almacenamiento y compute. La conclusión útil: ahora también te obliga a pensar mejor qué estado debe durar, cuánto, y con qué garantías.