Depot remote builders becoming the default

Fresh Produce
1

Hey all! Your builds are about to become more performant and reliable, thanks to our partnership with Depot.

Over the next week, your Fly deployments will be migrated to Depot’s Fly-hosted remote builder platform. When your account has switched over, you’ll see that your build starts with Waiting for Depot builder.

Since we announced support for building with Depot, we’ve been working with the Depot team to iron out bugs and lay the foundation for features. We’re confident that Depot’s remote builders are ready for prime time.

If you’re having issues with this change, get in touch with support or post on this thread. Also, you can continue to use Fly’s standard remote builders with fly deploy --depot=false.

What’s better about Depot builders?

Here’s a recap from the Depot beta annoucement:

  • Your hot build cache sticks around longer, given Depot’s ability to more intelligently evict unused artifacts/layers
  • A new app-scoped build option allows for more secure builds when using tokens scoped to specific apps
  • Depot optimized Docker’s build engine, Buildkit, offering general build speed improvements
  • Fly support (and soon, you) gets visibility into your build instrumentation to assist you with debugging and performance profiling

How about build security?

Like Fly builders, Depot builders are ephemeral. Their access credentials are rotated on every build. Builders are isolated from the internet and only accept requests from Depot’s authenticated proxy. Builds may only be initiated with single-use build tokens supplied to Flyctl from our backend.

Builds run inside Depot’s Fly.io organization, but Depot has no access to your account information, email address, etc.

Does this cost anything?

For now, remote builds stay free. This change won’t cost you anything.

But, some weeks after the Depot migration is complete and verified, we’ll offer a free allowance of 300 build minutes per month. After 300 minutes, we’ll bill you $0.05 per build minute.

Around that time, we’ll likely stop supporting the standard Fly remote builder.

What’s next?

Apart from more reliable builds, this change unlocks exciting future work. Let us know if you’re interested in any of the following:

  • Pricing for larger builders and cache sizes
  • Shared cache across multiple builders, even while running simultaneous builds (think fast, region-local builds)
  • Enhancing the release+build UI in the Fly dashboard with Depot build instrumentation
  • GPU support
7 Likes
2

So no more standart build means no more flyio free build.
You could keep, at least, hobby plan build free since it’s for side projects, test environment or just learning…

2 Likes
3

This is fair comment…

300 build minutes is a lot, though. That’s on the order of 100 builds per day, on average, given my own tests (with optimized multi-stage builds).

(I’m wondering more about the aspect of a second organization now having access to the source code, etc., myself.)

(It’s not precisely anonymous, given the “Copyright (c) Evilcorp, secret new arbitrage strategy” gigantic header blocks…)

1 Like
4

I still got this error when using depot builder

1 Like
5

Is there a way to see our historical builder usage to see where it is relative to the 300min/month allowance?

6

My point is, no more build as a Flyio free feature. And who is building for -side projects, test environment or just learning- could builds a lot.

7

Right, this is the part I was saying is a fair and correct observation.

Here we might disagree, in terms of policy implications rather than initial facts. Overall, Fly.io needs to rein in their unbounded costs; this is important for future planning—on both sides. People who were putting off Dockerfile optimization to another day now have ample (but not extreme) motivation to do so in the next couple months (as opposed to “someday”). And those who were wondering whether the Fly.io platform is a safe choice in the long term have additional reasons for confidence in that regard.

Those builder machines are huge, and it’s in everyone’s overall interest if they’re apportioned more carefully.

I share your interest in the educational side, however. An HN comment by the author of a recent Fly blog post teased the possibility of having a new class of free accounts for that purpose, and perhaps those will have more leniency in the build component—as well.

3 Likes
8

Nice!

Will there be any best practices for Rails, Elixir, etc apps to fully utilize Depot build caches to improve deploy speed?

Will there be an option to use your own builder (Github Actions maybe?) and skip Depot?

9

You can already do this by deploying with fly deploy -i yourimage. Here’s a guide from one of our users.

2 Likes
10

Not now, but we’ll expose usage in the dashboard before actual billing starts. Generally, we’ve given a month runway to start real billing, during which your usage and estimated costs are visible.

3 Likes
11

Both dockerfile-rails and dockerfile-node have a --cache option. To use, simply regenerate your dockerfile using one of:

bin/rails generate dockerfile --cache
npx @flydotio/dockerfile --cache

Over time, this ability can be added for other frameworks.

2 Likes
12

Hey all :wave: I’m one of the founders of Depot and am super excited to be launching this!

We’ll be working with everyone at Fly on the rollout / fixing any issues that arise and continuing to work on what’s next.

I also want to mention that we have written a few guides and blog posts about Dockerfile optimizations that may be useful, if anyone is looking to further improve build times, caching, and image size:

8 Likes
13

Does this mean it’s no longer in beta?

What does the support story look like?

Will fly.io be completely responsible for all issues?

Is fly subcontracting depot on behalf of fly customers or is it considered another extension?
Whats the regulatory impact of this change (e.g. GDPR)?

4 Likes
14

Yes, it’s out of beta. Fly.io is your first line of support. We’ll engage with Depot on your behalf and take responsibility for resolution of issues.

Fly is subcontracting, therefore Depot is considered a subprocessor.

I’m not very familiar with the GDPR implications. But my understanding is that without sharing PII/PHI, Fly is still ultimately responsible for reaches to things like GDPR. I’ll check to get more details on this.

3 Likes
15

Hello, I have been having some issues due to this change. Namely, fly deploy has been failing with app does not have a Dockerfile or buildpacks configured. on all of my projects that use Paketo golang buildpacks:

image
image1429×443 115 KB

fly deploy --depot=false works, but since it will stop being supported in the future, I thought I would ask about this here. Is there any solution to this problem?

16

I’m unable to build with normal fly deploy command, getting the following error:

Error: failed to fetch an image or build from source: error building: input:3: ensureDepotRemoteBuilder {"code"=>"invalid_argument", "message"=>"Invalid region fly-lga"}

using fly deploy --depot=false worked

2 Likes
17

Thanks for the heads up! We’ll look into a fix for this.

1 Like
18

Thanks for the report. We’ll look into it.

1 Like
19

Can you try this again?

20 
Error: failed to fetch an image or build from source: error building: input:3: ensureDepotRemoteBuilder {"code"=>"invalid_argument", "message"=>"Invalid region ewr"}

same result but it correctly identified ewr this time

1 Like