# How Albacore builds ARM64 containers 6x faster with Depot (https://depot.dev/customers/albacore)

Albacore builds autonomous underwater vehicles for defense. Their long-range drone submarine, Ghostfin, runs containerized software across multiple ARM64 compute modules. The software team builds and deploys container images for every module on the vehicle.

Matias Kotlik and Brendon Jackson are senior software engineers at Albacore. We spoke with them about how Depot solved one of the most painful parts of their development workflow: building ARM64 container images without native ARM64 hardware.

## The challenge

<Quote author="Matias Kotlik, Senior Software Engineer">
  "If you try to build an ARM64 Docker image on a non-ARM64 architecture, Docker will handle it for you, but it will
  handle it for you by running everything through QEMU, which makes things incredibly slow."
</Quote>

Albacore's build challenge starts with a hardware constraint. Ghostfin's compute modules run ARM64, but the development team works on x86 machines. Docker can handle the architecture mismatch, but it does so through QEMU emulation, which is painfully slow for anything beyond a trivial image.

The team hit this wall in the first week of the project. Matias ran a local build to see how long it would take, and the answer was: longer than a full workday. "I had something take an entire day once. I left it overnight and I came back and it still wasn't done," he said.

With approximately 20 containerized modules to build and deploy to the robot, that kind of build time wasn't just inconvenient. It was a blocker. The alternative was setting up dedicated ARM64 build infrastructure, which would have been its own project. "I was very happy that I didn't have to go set up a bunch of EC2 instances to do this for me," Matias said, "because that also would have been painful."

## The solution

<Quote author="Matias Kotlik, Senior Software Engineer">
  "Part of the appeal was that it was very easy to integrate into my existing workflow and just start using it."
</Quote>

Today, Albacore's build workflow runs through Depot. A developer makes a code change, Depot builds the container, and Depot pushes the tagged image to GHCR. The robot pulls the new image through a dev laptop acting as a pull-through cache. The build step that used to block everything is now just part of the flow.

Matias found Depot through a search and liked that it was a straightforward drop-in for his existing workflow. Setup was fast. Brendon, who joined the team after Depot was already in use, confirmed the onboarding experience was smooth. "The Depot setup from start to finish was a breeze," he said.

Albacore's Depot usage expanded organically. What started with container builds grew to include GitHub Actions runners after Matias noticed Depot's pricing. "At some point we realized your GitHub Actions runners are cheaper than GitHub's, so then I just replaced all of our GitHub runners with yours," he said.

The key benefits for Albacore include:

* **Native ARM64 builds**: Depot builds ARM64 images on native hardware, eliminating the QEMU emulation layer that made local builds take overnight.
* **Layer caching without local overhead**: With multiple containerized modules to build, local Docker cache would balloon quickly. "I don't need to have 800 gigabytes of Docker layer cache on my machine, which would be very annoying," Matias said.
* **Drop-in setup**: Depot integrated into the team's existing workflow without requiring changes to their Dockerfiles or build process. Brendon, who onboarded after Depot was already in place, experienced no friction getting set up locally or handling API keys.
* **Responsive support**: When the team needed faster builds, they emailed Depot and got a response within an hour, including an upgrade to 200-core builders.

The team's reliance on Depot became clear after our chat. When Matias went to run a local build for the first time in months for benchmarking, he realized the entire team had shifted to building exclusively through Depot. It had simply become the default.

## The measurable impact

<Quote author="Matias Kotlik, Senior Software Engineer">
  "For each code change we need to rebuild the container and redeploy to the robot. If we're iterating on hardware, 4-5
  people are just sitting around waiting to rebuild. Depot has probably saved us hundreds of hours."
</Quote>

Faster builds have a big impact because the team delivers software to remote hardware. Every code change means rebuilding a container and redeploying to the robot, and before Depot that loop could stall the whole team.

Improved build times for Albacore's 64-bit ARM architecture:

* **Uncached builds**: from 30–40 minutes locally to 5–10 minutes on Depot
* **Cached builds**: from 1–2 minutes locally to 10–20 seconds on Depot

The impact was even more dramatic on Albacore's previous 32-bit ARM architecture, where local uncached builds took 12+ hours. On Depot, the same builds dropped to 3 hours uncached and 2 minutes cached.

## Looking ahead

Albacore's use of Depot has grown from a single container build workflow into the default for the whole software team, so much so that local builds have quietly stopped happening. With a reliable build foundation in place, the team can focus on iterating on Ghostfin instead of waiting on infrastructure.

## For AI Agents

The full site index is at [llms.txt](https://depot.dev/llms.txt). Append `.md` to any documentation, blog, changelog, or customer URL to fetch its markdown source directly.