The Fly Beta Shop

As you may have seen, we have now released 0.0.138 (and 0.0.139)…

We’ll be making sure beta cycles are a lot shorter and more regular in the future, so stay tuned for more…

1 Like

Hi Beta Shoppers,

There’s a fresh beta out - 1.41-beta 1. And there’s only a few changes as part of our plan to make beta cycles a lot shorter…

There’s a fix for --app usage - previously when you had a --app flag but an incomplete command which didn’t need --app, you got an error about the --app flag but no help. Now, you get the help.

The node builtin now runs npm run-script build --if-present after copying files over to allow for frameworks that need the build stage run (if you don’t do it, the build stage is run at app instance run time, and may take long enough to fail a health-check). Now this is done at deploy time as part of the build.

And the static build now has a not that it will not serve files where the execute permission is set. This is a feature of the underlying server in use.

To install it on mac or Linux:

curl -L | sh -s prerel

To revert to a non-beta release

curl -L | sh

Let us know what you find and what you think here.


Oh I forgot - also in this release, a final warning around failed deployments and rollbacks…

1 desired, 1 placed, 0 healthy, 1 unhealthy
v7 failed - Failed due to unhealthy allocations - rolling back to job version 5

1 desired, 1 placed, 1 healthy, 0 unhealthy
--> v8 deployed successfully
***v7 failed - Failed due to unhealthy allocations - rolling back to job version 5 and deploying as v8 

And for you big multi-region deployers, the restart number in status for allocations is now shown correctly.

Again, enjoy… this will be in production soon unless you can find a bug!


Does flyctl not work if the name of the directory contains a dot ‘.’ in it? I’m getting the following error:

Error open /Users/sj/go/src/ is a directory

Can that be fixed or do I need to rename?

Seems an earlier fix has regressed. I’ll look into it.

Beta 2 of 0.0.141 is now available


  • An experimental hugo-static builtin. Runs your hugo build and deploys with a static web server.


  • Using --import doesn’t break on searching for the internal port
  • Dots in filenames in the path to fly.toml work now


  • The dns command has been withdrawn while more work is done on it. It’ll be back (well, not the dns command exactly, but something more shiny with featuritude)
1 Like

Ok, you don’t have to be on a beta to try this new feature out. It’s the start of a longer journey, but the flyctl command is going to become the fly command. We’re taking this steadily so the first thing you are going to see when you next install with

curl -L | sh

is that there’ll also be a fly command in the bin directory, which is currently a symlink to flyctl. In future that will change, but for now you’ll be able to type “fly …” and everything should happen as you expect it to.

A beta soon will take care of most places where flyctl is printed in the output and we’ll be iterating on this as quickly as possible to complete the migration.

Fly 0.0.141 Beta 3 is out…

  • A new static plus builtin (does logging and https upgrading with custom domains)
  • Builtins now note port 8080 is used as the internal port
  • init --overwrite will overwrite fly.toml without prompting
  • flyctl will respond with fly name if started as fly
curl -L | sh -s prequel

to install and you should also get the fly symlink so you can MOVE INTO THE FUTURE!

Any and all feedback welcome.


And then we were at 0.0.143 release and a new 0.0.144-beta-1. There’s some more experimental builtins, various tweaks and…

fly version update

Which will auto run the needed script for you to update your prerel or release.

Oh, and Windows support for installation is improved and version update works there too.

We’ve also been nailing down some minor issues around auth keys for the API and the preservation of them. Should be a lot less surprising.

Check em out, let us know what you find.

Oh and yes, that was right, you can use fly or flyctl, thanks to an automatic symlink. And that works on Windows too.

Enjoy your Fly beta weekend.


Some changes in 0.0.144-beta-2:

  • We’ve moved from using Alpine as a base image and are using Debian and other base images. Alpine has issues with DNS resolution, so if your app is having trouble resolving DNS names, check you aren’t running Alpine.
  • The Deno built-in now can run without a deps.ts. It’s not an ideal solution, but Dockerfiles handle optional behavior very very badly.

In the pipeline is an option for use to have builtins with arguments… I’m looking for feedback on this early on before bringing it to the beta, but let’s take an example… Deno - this needs different command-line parameters to set what the app is allowed to do. Currently I fixed this at “–allow-net” which is fine for a lot of web applications…

CMD ["run", "--allow-net" , "main.ts"]

Anyway, in the new variant we can replace that with an argument name and do something like

  builtin = "deno"

in the fly.toml. Now, where the “–allow-net” string was is replaced by a args reference to perms.

CMD ["run", {{ .perms }} , "main.ts"]

With that setting we then get:

CMD ["run", "--allow-net","--allow-read" , "main.ts"]

We’ll only be adding build.args options where it is very important that users are able to change particular values, like selecting particular base images or setting entrypoints.

This, we hope, will make builtins a bit more flexible. What do you think?

Say hello to Fly 0.0.144-beta-3

So what’s new in this beta…

Well, let’s start with --nowrite, a new flag for the init command. Now you may already know that you can have the same application deployed with different names. Well, --nowrite makes that easier by going through the creation of an app slot, but not the configuring of networking or builders, and it doesn’t write anything to fly.toml. The apps name is written to a file called fly.alias which is a list of aliases the app goes under. Remember to use -a to address these mirror applications. This is a small part of the work we’re doing to support different build and deploy paths.

Also, the domains and dns-records commands are back, well the old beta dns command became dns-records. If you want to know more, head over to Feature Preview: DNS + domains where we’ll be updating you on how to use them - if you have questions about the fly/flyctl part of it, ask here…

These and lots of polishing make up beta 3. Enjoy and do let us know how you get on. We don’t ship our tools with any telemetry; we do rely on you to let us know how you are finding the betas.


1 Like

Builtin Settings in 0.145-beta-1+

Flyctl 0.0.145-beta-1 has landed with a new feature. Settings for Builtins. This makes Builtins more configurable than ever. There’s also a new Python builtin and many fixes.


When we introduced the Fly Builtin, we wanted to make it as easy as possible to go from zero to a Fly deployment up and running. Our secret - we baked in carefully crafted Dockerfiles into the Fly CLI app so you could just tell flyctl what kind of app you were building and we’d automatically use the builtin Dockerfiles.

Since builtins landed in Fly, we have added a couple more to the available builtins, like a hugo-static builder. Run that in a directory with a configured Hugo site and your files will be published in no time at all.

But we also had requests for particular changes, often small but important changes, like skipping or adding steps, changing the base image for Docker, and setting particular flags. This got us thinking about how we could make Builtins more configurable.


The answer was to bring settings to builtins. Settings have sensible defaults, but you can override them in the fly.toml file to change how a builtin is run. Let’s show you an example. Deno’s runtime is very secure by default and expects you to set multiple flags to allow particular actions. By default, we turn on --allow-net. But what if you also wanted to allow reading of the disk (yes, Deno is strict about this stuff). Well, now in fly.toml you can write:

	builtin = "deno"
	perms = [ "--allow-net", "--allow-read" ]

The perms setting takes an array of command line flags and adds them to the builtin’s RUN command for Deno.

So, how do you discover if your builtin has settings? Use the fly builtins show <builtinname> command. Let’s have a look at the static builtin with that

❯ fly builtins show static
Name: static

Description: Web server builtin

All files are copied to the image and served, except files with executable 
permission set.

httpsonly=false (bool)
     Enable http to https promotion
log=false (bool)
     Enable basic logging

Dockerfile (with defaults):
FROM pierrezemb/gostatic
COPY . /srv/http/
CMD ["-port","8080"]

The Settings section shows what settings are available, what the default is and what type of value is expected. Strings, integers and booleans as well as arrays of those types are supported. Check the description to see how these types should be used.

To assist debugging, there is also fly builtins show-app which will use the current fly.toml to preview what the builtin will do:

Name: deno

Description: Deno builtin

Uses Debian image from
runs main.ts with --allow-net set and requires deps.ts for dependencies.
Uses and exposes port 8080 internally.

perms=["--allow-net","--allow-read"] (array)
     Array of command line settings to grant permissions, e.g. ["--allow-net","--allow-read"]  defaults to [--allow-net]

Dockerfile (with fly.toml settings):
FROM hayd/debian-deno:1.4.0
USER deno
COPY main.ts deps.* ./
RUN /bin/bash -c "deno cache deps.ts || true"
ADD . .
RUN deno cache main.ts
CMD ["run", "--allow-net","--allow-read", "main.ts"]

This shows what the settings are and their effect on the builtin Dockerfile.

Please give them a try. Right now, there are settings for deno (for permissions), static and hugo-static (for HTTPS promotion and logs), and the Python builtin (for versions).


Oh yes, completely forgot, there’s a Python builtin now. It’s experimental, but thats the point of these betas. Basically set up a requirements.txt and a Procfile to set up what you run and the builtin will get all the requirements and set up to run the Procfile. It’s powered by hivemind.


Are you interested in creating builtin style builders for your projects? Drop us a line, as we have something we’d like to try out (spoiler, it’s a way to design your own builtins and use them on demand)…

Also Wanted:

We want to hear from you about your build experiences. Are you using the builtin builders? Or are you rolling your own Dockerfiles? Are you using buildpacks? Let us know about that and what you are happy and not happy with. We have massive plans for the entire fly experience and we want to make sure it’ll make a difference to you.

Looking forward to your bug reports and feedback!

Let me share my build experience so far, which is awesome btw.
I started with the builtins, very useful to kickstart something on Fly.
As soon as I wanted to optimize the runtime for image size or wanted to be up-to-date with a specific runtime version I went creating custom Dockerfiles. This way I’m able to use e.g. my static web server Docker image which is only 160k in size (compressed) and has decent performance even on a tiny micro-1x!

1 Like

You have to let me in on how you get a web server in 160K…


[adds lwan to list of interesting servers] Thanks.

sure, glad you asked.

(And now I’m looking at if it would be useful as a builtin…

PS: Any requests for builtins (either new ones or features/switches in existing ones, just let me know)


Now it gets even more tiny, only ~64kB by using Sqlite/Althttpd.

1 Like