Zip, git URL or container image: time from code to live for the same app, measured

There are three common ways to hand a host your code: upload a zip, point it at a git URL, or push a container image. We deployed the same two open-source apps each way, on a fresh host every time, and timed each step until the first 200 response. We ran 48 deploys in the main test, and the choice of path changed the total by much less than we expected.

Short version: on the Java app the build took 191 s of a 198 s first deploy, about 97%, and every path needed that build somewhere. Moving the code took under 5 s here. What does differ is where the build runs and how many bytes travel: a zip of the Java app was 529 KB, its image 175 MB. On a repo with a long history, a shallow clone also matters: Django took about 95 s to clone in full and 6 s shallow.

What we deployed

Each path ran three rounds, and each round started from a new Docker host with an empty cache, so a first deploy also downloads the base images and every dependency. The second deploy in each round adds one comment line to a source file and goes through the same path again. Tables show medians.

The hosts were Docker 29 containers on one Windows PC running Docker Desktop on WSL2, with 6 CPUs and 11.7 GB. Git clones came from GitHub over our real connection. The zip copy and the image push and pull only crossed a local Docker network, because we had no second site to send them from. So the transfer times for those two are a best case, and we work out real link times from their sizes further down.

First deploy

"Move the code" adds up the steps before the build: pack, copy and unzip for a zip, the clone for git, and push plus pull for an image. The pull includes unpacking layers, which is probably why it takes longer than the push here. Start to first 200 runs from docker run until the app answers, and it depends on the runtime, not on the path. We looked at that separately in Cold starts measured.

Across the four paths the Java totals only ran from 197 to 201 s and the Python totals from 28 to 32 s. The rounds of a single path varied by several seconds, so we wouldn't rank the paths on those gaps.

After a one-line change

The Python app drops to about 3 s because its install layer stays cached and only the last steps rerun. The Java app still takes about 96 s: this Dockerfile copies everything before mvn package, so any change makes Maven download its dependencies and build again, on every path. That's a Dockerfile matter, not a deploy path matter. We measured the fix in Rebuild time when only your code changes.

One caveat on these rebuilds: a host that keeps its build cache gets them. A host that starts clean for each deploy pays the first-deploy build every time.

Bytes on the wire

This is where the paths really do differ. The sizes below are measured. The times are simple arithmetic at 100 Mbit/s (12.5 MB/s), not measurements, with no allowance for protocol overhead.

The last Java figure took an extra run. In the main test the Java image came out unchanged after the edit: a comment doesn't alter the compiled code, and the registry received 0 new bytes. That would flatter the image path, so we also deployed a change that reaches the jar, one extra line in a properties file. That pushed 59.5 MB of the 175 MB image, because the Spring Boot jar is a single layer, dependencies included. It was one run, but the size is the point there. Spring Boot's own docs call one layer not optimal and show how to split the dependencies out.

An image also travels twice: once from the build machine to the registry, and once from the registry to the host. A zip of source goes one way, but it's small only if it's clean. Ours came from git archive. A zip of a working folder with dependencies is another matter, as we measured in What a missing .dockerignore costs.

Full or shallow clone

On our two test apps the gap is small, about 3.2 s on Java. Their histories are short. So we also cloned django/django, which has 35,081 commits on main, three times each way:

A deploy only needs the files of one commit, so the history is overhead unless the build asks for it. Git's clone documentation notes that --depth already implies --single-branch; we pass both to make the intent plain. Check your build first: anything that runs git describe or counts commits for a version number sees only one commit of history.

Where the build runs

The totals hide what may be the bigger difference. With a zip or git, the host does the build: the Java app used it for about 191 s, downloading dependencies and compiling. With an image, the host only pulled and started, about 9.5 s here on a local network. The build still took 190 s, only on another machine.

Our reading, as opinion rather than measurement: for one app on one host, pick whichever is easiest, because the clock won't decide it. Use a shallow clone if you deploy from git, and keep zips clean. An image starts to earn its extra machinery when several hosts run the same version, when you want to roll back to the exact bytes you ran, or when the host is too small to run your build.

What this test doesn't show

It's one machine, where the deploy hosts and the build machine shared 6 CPUs, so a larger builder would shorten the builds and a remote host would lengthen the zip and image transfers. One Java deploy failed on a Docker Hub timeout, so we discarded that pair and repeated it; the failure stays in our raw log and out of the medians. We didn't test private repositories, automatic deploys on push, a registry-backed build cache or the time to switch traffic, all of which change the picture. The apps are small samples of their runtimes: a Python app with heavier dependencies would spend longer in its first build.

Sources (read 3 Nov 2026): git clone documentation and Spring Boot's efficient container images page. All timings and sizes are our own, from the setup above.