Hey!
We’ve decided to rethink our remote builders. They’re the machines that build your app when deploying without a local Docker daemon or when using --remote-only
. We had been using AWS CodeBuild, but it was too slow for our taste. It didn’t feel good when we forgot to start our local Docker daemon before deploying.
Starting with flyctl
v0.0.164, the new remote builders should just work for your remote builds.
So what’s better about them?
- They’re much faster to boot up
- They should be faster when building
- They stream the Docker build output as it happens, not just at the end
- They’re private to each organization, these are not shared which allows for layers reuse for your builds
Technical details
- They run on Fly, like any other app, except they’re ephemeral
- They use our volumes feature to cache Docker layers
- They turn off automatically after 10 minutes of inactivity
- We’re proxying Docker connections to a Docker daemon running inside a VM on Fly
- These VMs are currently set to use our
dedicated-cpu-1x
tier
We’re still ironing out a few performance issues around them, but they’re already faster than our current remote building solution.
For your first remote build for an organization you’re part of, the boot might take up to a minute. While it stays up, it should be able to accept build jobs without delay. As it cools down and is turned off, turning it back on should only take a few seconds.
These remote builds will appear in your apps as fly-builder-...
, but you won’t be billed for them right now. We’re still working out a reasonable billing plan for them, but in the future you’ll have hours of free remote build time per month. Even if you did overflow on this free build time, you will wouldn’t break the bank.
Upgrade your flyctl
to at least v0.0.164 and let us know what you think!