For questions, concerns, or information about our security policies or to disclose a security vulnerability, please get in touch with us at security@depot.dev.
A Depot organization represents a collection of projects that contain builder VMs and SSD cache disks. These VMs and disks are associated with a single organization and are not shared across organizations.
When a build request arrives, the build is routed to the correct builder VM based on organization, project, and requested CPU architecture. Communication between the depot CLI and builder VM uses an encrypted HTTPS (TLS) connection.
Cache volumes are encrypted at rest using our infrastructure providers' encryption capabilities.
A builder in Depot and its SSD cache are tied to a single project and the organization that owns it. Builders are never shared across organizations. Instead, builds running on a given builder are connected to one and only one organization, the organization that owns the projects.
Connections from the Depot CLI to the builder VM are routed through a stateless load balancer directly to the project's builder VM and are encrypted using TLS (HTTPS).
Our services and applications run in the cloud using one of our infrastructure providers, AWS and GCP. Depot has no physical access to the underlying physical infrastructure. For more information, see AWS's security details and GCP's security details.
All data transferred in and out of Depot is encrypted using hardened TLS. This includes connections between the Depot CLI and builder VMs, which are conducted via HTTPS. In addition, Depot's domain is protected by HTTP Strict Transport Security (HSTS).
Cache volumes attached to project builders are encrypted at rest using our infrastructure providers' encryption capabilities.
Depot does not access builders or cache volumes directly, except for use in debugging when explicit permission is granted from the organization owner.
Today, Depot operates cloud infrastructure in regions that are geographically located inside the United States of America as well as the European Union (if a project chooses the EU as its region).
Depot supports API-token-based authentication for various aspects of the application:
Depot keeps up to date with software dependencies and has automated tools scanning for dependency vulnerabilities.
Development environments are separated physically from Depot's production environment.
You can add and remove user access to your organization via the settings page. Users can have one of two roles:
We expect to expand the available roles and permissions in the future; don't hesitate to contact us if you have any special requirements.
In addition to users, Depot also allows creating trust relationships with GitHub Actions. These relationships enable workflow runs initiated in GitHub Actions to access specific projects in your organization to run builds. Trust relationships can be configured in the project settings.
Access to create project builds effectively equates to access to the builder VM due to the nature of how docker build works. Anyone with access to build a project can access that project's build cache files and potentially add, edit, or remove cache entries. You should be careful that you trust the users and trust relationships that you have given access to a project and use tools like OIDC trust relationships to limit access to only the necessary scope.
Each GitHub Actions job runs on a new EC2 instance that has never been used before, ensuring complete isolation at the hardware level. Once the job completes, we destroy the instance, maintaining a single tenant environment for each job.
GitHub Actions can integrate with Depot Cache, allowing you to store data in a cache service backed by S3. You have control over what gets stored in the cache, as you choose which items to mark for caching.
Cache entries stored in the Depot Cache are scoped by repository. Cache entries can only be read by the same repository that saved them. This prevents repositories from having key collisions when using the same cache key and ensures that one repository cannot unexpectedly read cache entries from another repository of a different trust level (like reading from or writing to a private repository from a public repository).
The same masking rules that apply in GitHub Actions are enforced in the runner environment. Any secrets you configure will be masked in the logs, preventing exposure. However, avoid hardcoding secrets in your codebase to prevent potential security breaches.