Skaffold’s default concurrency for building images is one at a time, but you can build them in parallel.
Let’s see Skaffold build in action. Imagine you have a skaffold.yaml like this:
apiVersion: skaffold/v2beta29
kind: Config
build:
artifacts:
- image: my-app-1
docker:
dockerfile: Dockerfile.app1
- image: my-app-2
docker:
dockerfile: Dockerfile.app2
- image: my-app-3
docker:
dockerfile: Dockerfile.app3
local: {}
deploy:
kubectl: {}
And you run skaffold build. By default, Skaffold will build my-app-1, then my-app-2, then my-app-3, sequentially. If each of those builds takes 5 minutes, your total build time is 15 minutes.
Now, let’s make it parallel. You can configure the concurrency setting within the build section of your skaffold.yaml:
apiVersion: skaffold/v2beta29
kind: Config
build:
concurrency: 3 # Or any number you want to try
artifacts:
- image: my-app-1
docker:
dockerfile: Dockerfile.app1
- image: my-app-2
docker:
dockerfile: Dockerfile.app2
- image: my-app-3
docker:
dockerfile: Dockerfile.app3
local: {}
deploy:
kubectl: {}
With concurrency: 3, Skaffold will attempt to build all three images simultaneously. If your machine has enough resources (CPU, memory, disk I/O), and the Docker daemon can handle multiple builds, you could see a significant reduction in total build time. If each build still takes 5 minutes, but they run in parallel, your total build time could be closer to 5 minutes (plus a small overhead for coordination).
The concurrency setting directly controls how many builders Skaffold can run at the same time. Skaffold manages a pool of builders, and each builder is responsible for taking an artifact from your skaffold.yaml and executing the build process (e.g., docker build). When concurrency is set to N, Skaffold will start up to N builders. As soon as one builder finishes, Skaffold assigns it the next available artifact to build, up to the concurrency limit.
The actual number you should set for concurrency depends heavily on your system’s resources. A common starting point is to match the number of CPU cores on your machine. If you have 8 CPU cores, trying concurrency: 8 is a reasonable experiment. You might find that slightly more or fewer than your CPU count yields the best results, depending on whether your builds are CPU-bound, I/O-bound, or memory-bound. Too high a concurrency can lead to resource contention, slowing everything down.
Beyond just building, Skaffold’s dev loop also benefits from this. When you run skaffold dev, Skaffold will build images in parallel, then deploy them. If you have multiple microservices, and each requires a separate image build, parallelizing these builds can dramatically shorten the time it takes for your development environment to become ready after a code change.
The most surprising thing about concurrency is that it doesn’t just apply to Docker builds. If you’re using Jib, Bazel, or any other build tool configured in Skaffold, the concurrency setting will manage parallel execution for those as well, provided the underlying build tool can handle parallel execution. Skaffold abstracts away the specifics of the build process and focuses on orchestrating them concurrently.
When Skaffold builds images, it tags them with a unique digest or tag based on the build context (source code, Dockerfile, etc.). If you set a concurrency value, Skaffold will spin up multiple builder processes, each responsible for one artifact. These builders will all interact with your local Docker daemon (or whichever builder backend you’ve configured). The builder processes themselves are lightweight, but the actual build operations (e.g., docker build) consume significant CPU, memory, and disk I/O. Skaffold ensures that no more than concurrency build operations are active simultaneously.
One aspect that often trips people up is that Skaffold doesn’t automatically detect optimal concurrency. You have to experiment. If you set concurrency: 10 on a machine with only 4 cores, you’re likely to see performance degrade as the system spends more time context-switching between processes than actually building. The trick is to find the sweet spot where all your cores are busy but not thrashing.
If you’re using skaffold dev and have multiple services, you might find that after you fix your build concurrency, your deployments start failing.