depot · depot-bot · Oct 2, 2026
diff --git a/content/account.mdx b/content/account.mdx
@@ -10,9 +10,7 @@ The [Depot dashboard](/orgs/) is where you manage your account and organizations
 
 ## Account settings
 
-You can access your user account settings in the Depot dashboard. Click the organization name at the top of the page and select **User settings**.
-
-![Select User settings from the depot dashboard menu](/images/docs/dashboard-user-settings.png)
+You can access your user account settings in the Depot dashboard. Click the organization name in the sidebar and select **Settings**, then **Personal settings** under **Account**.
 
 From the user [Settings](/settings) page you can do the following:
 
@@ -27,7 +25,7 @@ You can't change the email address for your Depot account. To delete an account,
 
 Every action you take in Depot is within the context of an organization. An organization typically represents a single company or team. Depot bills at the organization level, consolidating all usage across products into a single invoice.
 
-You can view all of your builds, runners, usage, and billing per organization in your Depot dashboard. Configure organization-level settings in the organization [Settings](/orgs/_/settings) page.
+You can view all of your builds, runners, usage, and billing per organization in your Depot dashboard. Configure organization-level settings in the organization [Settings](/orgs/_/settings/general) page.
 
 ### Create an organization
 
@@ -60,8 +58,8 @@ Organizations have role-based access. When you create an organization, you have
 If you have a Startup or Business plan, you can invite users to join an organization.
 
 1. Log in to your [Depot dashboard](/orgs).
-2. Under **Organization**, click [Settings](/orgs/_/settings).
-3. From the **Members** section of the **Settings** page you can:
+2. Open **Settings**.
+3. Select [Members](/orgs/_/settings/members) under **Organization** to:
    - View members and change their role.
    - View or remove pending invites.
    - Invite new members using either their existing Depot account email or the email they'll use to sign up for Depot.
@@ -80,8 +78,8 @@ To delete an organization, send a request to help@depot.dev. Include the name of
 
 ## Billing
 
-Each Depot organization has its own [plan](/pricing) and billing. To view an organization's billing, payment, and plan details, go to the organization [Settings](/orgs/_/settings) page in your Depot dashboard.
+Each Depot organization has its own [plan](/pricing) and billing. To view an organization's billing, payment, and plan details, go to the [Billing & usage](/orgs/_/settings/billing-and-usage) page in your Depot dashboard.
 
-You can access invoices from Stripe that contain VAT information through the Billing Portal in your organization [Settings](/orgs/_/settings).
+You can access invoices from Stripe that contain VAT information through the Billing Portal in [Billing & usage](/orgs/_/settings/billing-and-usage).
 
 For billing issues, see the [troubleshooting page](/docs/troubleshooting#billing).
diff --git a/content/api/github-actions-api.mdx b/content/api/github-actions-api.mdx
@@ -0,0 +1,147 @@
+---
+title: GitHub Actions API
+ogTitle: Automate Depot GitHub Actions jobs and analytics
+description: Use the Depot GitHub Actions API to inspect jobs and logs, analyze runner usage, manage connections, and retrieve recommendations.
+---
+
+The GitHub Actions API gives your tools and agents organization-scoped access to Depot job operations, logs, analytics,
+runner recommendations, GitHub App connections, test-result summaries, and usage projections.
+
+Download the [OpenAPI specification](/openapi/depot-github-actions/v1.json) to generate a client or inspect every request
+and response field.
+
+## Authenticate requests
+
+Create an organization token in your [organization settings](/orgs/_/settings), then send it as a bearer token. Depot
+derives the organization from this token. A request can't select a different organization.
+
+```http
+Authorization: Bearer <DEPOT_TOKEN>
+```
+
+Responses don't include GitHub provider credentials.
+
+## List jobs
+
+Call Connect JSON methods at `https://api.depot.dev/<service>/<method>`. This request lists the 50 newest jobs for one
+repository:
+
+```bash
+curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobs \
+  -H "Authorization: Bearer $DEPOT_TOKEN" \
+  -H 'Connect-Protocol-Version: 1' \
+  -H 'Content-Type: application/json' \
+  --data '{"repositories":["acme/widgets"],"pageSize":50}'
+```
+
+Job and analytics queries default to the last 30 days and accept windows of up to 90 days.
+
+## Search logs
+
+Log queries default to the last hour and accept windows of up to 30 days. You can filter by repository, workflow,
+runner label, action, or compute ID.
+
+```bash
+curl https://api.depot.dev/depot.core.v1.GithubActionsService/SearchGithubActionsLogs \
+  -H "Authorization: Bearer $DEPOT_TOKEN" \
+  -H 'Connect-Protocol-Version: 1' \
+  -H 'Content-Type: application/json' \
+  --data '{
+    "query":"timeout",
+    "timeRange":{"startAt":"2026-09-17T00:00:00Z","endAt":"2026-09-18T00:00:00Z"},
+    "filters":{"repositories":["acme/widgets"]},
+    "pageSize":100
+  }'
+```
+
+Use `CountGithubActionsLogs` for a count, `ListGithubActionsLogFacets` to discover filter values, and
+`GetGithubActionsLogContext` with a returned `lineId` to fetch surrounding lines.
+
+## Analyze runner usage
+
+`GetGithubActionsAnalytics` returns job counts, failure rates, elapsed time, and billable time in hourly or daily buckets.
+`ListGithubActionsJobAnalytics` groups CPU, memory, duration, and failure metrics by job.
+
+```bash
+curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobAnalytics \
+  -H "Authorization: Bearer $DEPOT_TOKEN" \
+  -H 'Connect-Protocol-Version: 1' \
+  -H 'Content-Type: application/json' \
+  --data '{
+    "timeRange":{"startAt":"2026-09-17T11:00:00Z","endAt":"2026-09-17T12:00:00Z"},
+    "filters":{"repositories":["acme/widgets"]},
+    "pageSize":100
+  }'
+```
+
+`ListGithubActionsRecommendations` uses the same filters. It returns size-up recommendations when average CPU or memory
+utilization reaches 90%. It returns size-down recommendations when both averages stay at or below 30% and both peaks stay
+at or below 70%. These thresholds use rounded whole percentages, with no minimum job count.
+
+CPU and memory utilization for `ListGithubActionsJobAnalytics` and `ListGithubActionsRecommendations` is calculated per
+UTC day, matching the dashboard. For example, a request for 11:00 to 12:00 UTC calculates utilization from metrics for that entire UTC day.
+By default, both methods use metrics from the last 30 days.
+
+Job counts, durations, and failure rates use the exact requested time range. Recommendations use the daily utilization described
+above, so metrics outside a sub-day window can affect the recommendation.
+
+Recommendations preserve the runner's architecture, OS, and storage family. Size-down recommendations require both CPU and memory data.
+Workflow-path filters return duration and failure analytics, but no utilization or recommendations when telemetry cannot
+be attributed to that path.
+
+To compare periods, request analytics for each time range and calculate the difference. To rank jobs by average
+duration, page through `ListGithubActionsJobAnalytics` and sort by `averageDurationSeconds`.
+
+## Inspect job durations
+
+`GetGithubActionsDurationDistribution` returns the dashboard's duration buckets: `0-1m`, `1-5m`, `5-10m`, `10-20m`,
+`20-30m`, `30-60m`, and `>60m`. Each upper bound is inclusive. Zero-duration jobs and empty buckets are omitted.
+It accepts analytics filters, with `filters.jobs` matching job display names rather than workflow YAML keys.
+
+`ListGithubActionsJobRuns` returns completed runs for a repository and job display name, longest first. Use the `name`
+from `ListGithubActionsJobs` for `jobName`. Unlike the job list, both duration methods filter by finish time. This request
+retrieves runs that finished on one UTC day:
+
+```bash
+curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobRuns \
+  -H "Authorization: Bearer $DEPOT_TOKEN" \
+  -H 'Connect-Protocol-Version: 1' \
+  -H 'Content-Type: application/json' \
+  --data '{
+    "repository":"acme/widgets",
+    "jobName":"Run tests",
+    "timeRange":{"startAt":"2026-09-17T00:00:00Z","endAt":"2026-09-18T00:00:00Z"},
+    "pageSize":100
+  }'
+```
+
+Historical runs return an empty `jobId` when the GitHub identifier is unavailable. Results can change between pages as
+analytics are ingested.
+
+## Page through results
+
+When a response contains `nextPageToken`, pass it as `pageToken` with the same filters and time range. Page tokens are
+opaque and bound to both the authenticated organization and the original request.
+
+The `dataThrough` field tells you how current the response is. Jobs come from Depot's transactional store. Logs,
+analytics, recommendations, and test-result summaries can lag while telemetry is ingested.
+
+## Terminate a job
+
+`TerminateGithubActionsJob` requests termination of the Depot compute resource for a queued or running job. The method is
+idempotent and reports whether termination was requested, already requested, already terminal, or no active compute was
+found. It doesn't cancel the GitHub workflow run itself.
+
+## Manage GitHub connections
+
+Use `ListGithubActionsConnections` and `ListGithubActionsRepositories` to inspect the installations available to the
+organization. `CreateGithubActionsInstallationUrl` returns a signed URL that expires after 10 minutes. Open it in a
+browser to install the Depot GitHub App. `DeleteGithubActionsConnection` disconnects an installation.
+
+## Inspect tests and projected usage
+
+`GetGithubActionsTestResultsSummary` returns passed, failed, errored, skipped, and unknown test counts for a job. The
+response also includes the owner values you can pass to the Test Results API.
+
+`GetGithubActionsUsageProjection` returns actual and projected billable seconds for a billing window. Its cost estimate
+uses the published list rate and excludes discounts, credits, and custom pricing.
diff --git a/content/api/overview.mdx b/content/api/overview.mdx
@@ -12,6 +12,11 @@ The Depot APIs are collections of endpoints that grant access to the underlying
 
 [Depot CI](/docs/ci/overview) has its own API for working with workflows programmatically: dispatching and rerunning workflows, listing runs, checking status, fetching logs and metrics, retrying and cancelling jobs, and downloading artifacts. See the [Depot CI API reference](/docs/api/ci/reference) for all endpoints and examples.
 
+## GitHub Actions API
+
+Inspect Depot-managed GitHub Actions jobs and logs, retrieve CPU and memory analytics, generate runner-size recommendations,
+and manage GitHub App connections with the [GitHub Actions API](/docs/api/github-actions-api).
+
 ## Container Builds API
 
 Organizations can manage projects, acquire BuildKit endpoints, and run image builds for their applications or services programmatically. Depot provides the following SDKs for interacting with the Container Builds API:
@@ -28,8 +33,8 @@ If you're using the Container Builds API to build untrusted code, you need **one
 ## Sandbox API
 
 <NoteCallout variant="beta" title>
-  The Sandbox SDK is in private beta. Methods might change before the SDK becomes generally available. Sandboxes are
-  billed per vCPU-second at the Depot CI compute rate. [Contact us](/help) to request access for your organization.
+  The Sandbox SDK is in public beta. Methods might change before the SDK becomes generally available. Sandboxes are
+  billed per vCPU-second at the Depot CI compute rate.
 </NoteCallout>
 
 Run untrusted or agent-generated code in isolated, ephemeral sandboxes: create a sandbox, run commands and stream their output, and work with the sandbox file system through a `node:fs/promises`-shaped interface. Depot provides the following SDK for interacting with the Sandbox API:

diff --git a/content/api/sandbox-sdk-reference.mdx b/content/api/sandbox-sdk-reference.mdx
@@ -7,8 +7,8 @@ description: Complete Node.js SDK reference for creating sandboxes, running comm
 import {NoteCallout} from '~/components/blog/NoteCallout'
 
 <NoteCallout variant="beta" title>
-  The Sandbox SDK is in private beta. Methods might change before the SDK becomes generally available. Sandboxes are
-  billed per vCPU-second at the Depot CI compute rate. [Contact us](/help) to request access for your organization.
+  The Sandbox SDK is in public beta. Methods might change before the SDK becomes generally available. Sandboxes are
+  billed per vCPU-second at the Depot CI compute rate.
 </NoteCallout>
 
 The [`@depot/sandbox`](https://www.npmjs.com/package/@depot/sandbox) package is the Node.js SDK for Depot sandboxes. It wraps the `depot.sandbox.v1` API with ergonomic classes for creating sandboxes, running commands, streaming command output, and working with a sandbox's file system through a `node:fs/promises`-shaped interface. The source is on GitHub at [`depot/sandbox-sdk`](https://github.com/depot/sandbox-sdk).
@@ -94,10 +94,10 @@ const sandbox = await Sandbox.create(client, {
 Options (`CreateSandboxOpts`):
 
 - **name**: an optional name for the sandbox, unique within your organization.
-- **runtime**: the runtime to boot into. Custom runtimes aren't available in the beta. Sandboxes boot from Depot's pre-cached default base image.
+- **runtime**: the image to boot, specified as `{imageRef: '…'}`. Omit this option to use Depot's default base image. Named runtimes aren't supported.
 - **resources**: the compute to request, as `{vcpus?, memoryMb?, diskGb?}`, each a positive integer. The server fills a default for any field you omit: 2 vCPUs, 4096 MB of memory, and 100 GB of disk. Sandboxes support 2 to 64 vCPUs. Disk must be large enough to hold the base image, so very small values fail to start.
 - **env**: environment variables for the sandbox. The server merges these into every command it runs. When a command sets the same variable, the command's value wins.
-- **timeoutMinutes**: requested lifetime in minutes, measured from when the sandbox is created (including provisioning time). Defaults to 120 minutes. Our preview currently limits container lifetime to a maximum of 24 hours; please contact us to increase this limit.
+- **timeoutMinutes**: requested lifetime in minutes, measured from when the sandbox is created (including provisioning time). Defaults to 120 minutes. The maximum sandbox lifetime is 24 hours.
 
 ### Get a sandbox
 

diff --git a/content/cache/authentication.mdx b/content/cache/authentication.mdx
@@ -23,6 +23,7 @@ For specific details on how to configure your build tools to authenticate with D
 - [Bazel](/docs/cache/integrations/bazel)
 - [Go](/docs/cache/integrations/gocache)
 - [Gradle](/docs/cache/integrations/gradle)
+- [Nx](/docs/cache/integrations/nx)
 - [Pants](/docs/cache/integrations/pants)
 - [sccache](/docs/cache/integrations/sccache)
 - [Turborepo](/docs/cache/integrations/turbo)
diff --git a/content/cache/integrations/nx.mdx b/content/cache/integrations/nx.mdx
@@ -0,0 +1,112 @@
+---
+title: Configure Nx to use Depot Cache
+ogTitle: Configure Nx to use Depot Cache
+description: Learn how to use Depot remote caching for Nx builds
+---
+
+[**Nx**](https://nx.dev/) is a build system for monorepos with first-class support for task caching. Nx can share its task cache across machines using a remote cache, so that a task computed once on your laptop or in CI never needs to be re-run anywhere else.
+
+[**Depot Cache**](/docs/cache/overview) implements Nx's [self-hosted remote cache protocol](https://nx.dev/docs/guides/tasks--caching/self-hosted-caching), so Nx can store and retrieve task outputs from Depot Cache. This cache is accessible from anywhere, both on your local machine and on CI/CD systems.
+
+**Note:** You need a [Depot API token](/docs/cli/authentication) to authenticate with the cache service. Nx uses the `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` environment variable for authentication, which you should set to your Depot API token.
+
+## Local workstation
+
+Set two environment variables representing the Depot Cache service endpoint and your API token:
+
+```shell
+export NX_SELF_HOSTED_REMOTE_CACHE_SERVER=https://cache.depot.dev
+export NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN=<your-depot-api-token>
+```
+
+After you configure Nx to use Depot Cache, run your tasks as you normally would. Nx automatically communicates with Depot Cache to fetch and reuse any stored task outputs from your previous runs.
+
+Nx doesn't support sending custom headers to the remote cache, so it can't select an organization for a user token that belongs to multiple organizations. If you're a member of multiple organizations, authenticate with an [organization token](/docs/cache/authentication) instead.
+
+## Local workstation with containerized builds
+
+When building Docker images that run Nx tasks locally, your build needs access to Nx's remote cache credentials to benefit from caching. Containerized builds execute in isolated environments that require explicit configuration.
+
+### Dockerfile configuration
+
+Update your Dockerfile to configure Depot Cache and mount the token as a secret:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+
+# ... other Dockerfile instructions
+
+# Configure Depot Cache for Nx
+ENV NX_SELF_HOSTED_REMOTE_CACHE_SERVER=https://cache.depot.dev
+
+# Mount the token secret and run build
+RUN --mount=type=secret,id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN \
+    npx nx run-many -t build
+```
+
+Adding `# syntax=docker/dockerfile:1` as the first line of your Dockerfile enables mounting secrets as environment variables.
+
+### Depot CLI
+
+Set `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` to your Depot API token, then run the build:
+
+```shell
+depot build --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN -t your-image:tag .
+```
+
+### Docker buildx
+
+```shell
+docker buildx build --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN -t your-image:tag .
+```
+
+## Depot GitHub Actions runners
+
+[Depot GitHub Actions runners](/docs/github-actions/overview) are pre-configured to use Depot Cache with Nx. Each runner launches with `NX_SELF_HOSTED_REMOTE_CACHE_SERVER` and `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` environment variables that include the connection details for Depot Cache.
+
+You don't need additional configuration. Run your Nx tasks as normal:
+
+```yaml
+jobs:
+  build:
+    runs-on: depot-ubuntu-24.04
+    steps:
+      - uses: actions/checkout@v4
+      - run: npx nx run-many -t build
+```
+
+To disable automatic configuration, turn off **Allow Actions jobs to automatically connect to Depot Cache** in your organization settings page. You can then manually configure Nx as described in the Local workstation section.
+
+## Depot GitHub Actions runners with containerized builds
+
+When running containerized builds on Depot GitHub Actions runners, your build needs access to Nx's remote cache credentials. These credentials aren't automatically available inside your Docker build environment.
+
+### `depot/build-push-action`
+
+Store your Depot API token in a GitHub Secret named `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN`, then configure your workflow:
+
+```yaml
+- name: Build and push
+  uses: depot/build-push-action@v1
+  with:
+    context: .
+    file: ./Dockerfile
+    push: true
+    tags: your-image:tag
+    secrets: |
+      "NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN=${{ secrets.NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN }}"
+```
+
+### Docker CLI
+
+Store your Depot API token in a GitHub Secret named `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN`, then configure your workflow:
+
+```yaml
+- name: Build
+  run: |
+    docker buildx build \
+      --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN \
+      -t your-image:tag .
+  env:
+    NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN: ${{ secrets.NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN }}
+```