docs: update template naming to reflect team-local names (#89)

Author: dobrac

docs/billing.mdx

@@ -43,8 +43,7 @@ You can customize allocated CPU and RAM when building custom templates by specif
 ```js JavaScript & TypeScript
 import { Template, defaultBuildLogger } from 'e2b'
 
-await Template.build(template, {
-  alias: "my-template",
+await Template.build(template, 'my-template', {
   cpuCount: 8,
   memoryMB: 4096,
   onBuildLogs: defaultBuildLogger(),
@@ -55,7 +54,7 @@ from e2b import Template, default_build_logger
 
 Template.build(
     template,
-    alias="my-template",
+    'my-template',
     cpu_count=8,
     memory_mb=4096,
     on_build_logs=default_build_logger(),

docs/template/base-image.mdx

@@ -81,7 +81,8 @@ template.from_image("custom-image:latest")
 template.from_base_image()  # e2bdev/base
 
 # Build from existing template
-template.from_template("existing-template-alias")
+template.from_template("my-template")  # Your team's template
+template.from_template("acme/other-template")  # Full namespaced reference
 
 # Parse and build from Dockerfile
 template.from_dockerfile("Dockerfile")

docs/template/names.mdx

@@ -38,16 +38,18 @@ sandbox = Sandbox.create('my-python-env')
 
 </CodeGroup>
 
-## Uniqueness Requirement
+## Team-Local Naming
 
-<Warning>
-Template names must be **globally unique across the entire E2B platform**, not just within your team or account. This means if another user has already claimed a name, you cannot use it for your template.
-</Warning>
+Template names are scoped to your team. This means:
 
-When choosing a name, consider using:
-- Your company or project name as a prefix (e.g., `acme-api-server`)
-- Version numbers or environment indicators (e.g., `myapp-v2`, `myapp-staging`)
-- Descriptive names that indicate the template's purpose (e.g., `data-analysis-python`)
+- Your template named `my-app` is stored as `your-team-slug/my-app`
+- You can reference it simply as `my-app` within your team
+- Other teams can have their own `my-app` template without conflict
+- Public templates should be referenced using the full namespaced format (`team-slug/template-name`)
+
+<Info>
+**Backwards Compatibility**: Existing public templates remain accessible without the team slug prefix. New public templates should be referenced using the full namespaced format (`team-slug/template-name`).
+</Info>
 
 ## Common Use Cases
 
@@ -137,7 +139,7 @@ When building variants with the same template definition but different CPU/RAM c
 
 ## Checking Name Availability
 
-You can check if a name is already in use with the `exists` method.
+You can check if a name is already in use within your team with the `exists` method.
 
 <CodeGroup>
 
@@ -162,4 +164,3 @@ print(f"Name {'is taken' if exists else 'is available'}")
 1. **Use descriptive names**: Choose names that clearly indicate the template's purpose or configuration
 2. **Use tags for versioning**: Instead of baking version numbers into names, use [tags](/docs/template/tags) for version management (e.g., `myapp:v1`, `myapp:v2`)
 3. **Use consistent naming**: Establish a naming convention for your team and stick to it
-4. **Document your names**: Keep a record of which names are used for which purposes in your team

docs/template/tags.mdx

@@ -8,12 +8,12 @@ Template versioning allows you to maintain multiple versions of the same templat
 
 ## Tag Format
 
-Tags follow the `name:tag` format, where `name` is your template's unique identifier and `tag` is the version label.
+Tags follow the `name:tag` format, where `name` is your template's identifier and `tag` is the version label.
 
 ```
-my-template:v1.0.0
-my-template:production
-my-template:latest
+my-template:v1.0.0              // Within your team
+my-template:production          // Within your team
+acme/my-template:v1.0.0         // Full namespaced reference
 ```
 
 ## The Default Tag