Update docs content from https://github.com/depot/app

Author: andie787

content/cache/integrations/sccache.mdx

@@ -90,15 +90,18 @@ DEPOT_TOKEN=your_token depot bake
 
 [Depot GitHub Actions runners](/docs/github-actions/overview) are pre-configured to use Depot Cache with sccache. Each runner launches with a `SCCACHE_WEBDAV_ENDPOINT` environment variable pre-configured with the connection details for Depot Cache.
 
-You don't need additional configuration. Run your sccache builds as normal:
+Tell Rust to compile via sccache, and run your sccache builds as normal:
 
 ```yaml
 jobs:
   build:
     runs-on: depot-ubuntu-24.04
     steps:
       - uses: actions/checkout@v4
-      - run: sccache --start-server && cargo build --release
+      - uses: mozilla-actions/[email protected]
+      - run: cargo build --release
+        env:
+          RUSTC_WRAPPER: 'sccache'
 ```
 
 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 sccache as described in the Local workstation section.

content/cache/overview.mdx

@@ -27,6 +27,17 @@ Supported build tools can be configured to use Depot Cache, so that they store a
 
 This speeds up your builds and tests by orders of magnitude, especially for large codebases, as those builds and tests become incremental. Instead of always having to rebuild from scratch, only the parts of your codebase that have changed are rebuilt, and only affected tests are re-run.
 
+### Cache retention policy
+
+The default cache retention policy is to store the cache entries for 14 days with no limit on total cache size.
+
+Configure the cache retention policy on your organization's [settings page](/orgs/_/settings) to control time based retention and cache size limits.
+
+- Available values for time based retention: 7 days, 14 days (default), 30 days
+- Available values for size based retention: 25 GB, 50 GB, 100 GB, 150 GB, 250 GB, 500 GB, No limit (default)
+
+**Note:** Retention policy settings don't apply to Docker layer cache entries (shown as type `docker` in the [Cache Explorer](/orgs/_/cache)). To manage Docker cache retention, set cache policy per [project](/orgs/_/projects) in project Settings.
+
 ## Where can I use Depot Cache?
 
 Depot Cache is accessible anywhere you run your builds, in local development or from any CI/CD system. Additionally, all supported tools are pre-configured to use Depot Cache when using [Depot GitHub Actions Runners](/docs/github-actions/overview).
@@ -35,8 +46,4 @@ This means that build artifacts are shared between different members of your tea
 
 ## Pricing
 
-Depot Cache is available on all of our pricing plans. Each plan includes a block of cache storage. Each additional GB over the included amount is billed at **$0.20/GB/month**. See our [pricing page](/pricing) for more details.
-
-## Cache Retention
-
-Depot Cache retains build artifacts for a configurable amount of time. By default, artifacts are retained for 14 days. You can configure this retention period in the Depot Cache settings.
+Depot Cache is available on all of our pricing plans. Each plan includes a block of cache storage. Each additional GB over the included amount is billed at $0.20 per GB of usage. We calculate usage by taking a snapshot every hour and then averaging out those snapshots over the month. For more information about plans and included usage, see the [pricing page](/pricing).

content/cli/reference.mdx

@@ -8,7 +8,7 @@ Below is a reference to the `depot` CLI, including all config, commands, flags,
 
 ## Specifying a Depot project
 
-Some commands need to know which [project](/docs/core-concepts#projects) to route the build to.
+Some commands need to know which [project](/docs/container-builds/overview#projects) to route the build to.
 
 For interactive terminals calling [`build`](#depot-build) or [`bake`](#depot-bake), if you don't specify a project, you will be prompted to choose a project when using an interactive prompt and given the option to save that project for future use in a `depot.json` file.
 

content/container-builds/overview.mdx

@@ -8,7 +8,7 @@ import {CheckCircleIcon} from '~/components/icons'
 import {DocsCTA} from '~/components/blog/CTA'
 import {FAQSection, FAQItem} from '~/components/blog/FAQ'
 
-Building a Docker image using Depot is up to [40x faster](https://depot.dev/benchmark/posthog) than on your local machine or CI provider. See a live benchmark.
+Building a Docker image using Depot is up to 40x faster than on your local machine or CI provider. See a live [benchmark](https://depot.dev/benchmark/posthog).
 
 At a high level, here's what happens when you run `depot build`:
 

content/core-concepts.mdx

@@ -0,0 +1,52 @@
+---
+title: Use egress filters for GitHub Actions runners
+ogTitle: How to configure egress filtering for your Depot GitHub Actions runners
+description: Learn how to configure egress filtering rules to control which external services your GitHub Actions runners can connect to.
+---
+
+Configure egress filtering to control which external services your GitHub Actions runners can connect to by blocking or allowing connections at the network level. Egress filtering helps prevent data exfiltration and reduces the attack surface of your CI infrastructure.
+
+### Configuration
+
+Configure egress rules on your organization's [settings page](/orgs/_/settings), in the **GitHub Actions Runners** section under **Egress Rules**.
+
+By default, Depot runners allow outbound connections to any external service. You can set the default rule (target `*`) to either `Deny` or `Allow`. You can add more rules to allow or deny connections to specific IPs, CIDRs, or hostnames.
+
+The following example shows a set of rules to get a Docker build with Golang working:
+
+[![A screenshot of the egress filter rules settings in use](/images/egress-filter-rules.webp)](/images/egress-filter-rules.webp)
+
+This example first applies a blanket deny rule, which blocks all outbound connections by default. Then, it allows connections to the following:
+
+- `auth.docker.io` and `docker.io` for Docker Hub authentication and registry access
+- `sum.golang.org` and `proxy.golang.org` for Go modules and proxy access
+- `storage.googleapis.com` for Google Cloud Storage access
+
+### How the runner applies the rules
+
+The runner applies the filtering rules in the following order:
+
+1. Allow all loopback traffic (127.0.0.1, ::1) to prevent breaking localhost services.
+2. Apply Deny rules: denied IPs and CIDR blocks take precedence.
+3. Apply Allow rules: explicitly permitted IP addresses and CIDR blocks.
+4. Apply the default policy (ALLOW or DENY) to all other traffic.
+
+When you specify a hostname in your rules, it's resolved to IP addresses and pinned in `/etc/hosts` to ensure consistent filtering.
+
+### Pre-configured rules
+
+To ensure that runners can still connect to necessary services, we automatically add certain IPs and hosts to the allowlist:
+
+- depot.dev domains
+- GitHub Actions service IPs
+- AWS service IPs
+
+Container builds with `depot build` also work with egress filtering enabled. Depot dynamically adds BuildKit machine IPs to the allowlist as they're allocated.
+
+### Limitations
+
+Keep the following limitations in mind when you use egress filtering:
+
+- You can't use Tailscale with egress filters because each modifies the network config in incompatible ways.
+- Any process with root access can modify the egress filter rules. Ensure that untrusted processes don't run with higher privileges than necessary.
+- The egress filter is currently supported only on Linux runners.