For questions, concerns, or information about our security policies, or to disclose a security vulnerability, please contact us at firstname.lastname@example.org.
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, and its SSD cache, in Depot is tied to a single project and the organization that owns that project. Builders are never at any point in time shared across organizations. Builds running on a given builder are tied 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).
All of our services and applications run in the cloud using one of our infrastructure providers, AWS and Fly.io. Depot has no physical access to the underlying physical infrastructure. For more information, see AWS's security details or Fly.io'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. 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.
User passwords are cyrptographically hashed and salted using bcrypt before being stored in our database.
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 all cloud infrastructure in regions that are geographically located inside the United States of America.
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 are able to 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, please contact us if you have any special requirements.
In addition to users, Depot also allows creating trust relationships with GitHub Actions. This allows workflow runs initiated in GitHub Actions to access specific projects in your organization, for the purposes of running builds. Trust relationships can be configured in the project settings.
Access to create project builds effectively equates to access on 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 could 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.