docs: clarify templates vs snapshots performance and many-template usage

docs/sandbox/snapshots.mdx

@@ -10,9 +10,9 @@
 
 ## Prerequisites
 
 Snapshots require templates with envd version `v0.5.0` or above. If you are using a custom template created before envd `v0.5.0`, you need to rebuild it.
 
 You can check the template envd version using the `e2b template list` command or by viewing the templates list on the dashboard.
 
 ## Snapshots vs. Pause/Resume
 
@@ -97,7 +97,7 @@
 const snapshot = await sandbox.createSnapshot()
 
 // Create a new sandbox from the snapshot
 const newSandbox = await Sandbox.create(snapshot.snapshotId)
 ```
 ```python Python highlight={5}
 from e2b import Sandbox
@@ -111,17 +111,17 @@
 
 ## List snapshots
 
 You can list all snapshots. The method returns a paginator for iterating through results.
 
 <CodeGroup>
 ```js JavaScript & TypeScript
 import { Sandbox } from 'e2b'
 
 const paginator = Sandbox.listSnapshots()
 
 const snapshots = []
 while (paginator.hasNext) {
   const items = await paginator.nextItems()
   snapshots.push(...items)
 }
 ```
@@ -180,15 +180,24 @@
 |---|---|---|
 | Defined by | Declarative code (Template builder) | Capturing a running sandbox |
 | Reproducibility | Same definition produces the same sandbox every time | Captures whatever state exists at that moment |
 | Best for | Repeatable base environments | Checkpointing, rollback, forking runtime state |
 
 Use templates when every sandbox should start from an identical, known state — pre-installed tools, fixed configurations, consistent environments.
 Use snapshots when you need to capture or fork live runtime state that depends on what happened during execution.
 
+### Performance: prefer templates when possible
+
+For workloads where either approach would work, **templates are faster and more resource-efficient** than snapshots:
+
+- **Compact memory.** During a template build, the guest OS is restarted before the long-running process is captured. Memory is compact and any setup-time processes that aren't needed at runtime are gone, so sandboxes start with less memory pressure and fewer resources.
+- **More effective prefetching.** E2B optimistically prefetches data needed to start a sandbox. For templates this prefetching is highly effective; for snapshots its effectiveness is significantly lower due to memory fragmentation and general memory pressure from the captured live state.
+
+If you can express the state you need as a declarative template build, you'll generally get faster cold starts and lower overhead than capturing the equivalent state as a snapshot. There is no limit that should discourage you from creating many templates — see [Creating many templates](/docs/template/quickstart#creating-many-templates) for using templates per-customer or per-project.
+
 ## Use cases
 
 - **Checkpointing agent work** — an AI agent has loaded data and produced partial results in memory. Snapshot it so you can resume or fork from that point later.
 - **Rollback points** — snapshot before a risky or expensive operation (running untrusted code, applying a migration, refactoring a web app). If it fails, rollback - spawn a fresh sandbox from the snapshot before the operation happened.
 - **Forking workflows** — spawn multiple sandboxes from the same snapshot to explore different approaches in parallel.
 - **Cached sandboxes** — avoid repeating expensive setup by snapshotting a sandbox that has already loaded a large dataset or started a long-running process.
 - **Sharing state** — one user or agent configures an environment interactively, snapshots it, and others start from that exact state.

docs/template/quickstart.mdx

@@ -239,12 +239,50 @@
 The template name is the identifier that can be used to create a new Sandbox.
 </Note>
 
+## Creating many templates
+
+There is no practical limit on how many templates you can have. It's perfectly fine to create **tens or hundreds of thousands of templates** — for example, one template per customer, per project, or per agent run.
+
+The template build environment is a full sandbox environment, so you can do anything during the build that you can do inside a running sandbox, including running Docker containers as part of the setup.
+
+Compared to [snapshots](/docs/sandbox/snapshots), templates start faster and use fewer resources because the guest OS is restarted before the long-running process is captured and prefetching is significantly more effective. If your workload involves spinning up many per-customer or per-project environments, prefer templates over snapshots.
+
+### Layering templates with `fromTemplate`
+
+When you build many similar templates (e.g. a customer-specific template per customer that all share the same base setup), use [`fromTemplate`](/docs/sdk-reference/js-sdk/v2.29.1/template#fromtemplate) to start from an existing template instead of rebuilding the shared layers from scratch each time. This keeps per-customer builds fast and reuses the cached base.
+
+<CodeGroup>
+
+```typescript JavaScript & TypeScript
+import { Template } from 'e2b'
+
+// Per-customer template built on top of a shared base template
+export const template = Template()
+  .fromTemplate('my-base-template')
+  .copyDirectory('./customers/acme', '/app/config')
+  .setEnvs({ CUSTOMER_ID: 'acme' })
+```
+
+```python Python
+from e2b import Template
+
+# Per-customer template built on top of a shared base template
+template = (
+    Template()
+    .from_template("my-base-template")
+    .copy_directory("./customers/acme", "/app/config")
+    .set_envs({"CUSTOMER_ID": "acme"})
+)
+```
+
+</CodeGroup>
+
 ## Build limits
 
 Template builds are subject to the following limits:
 
 - **Max build duration**: Builds can run for **up to 1 hour**. If a build exceeds this, it will be terminated.
 - **Max vCPUs per build**: 8 on Hobby, 8+ on Pro, custom on Enterprise.
 - **Max memory per build**: 8 GB on Hobby, 8+ GB on Pro, custom on Enterprise.
 - **Max disk size per build**: 10 GB on Hobby, 20+ GB on Pro, custom on Enterprise.
 - **Concurrent builds**: 20 on Hobby and Pro, custom on Enterprise.