Does sandbox git clone public repos or use faster method?

If I start a sandbox with a public github repo as source, the vm will just git clone that repo or there is something that makes it faster than git cloning after the sandbox is live?

Now I have a thorough understanding. Here's the answer:

##How Git Source Works in Sandbox Creation

Based on the source code, when you create a sandbox with a public GitHub repo as source, the source configuration is passed directly to the Vercel API server-side — the git clone happens as part of the sandbox provisioning, not after the VM is live and available to you.

Here's the flow from the code:

###1. You specify a source of type "git"

From packages/vercel-sandbox/src/sandbox.ts (lines 30–53):

source?:
  | {
      type: "git";
      url: string;
      depth?: number;     // Creates shallow clones with limited commit history (minimum: 1)
      revision?: string;  // Clones and checks out a specific commit, branch, or tag
    }
  | { /* same but with username/password for private repos */ }
  | { type: "tarball"; url: string };

###2. It gets sent as-is in the POST /v2/sandboxes API call

From packages/vercel-sandbox/src/api-client/api-client.ts (lines 185–207), the source is just JSON-serialized and sent in the request body:

body: JSON.stringify({
  projectId: params.projectId,
  ports: params.ports,
  source: params.source,  // passed directly to the API
  // ...
}),

###3. The clone happens server-side during VM provisioning

The Sandbox.create() call blocks until the sandbox is fully ready — meaning the git clone is done as part of the provisioning before the promise resolves. By the time you get the Sandbox instance back, the repo is already cloned onto the VM's filesystem.

###What makes it faster (or not)?

From the SDK side, there's no client-side caching or pre-fetching magic for the initial clone. However, there are two built-in optimizations you can use:

1. depth parameter — Use depth: 1 for a shallow clone, which avoids downloading full git history:

   source: {
     type: "git",
     url: "https://github.com/org/repo.git",
     depth: 1,        // ← shallow clone, much faster for large repos
     revision: "main", // ← specific branch/tag/commit
   }
   

2. Snapshots for subsequent uses — This is the big one. After the initial clone (and any setup like npm install), you can snapshot the sandbox and create future sandboxes from that snapshot. This completely avoids re-cloning:

   // First time: clone + install
   const sandbox = await Sandbox.create({ source: { type: "git", url: "..." } });
   await sandbox.runCommand("npm", ["install"]);
   const snapshot = await sandbox.snapshot();
   
   // Subsequent times: instant restore from snapshot (no git clone!)
   const fast = await Sandbox.create({
     source: { type: "snapshot", snapshotId: snapshot.snapshotId },
   });
   

3. Persistence — Sandboxes are persistent by default. If you use Sandbox.get({ name: "my-sandbox" }) to resume an existing sandbox, the filesystem state is restored from a snapshot automatically — no re-clone needed.

###TL;DR

The first creation with a git source is essentially a server-side git clone during VM provisioning (use depth: 1 to speed it up). There's no special caching layer that makes it faster than a regular clone. But for subsequent uses, you can use snapshots or persistence to skip the clone entirely and boot from a saved filesystem state.