[kylegalbraith]

Thank you for sharing your experience and trying Depot out!

We currently charge on a per project basis as behind the scenes we are provisioning and maintaining a VM with a persistent SSD cache for each architecture you are building for (i.e. Intel & Arm). We switched to usage based pricing before rolling Depot out to the public so you are only charged for your active projects and used build minutes in a month. So far it has seemed to be working well, but we are always open to feedback and ideas on how we can make pricing better.

We don't currently document this, and we probably should, but it's entirely possible to use a single Depot project for multiple Docker images. There is no limitation that prevents this and the only downside is you may fill up your cache space at a faster rate and get fewer hits if you have different image builds clobbering the cache.

[Aeolun]

> behind the scenes we are provisioning and maintaining a VM with a persistent SSD cache

How does this work if I have 5 builds for a single project at the same time?

In our current setup it takes a bit longer to boot, but concurrency is effectively unlimited. I don’t imagine that is true for Depot?

[kylegalbraith]

Thank you for the question!

We don't limit concurrency on the builder VMs. When you create a project you are effectively getting a dedicated build VM with a persistent SSD cache for each architecture you want to build for. We run native BuildKit on the VM and connect your `depot build` directly to the builder instance via mTLS. So your concurrency is unlimited with Depot as well (or at least as unlimited as BuildKit will allow for).