diff --git a/docs.json b/docs.json index 9ef6c9c1..5700f06f 100644 --- a/docs.json +++ b/docs.json @@ -40,6 +40,7 @@ ] }, "docs/api-key", + "docs/projects", "docs/cookbook", "docs/support", "docs/billing" diff --git a/docs/billing.mdx b/docs/billing.mdx index c3cdb5db..e362e9f0 100644 --- a/docs/billing.mdx +++ b/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 diff --git a/docs/byoc.mdx b/docs/byoc.mdx index 74f096b6..96b1e9c3 100644 --- a/docs/byoc.mdx +++ b/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 diff --git a/docs/faq/public-templates.mdx b/docs/faq/public-templates.mdx index 538f2a09..e909fb61 100644 --- a/docs/faq/public-templates.mdx +++ b/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 ## 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/ +e2b sandbox spawn your-project-slug/ ``` -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 ``` -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). diff --git a/docs/migration/access-token-deprecation.mdx b/docs/migration/access-token-deprecation.mdx index b7bf59c5..9d038edd 100644 --- a/docs/migration/access-token-deprecation.mdx +++ b/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`. diff --git a/docs/projects.mdx b/docs/projects.mdx new file mode 100644 index 00000000..ff21ca47 --- /dev/null +++ b/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. + + +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. + + +## 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). diff --git a/docs/sandbox/environment-variables.mdx b/docs/sandbox/environment-variables.mdx index 0f893e30..a8e7786b 100644 --- a/docs/sandbox/environment-variables.mdx +++ b/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 ``` diff --git a/docs/sandbox/lifecycle-events-api.mdx b/docs/sandbox/lifecycle-events-api.mdx index f8de408c..f9a87f2c 100644 --- a/docs/sandbox/lifecycle-events-api.mdx +++ b/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={ diff --git a/docs/sandbox/lifecycle-events-webhooks.mdx b/docs/sandbox/lifecycle-events-webhooks.mdx index d95fbd11..6cceaa0e 100644 --- a/docs/sandbox/lifecycle-events-webhooks.mdx +++ b/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). @@ -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. ```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. ```js JavaScript & TypeScript diff --git a/docs/template/base-image.mdx b/docs/template/base-image.mdx index f494112d..e98a4c11 100644 --- a/docs/template/base-image.mdx +++ b/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: ```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 ``` diff --git a/docs/template/caching.mdx b/docs/template/caching.mdx index 25b3fa42..6837aa70 100644 --- a/docs/template/caching.mdx +++ b/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. diff --git a/docs/template/names.mdx b/docs/template/names.mdx index a82b6a53..e4c65f33 100644 --- a/docs/template/names.mdx +++ b/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`) -**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`). ## 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. @@ -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 diff --git a/docs/template/tags.mdx b/docs/template/tags.mdx index 54fff77b..629df11a 100644 --- a/docs/template/tags.mdx +++ b/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 ```