Depot (W23) | Multiple openings | Remote (North America, Europe) | Full-time

Depot is the fastest place to build software. We accelerate builds for customers using GitHub Actions, Docker, Bazel, Gradle, and more. We're seeking the following roles:

- Solutions Engineer ($120k-$150k)

- Developer Marketer focused on Community & Events ($100k-$130k)

- Technical Content Writer ($90k-$110k)

We offer a fully remote working environment anywhere in North America and Europe with competitive salaries and equity.

For more details, and to apply: https://depot.dev/careers

Founder of Depot here. Looks like Blacksmith was inspired by our implementation from last May and wrote a similar post to ours here.

To help reduce the confusion for other visitor to this post, you might want to email the HN mods to add (2024) to the title .

This will make it clear that you guys built the prior art that Blacksmith took inspiration from.

Yeah this is a great point. Thank you for adding this. I didn’t post this but will try to flag up the chain.

Fun to see folks replicating what we’ve done with Depot for GitHub Actions [0]. Going as far as using a similar title :)

Forking the ecosystem of actions to plug in your cache backed isn’t a good long term solution.

[0] https://depot.dev/blog/github-actions-cache

This reads less like an article about the downsides of Docker and more like an article about how someone doesn’t fully understand Docker.

Not that I think Docker should always be used. It’s a simple piece tech on the surface but explodes in complexity the more complicated you try to get.

All that said, this article feels detached from reality.

Glad this got posted. It's an excellent article from the Wiz team.

GitHub Actions is particularly vulnerable to a lot of different vectors, and I think a lot of folks reach for the self-hosted option and believe that closes up the majority of them, but it really doesn't. If anything, it might open more vectors and potentially scarier ones (i.e., a persistent runner could be compromised, and if you got your IAM roles wrong, they now have access to your AWS infrastructure).

When we first started building Depot GitHub Actions Runners [0], we designed our entire system to never trust the actual EC2 instance backing the runner. The same way we treat our Docker image builders. Why? They're executing untrusted code that we don't control.

So we launch a GitHub Actions runner for a Depot user in 2-5 seconds, let it run its job with zero permissions at the EC2 level, and then kill the instance from orbit to never be seen again. We explicitly avoid the persistent runner, and the IAM role of the instance is effectively {}.

For folks reading the Wiz article. This is the line that folks should be thinking about when going the self-hosted route:

> Self-hosted runners execute Jobs directly on machines you manage and control. While this flexibility is useful, it introduces significant security risks, as GitHub explicitly warns in their documentation. Runners are non-ephemeral by default, meaning the environment persists between Jobs. If a workflow is compromised, attackers may install background processes, tamper with the environment, or leave behind persistent malware.

> To reduce the attack surface, organizations should isolate runners by trust level, using runner groups to prevent public repositories from sharing infrastructure with private ones. Self-hosted runners should never be used with public repositories. Doing so exposes the runner to untrusted code, including Workflows from forks or pull requests. An attacker could submit a malicious workflow that executes arbitrary code on your infrastructure.

[0] https://depot.dev/products/github-actions

Thank you for the kind words. We’re always trying to share our knowledge even if Depot isn’t a good fit for everyone. I hope the scripts get some mileage!

This is what we focus on with Depot. Faster builds across the board without breaking the bank. More time to get things done and maybe go outside earlier.

Trading Strategy looks super cool, by the way.

This is a neat idea that we should try. We've tried the `eatmydata` thing to speed up dpkg, but the slow part wasn't the fsync portion but rather the dpkg database.

Founder of Depot here. For image builds, we’ve done quite a bit of optimization to BuildKit for our image builders to make certain aspects of the builds fast like load, cache invalidations, etc.

We also do native multi-platform builds behind one build command. So you can call depot build —platform Linux/amd64,linux/arm64 and we will build on native Intel and ARM CPUs and skip all the emulation stuff. All of that adds up to really fast image builds.

Hopefully that’s helpful!

Just flagging that Depot now has macOS and Windows runners [0] as well if you're looking for even faster builds. I also recognize that constantly reevaluating runners isn't on everyone's priority list.

[0] https://depot.dev/docs/github-actions/runner-types