docs: rename Teams to Projects (+ new Projects page)

docs.json

@@ -40,6 +40,7 @@
                 ]
               },
               "docs/api-key",
+              "docs/projects",
               "docs/cookbook",
               "docs/support",
               "docs/billing"

docs/billing.mdx

@@ -30,7 +30,7 @@ To upgrade your plan or purchase add-ons, visit the [dashboard billing tab](http
 
 You pay per second for compute resources while your sandbox is running.
 
-Upgrading to the Pro tier does not grant additional credits. It only increases the limits available to your team (such as concurrent sandboxes, continuous runtime, and resource ceilings).
+Upgrading to the Pro tier does not grant additional credits. It only increases the limits available to your project (such as concurrent sandboxes, continuous runtime, and resource ceilings).
 
 ### Compute costs
 

docs/byoc.mdx

@@ -42,7 +42,7 @@ After that, we will receive the IAM role needed for managing account resources.
 For AWS account quota limits may need to be increased.
 
 Terraform configuration and machine images will be used for provisioning BYOC cluster.
-When provisioning is done and running, we will create a new team under your E2B account that can be used by SDK/CLI the same way as it is hosted on E2B Cloud.
+When provisioning is done and running, we will create a new project under your E2B account that can be used by SDK/CLI the same way as it is hosted on E2B Cloud.
 
 ## FAQ
 

docs/faq/public-templates.mdx

@@ -1,9 +1,9 @@
 ---
-title: "Can I make a template public so other teams can use it?"
+title: "Can I make a template public so other projects can use it?"
 sidebarTitle: Public templates
 ---
 
-Yes. By default, templates are scoped to the team that built them, but you can publish a template to make it usable by any other E2B team.
+Yes. By default, templates are scoped to the project that built them, but you can publish a template to make it usable by any other E2B project.
 
 ## Publishing a template
 
@@ -23,13 +23,13 @@ e2b template publish <template-name>
 
 ## Using a public template
 
-Once published, other teams can create a sandbox from your template by referencing it with the full namespaced format `team-slug/template-name`:
+Once published, other projects can create a sandbox from your template by referencing it with the full namespaced format `project-slug/template-name`:
 
 ```bash
-e2b sandbox spawn your-team-slug/<template-name>
+e2b sandbox spawn your-project-slug/<template-name>
 ```
 
-The same naming format works in the SDKs. Pass `team-slug/template-name` as the template alias to `Sandbox.create()`.
+The same naming format works in the SDKs. Pass `project-slug/template-name` as the template alias to `Sandbox.create()`.
 
 ## Unpublishing
 
@@ -39,6 +39,6 @@ To revoke public access, either toggle the template back to private in the [dash
 e2b template unpublish <template-name>
 ```
 
-The template stays in your team and remains usable by your team. It is just no longer reachable by others.
+The template stays in your project and remains usable by your project. It is just no longer reachable by others.
 
-For more on naming and how the team-slug prefix works, see [Template names](/docs/template/names).
+For more on naming and how the project-slug prefix works, see [Template names](/docs/template/names).

docs/migration/access-token-deprecation.mdx

@@ -30,7 +30,7 @@ Next, set a single environment variable wherever you run the CLI and remove the
 export E2B_API_KEY=e2b_...
 ```
 
-Your API key is scoped to a team, so the CLI targets the right team automatically. There is no separate team variable to set.
+Your API key is scoped to a project, so the CLI targets the right project automatically. There is no separate project variable to set.
 
 With the API key set, run CLI commands directly. You do not need to run `e2b auth login`.
 

docs/projects.mdx

@@ -0,0 +1,29 @@
+---
+title: "Projects"
+icon: "folder"
+---
+
+A **project** is the workspace under your E2B account that owns everything you build: API keys, sandboxes, templates, and billing. Every sandbox you create runs inside a project, and every API key is scoped to exactly one project, so the key you use determines which project's resources and limits apply.
+
+<Info>
+Projects were previously called **Teams**. The concept is unchanged; only the name is new. Existing API keys, template slugs, and integrations keep working without any change.
+</Info>
+
+## What a project owns
+
+Your project is the boundary for the resources and settings you manage in the [E2B Dashboard](https://e2b.dev/dashboard):
+
+- **API keys**: Each key authenticates against a single project. See [API key](/docs/api-key) for where to find yours.
+- **Sandboxes**: Every sandbox is created and billed within the project tied to your API key.
+- **Templates**: Templates are scoped to the project that built them and are namespaced by the project slug. See [Template names](/docs/template/names).
+- **Billing and limits**: Your tier (concurrent sandboxes, continuous runtime, disk size, and other resource ceilings) applies to the whole project. See [Billing](/docs/billing).
+
+## Finding your project
+
+Open the [E2B Dashboard](https://e2b.dev/dashboard) to see the project you're currently working in, manage its API keys, and review usage. Your API key already targets the right project, so the SDK and CLI pick it up automatically with no extra configuration.
+
+## Project slug and template names
+
+Each project has a unique slug used to namespace its templates. A template named `my-app` in a project with the slug `your-project-slug` is stored as `your-project-slug/my-app`. You can reference it by its short name within the project, or by the full `project-slug/template-name` format from anywhere (for example, to use a public template from another project).
+
+For the full naming rules and how the slug prefix works, see [Template names](/docs/template/names).

docs/sandbox/environment-variables.mdx

@@ -10,7 +10,6 @@ This page covers how to set and use environment variables in a sandbox, and defa
 Sometimes it's useful to know if the code is running inside a sandbox. Upon creating a sandbox, useful sandbox metadata is set as environment variables for commands: 
 - `E2B_SANDBOX` is set to `true` for processes to know if they are inside our VM.
 - `E2B_SANDBOX_ID` to know the ID of the sandbox.
-- `E2B_TEAM_ID` to know the team ID that created the sandbox. 
 - `E2B_TEMPLATE_ID` to know what template was used for the current sandbox.
 
 You can try it out by running the following code in the sandbox:
@@ -30,7 +29,7 @@ result = sandbox.commands.run("echo $E2B_SANDBOX_ID")
 These default environment variables are only accessible via the SDK, when using the CLI you can find them in the form of dot files in the `/run/e2b/` dir: 
 ```sh
 user@e2b:~$ ls -a /run/e2b/
-.E2B_SANDBOX  .E2B_SANDBOX_ID  .E2B_TEAM_ID  .E2B_TEMPLATE_ID
+.E2B_SANDBOX  .E2B_SANDBOX_ID  .E2B_TEMPLATE_ID
 ```
 </Note>
 

docs/sandbox/lifecycle-events-api.mdx

@@ -4,7 +4,7 @@ sidebarTitle: Lifecycle events API
 ---
 
 The lifecycle API provides RESTful endpoints to request the latest sandbox lifecycle events. This allows you to track when sandboxes are created, paused, resumed, updated, snapshotted, or killed, along with metadata.
-All requests require authentication using your team [API key](/docs/api-key#where-to-find-api-key).
+All requests require authentication using your project [API key](/docs/api-key#where-to-find-api-key).
 
 ## Retention
 
@@ -34,7 +34,7 @@ const resp1 = await fetch(
 )
 const sandboxEvents = await resp1.json()
 
-// Get the latest 10 events for all sandboxes associated with the team
+// Get the latest 10 events for all sandboxes associated with the project
 const resp2 = await fetch(
   'https://api.e2b.app/events/sandboxes?limit=10',
   {
@@ -117,7 +117,7 @@ resp1 = requests.get(
 )
 sandbox_events = resp1.json()
 
-# Get the latest 10 events for all sandboxes associated with the team
+# Get the latest 10 events for all sandboxes associated with the project
 resp2 = requests.get(
     "https://api.e2b.app/events/sandboxes?limit=10",
     headers={

docs/sandbox/lifecycle-events-webhooks.mdx

@@ -5,14 +5,14 @@ sidebarTitle: Lifecycle events webhooks
 
 Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur. 
 This allows you to receive real-time updates about sandbox creation, updates, and termination without having to poll the API.
-All webhook requests require authentication using your team [API key](/docs/api-key#where-to-find-api-key).
+All webhook requests require authentication using your project [API key](/docs/api-key#where-to-find-api-key).
 
 ## Webhook management
 
 ### Register webhook
 
 Register a new webhook to receive sandbox lifecycle events.
-The webhook will be registered for the team ID associated with your API key.
+The webhook will be registered for the project associated with your API key.
 All events specified during webhook creation will be sent to URL provided during registration with [following payload](#webhook-payload).
 
 <CodeGroup>
@@ -66,7 +66,7 @@ if resp.status_code == 201:
 
 ### List webhooks
 
-List all registered webhooks for your team.
+List all registered webhooks for your project.
 
 <CodeGroup>
 ```js JavaScript & TypeScript
@@ -106,7 +106,7 @@ if resp.status_code == 200:
 
 ### Get webhook configuration
 
-Retrieve the current webhook configuration for your team.
+Retrieve the current webhook configuration for your project.
 
 <CodeGroup>
 ```js JavaScript & TypeScript

docs/template/base-image.mdx

@@ -97,21 +97,21 @@ template.from_base_image()  # e2bdev/base
 
 A sandbox gets its CPU and memory from the template it's built on. A sandbox built from `base` starts with **2 vCPU and 512 MiB of RAM**.
 
-You can override CPU and memory when you [build a template](/docs/template/build) (`cpuCount`/`cpu_count`, `memoryMB`/`memory_mb`). Disk size is not a default you set per sandbox; it's determined by your team's tier limit and applied at build time (see [Build limits](/docs/template/quickstart#build-limits)).
+You can override CPU and memory when you [build a template](/docs/template/build) (`cpuCount`/`cpu_count`, `memoryMB`/`memory_mb`). Disk size is not a default you set per sandbox; it's determined by your project's tier limit and applied at build time (see [Build limits](/docs/template/quickstart#build-limits)).
 
 ### Build from existing template
 
-Extend an existing template from your team or organization:
+Extend an existing template from your project or organization:
 
 <CodeGroup>
 
 ```typescript JavaScript & TypeScript
-template.fromTemplate("my-template"); // Your team's template
+template.fromTemplate("my-template"); // Your project's template
 template.fromTemplate("acme/other-template"); // Full namespaced reference
 ```
 
 ```python Python
-template.from_template("my-template")  # Your team's template
+template.from_template("my-template")  # Your project's template
 template.from_template("acme/other-template")  # Full namespaced reference
 ```
 

docs/template/caching.mdx

@@ -8,7 +8,7 @@ Each layer is cached based on the command and its inputs (e.g., files copied, co
 If a layer command is unchanged and its inputs are the same as in any previous build, we reuse the cached layer instead of rebuilding it.
 
 This significantly speeds up the build process, especially for large templates with many layers.
-The cache is scoped to the team, so even if you have multiple templates, they can share the same cache if they have identical layers.
+The cache is scoped to the project, so even if you have multiple templates, they can share the same cache if they have identical layers.
 
 ## Invalidation
 You can invalidate the caches only partially, or for the whole template.

docs/template/names.mdx

@@ -48,17 +48,17 @@ Before a name is used, it's trimmed of surrounding whitespace and lowercased. Th
 
 Uppercase letters are accepted on input and lowercased automatically, so `My-Template` and `my-template` refer to the same name. Any other character (spaces inside the name, dots, slashes, and so on) is rejected.
 
-## Team-local naming
+## Project-local naming
 
-Template names are scoped to your team. This means:
+Template names are scoped to your project. This means:
 
-- 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`)
+- Your template named `my-app` is stored as `your-project-slug/my-app`
+- You can reference it simply as `my-app` within your project
+- Other projects can have their own `my-app` template without conflict
+- Public templates should be referenced using the full namespaced format (`project-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`).
+**Backwards Compatibility**: Existing public templates remain accessible without the project slug prefix. New public templates should be referenced using the full namespaced format (`project-slug/template-name`).
 </Info>
 
 ## Common use cases
@@ -149,7 +149,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 within your team with the `exists` method.
+You can check if a name is already in use within your project with the `exists` method.
 
 <CodeGroup>
 
@@ -173,4 +173,4 @@ 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
+3. **Use consistent naming**: Establish a naming convention for your project and stick to it

docs/template/tags.mdx

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