Depot

Name: Depot
Brand: Depot
Rating: 5 (3 reviews)

AI Native

Build software faster. Waste less time.

Est 2022|Raised $16.6M|6 Ref Customers

LinkedIn 3K|Web traffic 14K|FTEs 8|HQ Beaverton, OR

MarketsContinuous Integration & Continuous Delivery (CI/CD)Build Tools

Published Oct 6, 2026

01Common complaints

1. Organizations seeking a full, end-to-end CI/CD platform with integrated pipeline orchestration and analytics beyond runner and build acceleration — consider other CI platforms such as Buildkite. 2. Organizations that must keep all code, logs, caches, and build artifacts entirely within their own cloud account and minimize third-party control-plane dependencies — consider RunsOn or DIY self-hosted runners plus caching. 3. Organizations with strict enterprise requirements (SSO/SCIM, audit logs, static IPs, PrivateLink) that prefer not to engage in custom pricing or vendor-assisted enablement; these requirements are typically fulfilled via the Business tier. 4. Workloads that are not container/build-heavy (for example, simple scripted CI tasks) where measurable gains are likely to be limited. 5. Organizations that cannot tolerate external vendor outages affecting CI and do not maintain fallback runners or mitigations; the vendor has documented outages and is exposed to upstream dependencies.

Deal disqualifiers (poor fit)

Requirements for on-premise-only deployments with no external control plane interaction.
Need for a full CI platform (pipelines, artifacts, test analytics) rather than a built-for-purpose runner/build acceleration solution.
Extremely low CI volume where ROI for a new vendor is unlikely.

Known limitations (publicly documented)

Windows runners have documented limitations relative to Linux Ultra runners, such as the absence of a disk accelerator.

Roadmap / future work (signals)

The vendor has published work related to scaling, provisioning protections, and cache optimizations following incident investigations.

Scale limitations

A vendor postmortem described that extreme concurrency combined with autoscaling overwhelmed cache infrastructure; while mitigations were implemented, very large workloads should validate performance at expected peak concurrency.

Security/compliance gaps

SOC 2 Type I is documented by the vendor; SOC 2 Type II and ISO 27001 are not publicly documented. Buyers with strict compliance requirements should request certification documents and relevant reports during procurement.

API / integration constraints

Depot Managed deployments typically require coordination with the vendor and are not always fully self-serve; setup may require elevated AWS IAM roles and integration work.

02Why they buy

Features presented by the vendor as differentiated

- Command replacements to reduce build time for common workflows (for example, `depot build` as an alternative to `docker build`) and an option to use vendor-managed runner labels for GitHub Actions. - A remote, shared cache that supports multiple build tools (Bazel, Gradle, Turborepo, sccache, Pants), enabling incremental builds across developers and CI. - Depot Managed option to deploy parts of the data plane into a customer’s AWS account to address specific compliance or residency requirements. - Single-tenant ephemeral runner configurations intended to reduce noisy-neighbor effects in multi-tenant environments.

Areas where competitors have advantages

GitHub-hosted runners: simplest procurement and governance for GitHub-centric organizations; pricing changes in 2026 improved competitiveness.
RunsOn / DIY: stronger posture for keeping all runtime resources within the customer’s cloud account and potentially better unit economics at scale depending on workload.
Buildkite: a more complete CI platform for organizations that require pipeline orchestration and artifact/test analytics.

03Field reports

Review platform signal (G2)

Depot has a limited review volume on G2, consistent with early-stage vendors: relatively high satisfaction among initial adopters but limited broad review distribution. Selected review excerpts (verbatim where provided on G2): - A Staff DevOps wrote: "It just works, faster CI at lower cost" and emphasized simple setup (installing the GitHub App and changing a single line). - A Director of Software Engineering wrote: "Much faster builds for lower cost — it's a no-brainer" and described the service as stable and easy to implement. Critical notes from reviews: - Some reviewers described queue time or job start latency during onboarding; the vendor reported addressing onboarding issues in short order in at least one instance. - Some review listings on public platforms appear to reference different products with the same name, indicating product-name ambiguity on review platforms. Buyers should verify reviews are for the vendor’s offering specifically.

Capterra

Capterra lists the vendor but shows no rating or review summary at the time of research.

Community / social proof

Vendor marketing includes developer-attributed snippets claiming substantial build improvements; these are vendor-curated excerpts and should not be treated as representative independent sampling.

Why customers cite the product (themes)

From reviews and vendor materials, adoption drivers cited include:

Reduced build times for certain workloads without large codebase refactors.
Improved caching behavior across jobs and teams.
Multi-architecture builds with reduced emulation overhead.
Potential cost reduction compared with GitHub-hosted runner minutes for some workloads.

Why some customers might leave / churn (inferred)

Public churn narratives are limited. Based on typical CI tooling dynamics and vendor disclosures, likely churn drivers include:

Enterprise security or networking requirements that necessitate Business-tier features and custom pricing.
A preference to run all infrastructure within the customer’s own cloud account (favoring self-hosted or DIY solutions).
Reliability concerns if CI becomes dependent on a single external provider.

Vendor-published outcomes (examples)

Vendor materials and pricing pages include quoted outcomes such as faster build times and substantial cost reductions attributed to customer roles. Critical evaluation: - These outcomes are presented as testimonials without full methodological disclosure (e.g., build types, cache warm state, baseline runner sizes, workload mixes, time windows, or whether cost calculations included subscription and cache storage). - Large multipliers are plausible in specific scenarios (for example, when moving from emulation or poorly cached builds to native builders with a warm cache), but they should be considered best-case vendor-reported examples until validated under customer-specific workloads.

Operational transparency as a form of case study

The vendor’s incident write-up about build autoscaling failures provides insight into failure modes and mitigation steps. The write-up described a cache-cluster overload scenario and subsequent mitigations such as disabling a feature, scaling the cache cluster, and adding safeguards.

Buyer takeaway: the vendor publishes postmortems, which supports operational transparency, but these disclosures also indicate that high-volume workloads can expose platform constraints.

04Best fit

Company sizes (practical ranges)

5–200 engineers is likely the strongest practical fit: enough CI volume for potential ROI, but not so large that the organization prefers to own the entire stack.
Enterprises can also be a fit but typically require Business-tier features and a formal security review.

Industries / verticals

Suitable for any software-heavy organization with frequent releases, containerized deployments, and CI-heavy workflows.

Roles and personas

Decision makers: Head of Engineering, VP Engineering, Platform/Infrastructure leaders, DevOps leadership.
End users: developers performing local builds, CI maintainers, and release engineers.

Pain points addressed

Slow Docker builds, particularly for multi-stage builds and large dependency graphs.
Slow CI due to cache misses, limited cache bandwidth, or constrained runner performance.
High GitHub Actions spend driven by long job durations.

Qualification criteria (good fit)

Heavy usage of GitHub Actions with the ability to change runner labels.
Frequent Docker image builds that can use depot build.
Repeated cache misses or slow cache restores that impact build durations.

05The pitch

What the product does (objective)

Depot is a developer infrastructure platform focused on reducing build and CI latency. Key capabilities include: - Remote container builds (a drop-in replacement for `docker build` via `depot build`) using remote, high-CPU builders with persistent caching. - Managed GitHub Actions runners (a drop-in `runs-on` replacement) positioned by the vendor as faster than GitHub-hosted runners with fewer constraints (e.g., higher concurrency) and integrated caching. - Depot Cache: a remote, globally distributed caching service that can be used by multiple build tools (e.g., Bazel, Go, Gradle, Turborepo, sccache, Pants) to support incremental builds across local development and CI. The vendor states the product aims to reduce CI and build latency and to lower billed runner minutes by combining tuned compute resources with persistent caching and cache orchestration.

Target market and market positioning

- Target users: platform engineers, DevOps, build/release engineers, and development teams with material CI time or cost concerns. - Target organizations: startups through mid-market and enterprise (Business plan), particularly teams that: - build and push Docker images frequently; - run GitHub Actions at scale; - maintain multi-architecture builds where emulation slows builds. - Positioning (vendor messaging): the product is presented as an option intended to provide faster builds and lower billed runner minutes compared with GitHub-hosted runners and as a managed alternative to self-hosted BuildKit/buildx plus manual caching.

Get a comprehensive analysis of Depot including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 6, 2026

01Common complaints

Organizations seeking a full, end-to-end CI/CD platform with integrated pipeline orchestration and analytics beyond runner and build acceleration — consider other CI platforms such as Buildkite.
Organizations that must keep all code, logs, caches, and build artifacts entirely within their own cloud account and minimize third-party control-plane dependencies — consider RunsOn or DIY self-hosted runners plus caching.
Organizations with strict enterprise requirements (SSO/SCIM, audit logs, static IPs, PrivateLink) that prefer not to engage in custom pricing or vendor-assisted enablement; these requirements are typically fulfilled via the Business tier.
Workloads that are not container/build-heavy (for example, simple scripted CI tasks) where measurable gains are likely to be limited.
Organizations that cannot tolerate external vendor outages affecting CI and do not maintain fallback runners or mitigations; the vendor has documented outages and is exposed to upstream dependencies.

Deal disqualifiers (poor fit)

Requirements for on-premise-only deployments with no external control plane interaction.
Need for a full CI platform (pipelines, artifacts, test analytics) rather than a built-for-purpose runner/build acceleration solution.
Extremely low CI volume where ROI for a new vendor is unlikely.

Known limitations (publicly documented)

Windows runners have documented limitations relative to Linux Ultra runners, such as the absence of a disk accelerator.

Roadmap / future work (signals)

The vendor has published work related to scaling, provisioning protections, and cache optimizations following incident investigations.

Scale limitations

A vendor postmortem described that extreme concurrency combined with autoscaling overwhelmed cache infrastructure; while mitigations were implemented, very large workloads should validate performance at expected peak concurrency.

Security/compliance gaps

SOC 2 Type I is documented by the vendor; SOC 2 Type II and ISO 27001 are not publicly documented. Buyers with strict compliance requirements should request certification documents and relevant reports during procurement.

API / integration constraints

Depot Managed deployments typically require coordination with the vendor and are not always fully self-serve; setup may require elevated AWS IAM roles and integration work.

02Why they buy

Features presented by the vendor as differentiated

Command replacements to reduce build time for common workflows (for example, depot build as an alternative to docker build) and an option to use vendor-managed runner labels for GitHub Actions.
A remote, shared cache that supports multiple build tools (Bazel, Gradle, Turborepo, sccache, Pants), enabling incremental builds across developers and CI.
Depot Managed option to deploy parts of the data plane into a customer’s AWS account to address specific compliance or residency requirements.
Single-tenant ephemeral runner configurations intended to reduce noisy-neighbor effects in multi-tenant environments.

Areas where competitors have advantages

GitHub-hosted runners: simplest procurement and governance for GitHub-centric organizations; pricing changes in 2026 improved competitiveness.
RunsOn / DIY: stronger posture for keeping all runtime resources within the customer’s cloud account and potentially better unit economics at scale depending on workload.
Buildkite: a more complete CI platform for organizations that require pipeline orchestration and artifact/test analytics.

03Field reports

Review platform signal (G2)

Depot has a limited review volume on G2, consistent with early-stage vendors: relatively high satisfaction among initial adopters but limited broad review distribution.

Selected review excerpts (verbatim where provided on G2):

A Staff DevOps wrote: "It just works, faster CI at lower cost" and emphasized simple setup (installing the GitHub App and changing a single line).
A Director of Software Engineering wrote: "Much faster builds for lower cost — it's a no-brainer" and described the service as stable and easy to implement.

Critical notes from reviews:

Some reviewers described queue time or job start latency during onboarding; the vendor reported addressing onboarding issues in short order in at least one instance.
Some review listings on public platforms appear to reference different products with the same name, indicating product-name ambiguity on review platforms. Buyers should verify reviews are for the vendor’s offering specifically.

Capterra

Capterra lists the vendor but shows no rating or review summary at the time of research.

Community / social proof

Vendor marketing includes developer-attributed snippets claiming substantial build improvements; these are vendor-curated excerpts and should not be treated as representative independent sampling.

Why customers cite the product (themes)

From reviews and vendor materials, adoption drivers cited include:

Reduced build times for certain workloads without large codebase refactors.
Improved caching behavior across jobs and teams.
Multi-architecture builds with reduced emulation overhead.
Potential cost reduction compared with GitHub-hosted runner minutes for some workloads.

Why some customers might leave / churn (inferred)

Public churn narratives are limited. Based on typical CI tooling dynamics and vendor disclosures, likely churn drivers include:

Enterprise security or networking requirements that necessitate Business-tier features and custom pricing.
A preference to run all infrastructure within the customer’s own cloud account (favoring self-hosted or DIY solutions).
Reliability concerns if CI becomes dependent on a single external provider.

Vendor-published outcomes (examples)

Vendor materials and pricing pages include quoted outcomes such as faster build times and substantial cost reductions attributed to customer roles.

Critical evaluation:

These outcomes are presented as testimonials without full methodological disclosure (e.g., build types, cache warm state, baseline runner sizes, workload mixes, time windows, or whether cost calculations included subscription and cache storage).
Large multipliers are plausible in specific scenarios (for example, when moving from emulation or poorly cached builds to native builders with a warm cache), but they should be considered best-case vendor-reported examples until validated under customer-specific workloads.

Operational transparency as a form of case study

Buyer takeaway: the vendor publishes postmortems, which supports operational transparency, but these disclosures also indicate that high-volume workloads can expose platform constraints.

04Best fit

Company sizes (practical ranges)

5–200 engineers is likely the strongest practical fit: enough CI volume for potential ROI, but not so large that the organization prefers to own the entire stack.
Enterprises can also be a fit but typically require Business-tier features and a formal security review.

Industries / verticals

Suitable for any software-heavy organization with frequent releases, containerized deployments, and CI-heavy workflows.

Roles and personas

Decision makers: Head of Engineering, VP Engineering, Platform/Infrastructure leaders, DevOps leadership.
End users: developers performing local builds, CI maintainers, and release engineers.

Pain points addressed

Slow Docker builds, particularly for multi-stage builds and large dependency graphs.
Slow CI due to cache misses, limited cache bandwidth, or constrained runner performance.
High GitHub Actions spend driven by long job durations.

Qualification criteria (good fit)

Heavy usage of GitHub Actions with the ability to change runner labels.
Frequent Docker image builds that can use depot build.
Repeated cache misses or slow cache restores that impact build durations.

05The pitch

What the product does (objective)

Depot is a developer infrastructure platform focused on reducing build and CI latency. Key capabilities include:

Remote container builds (a drop-in replacement for docker build via depot build) using remote, high-CPU builders with persistent caching.
Managed GitHub Actions runners (a drop-in runs-on replacement) positioned by the vendor as faster than GitHub-hosted runners with fewer constraints (e.g., higher concurrency) and integrated caching.
Depot Cache: a remote, globally distributed caching service that can be used by multiple build tools (e.g., Bazel, Go, Gradle, Turborepo, sccache, Pants) to support incremental builds across local development and CI.

The vendor states the product aims to reduce CI and build latency and to lower billed runner minutes by combining tuned compute resources with persistent caching and cache orchestration.

Target market and market positioning

Target users: platform engineers, DevOps, build/release engineers, and development teams with material CI time or cost concerns.
Target organizations: startups through mid-market and enterprise (Business plan), particularly teams that:
- build and push Docker images frequently;
- run GitHub Actions at scale;
- maintain multi-architecture builds where emulation slows builds.
Positioning (vendor messaging): the product is presented as an option intended to provide faster builds and lower billed runner minutes compared with GitHub-hosted runners and as a managed alternative to self-hosted BuildKit/buildx plus manual caching.

Get a comprehensive analysis of Depot including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →