Vercel Sandbox Drives: Persistente Workspaces richtig nutzen

Vercel Sandbox Drives kurz erklärt

Ein Drive wird einmal mit Drive.getOrCreate() angelegt und beim Aufruf von Sandbox.create() unter einem absoluten Mount-Pfad wie /data übergeben. Alle dauerhaft benötigten Dateien gehören in diesen Pfad. Bevor eine weitere Sandbox Schreibzugriff anfordert, muss die erste gestoppt werden. Für parallele Test- oder Review-Sandboxes dient stattdessen drive.snapshot(). Diese Leser erhalten einen eingefrorenen Stand und sehen keine späteren Änderungen.

Ein Drive ähnelt eher einem abtrennbaren Projektraum als einer größeren Festplatte in nur einer Maschine. Die Sandbox stellt das vorübergehende Team samt Werkstatt; das Drive ist der verschlossene Lagerraum, der nach Feierabend bestehen bleibt und an die nächste Werkstatt angeschlossen werden kann.

Vercel nennt Agenten-Workspaces, dateibasierte Memory-Systeme, Abhängigkeitsbäume, Datensätze, Modelle und Build-Artefakte als vorgesehene Einsatzfelder für Drives. Ein früher Nutzer berichtete außerdem, dass ein eigenes Drive pro Agent bei erneuten Verbindungen die Neuinstallation von Abhängigkeiten ersparte. Genau dieser Effekt sollte gemessen werden: weniger Einrichtungsaufwand, nicht bloß mehr Speicherplatz.

Einen dauerhaften Workspace einrichten

Am Anfang stehen ein Vercel-Projekt und eine lokale Authentifizierung. Für die lokale Entwicklung empfiehlt Vercel ein OIDC-Token. vercel env pull schreibt dieses Entwicklungs-Token in .env.local; nach 12 Stunden läuft es ab. Externe CI-Systeme können stattdessen eine Team-ID, eine Projekt-ID und ein Zugriffstoken verwenden.

Zum Veröffentlichungszeitpunkt ist @vercel/sandbox 3.5.0 die stabile npm-Version. In einigen älteren Texten zum Vercel SDK ist noch von einer Private Beta und dem Beta-Kanal die Rede. Die aktuelle Konzeptseite zu Drives und die Ankündigung vom 23. September bestätigen dagegen die Public Beta in allen drei Tarifen.

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

Das folgende Beispiel erstellt ein Drive, bindet es ein und schreibt eine Markierungsdatei sowie einen kleinen Cache. Danach wird die erste Sandbox gestoppt und beides aus einer neuen Sandbox gelesen:

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 rückt in diesem Beispiel bewusst das Drive in den Mittelpunkt. Eine persistente Sandbox besitzt einen eigenen, Snapshot-basierten Mechanismus zum Fortsetzen. Das Drive bleibt dagegen ein unabhängiges Verzeichnis, das zwischen verschiedenen Sandboxes wechseln kann. Beide Ansätze lassen sich kombinieren, wenn eine wiederverwendbare Basisumgebung und ein separat weiterentwickelter Projektordner gebraucht werden.

Die vier entscheidenden Prüfungen

Der Idealfall belegt die Persistenz. Erst die folgenden vier Prüfungen zeigen, ob das Konzept auch dann trägt, wenn mehrere Jobs auf denselben Workspace zugreifen.

1. Bleibt der Workspace in einer neuen Sandbox erhalten?

Markierungsdatei und Cache werden unter /data geschrieben. Anschließend wird der Writer gestoppt und eine andere Sandbox mit demselben Drive erstellt. Nur Dateien, die sich von dort aus /data lesen lassen, belegen die Persistenz des Drives. Dateien an anderen Orten der ersten Sandbox tun das nicht.

Für den eigenen Job sollten vier Zeitpunkte erfasst werden: das Erstellen der ersten Sandbox, die erste Installation der Abhängigkeiten, der erste Stopp sowie das Erstellen der neuen Sandbox einschließlich Cache-Wiederverwendung. Relevant ist die Einrichtungszeit, die beim zweiten Lauf entfällt. Bleiben Dateien zwar erhalten, wird der eigentliche Job dadurch aber nicht kürzer, ist das Drive womöglich praktisch – das Compute-Budget hat es jedoch nicht verändert.

2. Bleibt ein bestehender Leser auf seinem alten Stand?

Zunächst wird eine Markierung geschrieben und der Writer gestoppt. Danach startet mit mounts: { '/data': workspace.snapshot() } ein Leser, der weiterlaufen soll. Eine andere Sandbox bindet das Drive mit Schreibzugriff ein, ersetzt die Markierung und wird anschließend gestoppt. Der vorhandene Leser sollte weiterhin den ursprünglichen Wert liefern, denn seine Ansicht wurde beim Mounten fixiert. Erst ein neu erstellter Snapshot-Leser sieht die Änderung.

Das richtige Bild ist ein Foto, kein Live-Spiegel. snapshot() beschreibt den schreibgeschützten Mount; der zeitlich fixierte Stand entsteht in dem Moment, in dem die Leser-Sandbox ihn einbindet. Außerdem muss mindestens einmal auf ein Drive geschrieben worden sein, bevor sich ein Snapshot mounten lässt. Bei einem noch unbeschriebenen Drive erscheint drive_not_initialized.

3. Wird ein zweiter Writer abgewiesen?

Während eine Sandbox mit Lese-/Schreibzugriff läuft, wird versucht, eine zweite Sandbox mit demselben Zugriff auf dasselbe Drive zu erstellen. Vercel erlaubt jeweils nur einen Lese-/Schreib-Mount. Die erwartete Ablehnung sollte nicht in einer Flut von Wiederholungsversuchen enden. Vor die Writer gehört eine Lease oder Warteschlange; der Eigentümer wird sauber gestoppt. Drive.list() oder currentSandboxName helfen bei Bedarf, die aktuelle Verbindung zu ermitteln.

Die abgerufene Vercel-Dokumentation nennt für diesen zweiten Writer keinen stabilen Fehlercode. Der fehlgeschlagene Sandbox-Start ist daher der maßgebliche Vertrag. Produktivlogik sollte nicht von einem geratenen Code-String abhängen.

4. Stimmen die Hauptregionen überein?

Nach dem Erstellen eines Drives in iad1 folgt ein Mount-Versuch durch eine Sandbox mit der Hauptregion sfo1. Vercel dokumentiert diese Abweichung als drive_region_mismatch. Die Region eines Drives lässt sich nachträglich nicht ändern. Wird getOrCreate() für denselben Namen mit einer anderen Region oder Maximalgröße aufgerufen, entsteht ein conflict-Fehler.

Die Region sollte bei beiden Objekten ausdrücklich gesetzt werden – auch wenn iad1 bereits die Standardeinstellung ist. So kann eine spätere Änderung des Projektstandards einen gewöhnlichen Neustart nicht unbemerkt in einen Regionsfehler verwandeln.

Nach einem Wegwerftest werden alle Writer und Leser gestoppt. Mit Drive.list() oder currentSandboxName lässt sich prüfen, ob das Drive wirklich getrennt ist; erst danach folgt await workspace.delete(). Das Löschen entfernt die Dateien dauerhaft und wird von Vercel abgelehnt, solange noch eine Sandbox verbunden ist.

Vier getrennte Posten auf der Rechnung

Drive-Speicher ersetzt die Sandbox-Rechenleistung nicht. Neben dem bestehenden Compute-Zähler kommen drei Speicherzähler hinzu. Für iad1 gelten derzeit diese veröffentlichten Preise:

Die Preise unterscheiden sich je nach Region. Downloads aus dem Internet – etwa npm-Pakete und Git-Repositories – sind kostenlos. Die CPU und der bereitgestellte Arbeitsspeicher während ihrer Installation werden dennoch abgerechnet. Deshalb kann sich ein Abhängigkeits-Cache rechnen: Er spart wiederkehrende Einrichtungsarbeit, nicht Download-Traffic.

Ein nützliches Rechenbeispiel für Pro oder Enterprise, ausdrücklich kein Benchmark: Ein Abhängigkeitsbaum mit 10 GB kostet über einen vollen Monat $0.50 Speichergebühr. Wird der vollständige Baum in 100 Läufen gelesen, ergeben sich 1,000 GB an logischen Lesevorgängen und damit $1.50. Ein einmaliger Schreibvorgang über 10 GB kostet $0.04. In Summe entfallen $2.04 auf das Drive – zuzüglich Compute, Arbeitsspeicher, Übertragung und späterer Schreibvorgänge.

Vercels eigenes Preisbeispiel beziffert einen fünfminütigen KI-Codevalidierungslauf mit 2 vCPUs, 4 GB und 100% CPU-Auslastung in iad1 auf etwa $0.03. Es wäre falsch anzunehmen, dass ein Drive diesen Betrag vollständig einspart. Gemessen werden muss der tatsächlich vermiedene Installationsabschnitt. Dessen eingesparte Rechenzeit und Wartezeit wird anschließend den Kosten für Drive-Speicher, Lese- und Schreibvorgänge gegenübergestellt.

Im Hobby-Tarif sind 15 GB Drive-Speicher sowie jeweils 30 GB Lese- und Schreibvorgänge pro Monat enthalten. Unabhängig davon liegt die Standard-Maximalgröße eines einzelnen Hobby-Drives bei 1 GiB. Hobby berechnet keine Mehrnutzung: Nach Überschreiten eines Kontingents wird das Erstellen neuer Sandboxes pausiert. In kostenpflichtigen Tarifen gilt ohne maxSize eine Standard-Maximalgröße von 1 TiB; das Standardkontingent lässt sich bis auf 16 TiB konfigurieren.

Sieben Anwendungsfälle – sortiert nach größtem Nutzen

1. Coding-Agent-Produkte mit wiederkehrenden Projekten

Jeder Agenten-Workspace erhält ein eigenes Drive. Repository, erzeugte Dateien, Aufgabennotizen und Paket-Cache liegen unter dem Mount und werden beim nächsten Arbeitsschritt an eine neue Sandbox gehängt. Das Produktteam muss denselben Workspace nicht nach jedem Lebenszyklusereignis der Sandbox neu aufbauen. Nutzer erhalten Kontinuität, ohne Compute dauerhaft laufen zu lassen.

Dies ist der stärkste Anwendungsfall, weil sich häufige Neustarts und wiederholte Einrichtung gegenseitig verstärken. Die Ein-Writer-Regel passt zudem gut zu einem aktiven Agenten pro Workspace, während Vorschauen und Tests eingefrorene Leser verwenden können.

2. Build-Teams mit immer derselben Abhängigkeitsinstallation

Ein kontrollierter Writer befüllt das Drive einmal. Spätere Jobs binden den Abhängigkeitsbaum als schreibgeschützten Snapshot ein. Das Team tauscht wiederkehrende Installationszeit und CPU-Kosten gegen eine gespeicherte Kopie plus Lesegebühren. Besonders gut funktioniert das bei großen Abhängigkeiten, die sich seltener ändern als die Jobs laufen und deren Cache-Pfad sich vom Quellcode trennen lässt.

3. Review-Pipelines mit mehreren Agenten

Ein Koordinator schreibt das zu prüfende Repository. Anschließend laufen Sicherheitsprüfung, Tests, Linting und Dokumentationskontrolle parallel auf Snapshot-Lesern. Alle Reviewer beginnen mit demselben Stand und können den gemeinsamen Quellcode nicht verändern. Diese Eigenschaft ist bewusst restriktiv: Benötigt ein Reviewer eine spätere Änderung des Koordinators, muss er mit einem neuen Snapshot neu erstellt werden.

4. Datenteams mit einem wiederverwendbaren, vorbereiteten Datensatz

Ein Writer lädt den Datensatz herunter, normalisiert und indexiert ihn. Anschließend wird er als Snapshot in kurzlebige Analyse-Sandboxes eingebunden. Die teure Vorbereitung fällt einmal an, während parallele Leser konsistente Eingabedaten erhalten. Das eignet sich für reproduzierbare Evaluationen, nicht aber für Live-Datensätze, die jeder Leser direkt aktualisieren möchte.

5. Forschungsagenten, die über mehrere Sitzungen Dateien sammeln

Quellen, extrahierter Text, Zwischentabellen und ein lokaler Suchindex werden auf dem Drive gespeichert. Eine neue Sandbox kann in diesem Ordner weiterarbeiten, statt dieselben Quellen erneut abzurufen und zu indexieren. Der Gewinn liegt in reproduzierbarem Arbeitsmaterial. Riskant wird es, wenn diese Dateien ohne separates Backup oder Herkunftssystem als dauerhafte Wahrheit gelten.

6. Modell- oder Toolchain-Caches für sporadische Jobs

Modellgewichte, Compiler und andere große Eingaben werden vorab auf einem Drive abgelegt; Compute startet erst bei Eingang eines Jobs. Der erste Lesezugriff bei einem Cache Miss kann langsamer sein, weil Vercel die Daten aus dem dauerhaften Speicher holt. Spätere Zugriffe bei einem Cache Hit laufen mit NVMe-Geschwindigkeit. Das Muster lohnt sich, wenn ungenutzter Compute teurer wäre als die Speicherung der tatsächlich belegten Bytes.

7. Lernplattformen mit fortsetzbaren Projekten

Jedes Projekt erhält ein Drive, das für eine Sitzung an eine neue Sandbox gehängt und danach wieder getrennt wird. Die Dateien bleiben für die Lernenden erhalten, während die Plattform die Rechenleistung freigibt. Das Ein-Writer-Limit verhindert praktischerweise, dass zwei aktive Sitzungen gleichzeitig dasselbe Projekt bearbeiten. Identitäts-, Backup- und Aufbewahrungsregeln muss das Produkt trotzdem selbst bereitstellen.

Zwei Produkte, die sich daraus bauen lassen

Suchvolumen zeigt Nachfrage, ist aber keine Umsatzprognose. Entscheidend ist, ob die Funktion einer bereits lösungssuchenden Zielgruppe eine schmerzhafte Aufgabe abnimmt.

Stärkste Idee: ein Lease-Broker für Agenten-Workspaces

Eine kleine Steuerungsebene ordnet jedem Agenten- oder Nutzerprojekt ein Drive zu, vergibt eine zeitlich begrenzte Writer-Lease, startet eingefrorene Leser-Sandboxes für Tests und Vorschauen und zeigt Region, Verbindungsstatus sowie Löschstatus an. Teams, die Coding-Agenten entwickeln, dürften für diese Koordination zahlen: Der reine Speicherbaustein entscheidet nicht, wem der Writer gehört.

US-Keyword-Daten weisen rund 8,100 monatliche Suchanfragen nach „ai powered coding agent“ mit kommerzieller Suchabsicht aus. Im angrenzenden Markt sind Plattformrechnungen bereits üblich: E2B verlangt für Pro $150 pro Monat zuzüglich Nutzung; persistente, mehrtägige Sitzungen gehören dort zum individuell kalkulierten Enterprise-Tarif. Das ist kein direkter Preisvergleich, aber ein belastbarer Budgetanker für Teams, die Agenteninfrastruktur einkaufen.

Die kleinste verkaufsfähige Version braucht eine Zuordnung von Drives zu Workspaces, eine Writer-Warteschlange mit Ablaufzeit, das Erstellen von Snapshot-Lesern, eine Verbrauchsansicht und eine sichere Bereinigung. Schwierig bleibt der Wettbewerbsvorteil. Vercel oder ein Agenten-Framework kann einen dünnen Wrapper selbst übernehmen. Das Produkt benötigt deshalb Betriebsrichtlinien, Audit-Verlauf, Wiederherstellung und Anbieterportabilität – nicht bloß einen hübscheren getOrCreate()-Button.

Eine Warmstart-Schicht für Cloud-Entwicklungsumgebungen

Für Plattformteams lassen sich eine Repository-Vorlage, ein Drive-gestützter Abhängigkeitspfad, ein Cache-Warmer, eine explizite Regionsrichtlinie und eine Vorher-nachher-Messung der Einrichtungszeit bündeln. Verkauft wird das Ergebnis als kürzerer Kaltstart innerhalb einer bestehenden Vercel-Landschaft, nicht als vollständige Entwicklungsumgebung.

US-Keyword-Daten zeigen rund 1,900 monatliche Suchanfragen nach „cloud integrated development environment“ bei einem CPC von $9.03. Dieser Wert in der bezahlten Suche deutet auf konkurrierende Anbieter für diese Zielgruppe hin. Das MVP kann eng umrissen bleiben: zunächst Node und pnpm, eine Region, eine Cache-Richtlinie und ein Dashboard, das Drive-Speicher, Lesevorgänge, Schreibvorgänge, aktive CPU und Arbeitsspeicher getrennt ausweist.

Die Grenze liegt im Umfang. Ein Drive stellt genau ein persistentes Verzeichnis bereit. Es ersetzt weder IDE noch Secret-Verwaltung, Zusammenarbeit, Image-Verwaltung, Backup oder regionsübergreifende Replikation. Wer allein auf diesem Baustein einen vollständigen Cloud-Arbeitsplatz verspricht, wird Käufer enttäuschen.

Grenzen, die das Systemdesign bestimmen

• Ein Writer bedeutet einen Eigentümer. Änderungen werden serialisiert. Snapshot-Leser eignen sich für parallele Aufgaben, nicht für gemeinsames Bearbeiten.
• Leser bleiben eingefroren. Eine laufende Leserinstanz sieht spätere Änderungen nie. Für einen neuen Stand wird sie mit einem neuen Snapshot erstellt.
• Vor dem ersten Snapshot muss geschrieben werden. Das Drive wird initialisiert, bevor Leser-Sandboxes starten.
• Die Hauptregion muss übereinstimmen. Ein Drive verbleibt in einer Region und lässt sich nicht verschieben. Die Region wird ausdrücklich gesetzt.
• Eine Sandbox unterstützt vier Mounts. Jeder Pfad muss absolut sein; Mount-Pfade dürfen sich nicht überschneiden.
• Ein Drive ist nicht die gesamte Maschine. Ein Sandbox-Snapshot dient einer kompletten Umgebung. Ein Drive ist für ein unabhängig weiterentwickeltes Verzeichnis gedacht.
• Kalte Lesezugriffe können langsamer sein. Lesezugriffe bei Cache Hits und Schreibvorgänge laufen mit NVMe-Geschwindigkeit, bei Cache Misses aus dem dauerhaften Speicher gilt das nicht.
• Löschen ist endgültig. Vercel bezeichnet drive.delete() als permanent. Ein Drive darf nicht das einzige Backup sein.

Hinzu kommt ein aktueller Widerspruch in der Dokumentation. Laut Ankündigung vom 23. September können Sandboxes mit eingebundenen Drives keine Failover-Regionen verwenden. Die auf den 22. September datierte Regionsseite erklärt dagegen, dass Failover ein Drive regionsübergreifend mit höherer Leselatenz laden kann. Bis Vercel diese Aussagen in Einklang bringt, sollte Drive-Failover in der Architektur als nicht unterstützt gelten und vor jedem produktiven Einsatz erneut getestet werden.

Wird während eines einzelnen Laufs lediglich mehr temporärer Speicher benötigt, ist ein Drive nicht die erste Wahl. Der ergänzende Leitfaden zur größeren Scratch-Disk von Vercel Sandbox zeigt, wie sich mehr Platz ohne Persistenz einplanen lässt.

Der nächste konkrete Schritt

Für die kommende Woche wird ein Agenten-Workflow mit häufigen Neustarts ausgewählt. Nur dessen Projektdateien und Abhängigkeits-Cache kommen auf ein Drive, der Schreibzugriff bleibt bei einem Writer, und anschließend laufen die vier beschriebenen Prüfungen. Erfasst werden die Einrichtungszeit vor und nach der Änderung sowie Drive-Speicher, Lesevorgänge, Schreibvorgänge, aktive CPU und Arbeitsspeicher als getrennte Positionen. Erst wenn der kürzere Neustart die zusätzliche Speicherrechnung und Koordinationsregel rechtfertigt, wird das Muster ausgeweitet.

Wenn ein langlebiger Agenten-Workspace produktionsreif entworfen und instrumentiert werden soll, entwickle ich KI-Produktionssysteme.