The Fly Beta Shop

We’re running public betas on new versions of flyctl… so you can be the first to try out and report on some of the new functionality we’re bringing to the fore (or get your favourite issue resolved).

These include new “builtin” builders which you can select when you init your App. Node, Ruby, Deno, Go and a static web server are available. No Dockerfile needed. Just init and deploy. Ideal for your quick instance. Browse them with the flyctl builtins list command. If you want to know more about a particular builtin, try flyctl builtins show builtinname. Tell us how they work for you! And tell us what you’d like builtin…

When you use the flyctl certs commands to set up your TLS/SSL certificates, flyctl will now try and help you by telling you what to do next…so if you have a domain certificate you want set up, use the flyctl command line and see how useful flyctl’s guidance is and let us know too!

There’s also a a new orgs command, bringing organizational creation to the command line. It’s missing the feature that lets you add users to the organization (you can do that from the web-ui still) but it’s here as an early peek-ette as we fill it out.

There’s also a set of dns commands, as mentioned in Feature Preview: DNS + domains - these are a preview and like everything in the beta subject to change.

Remember as always it is a beta, and we don’t recommend you run it on your production systems.

To install it on mac or Linux:

curl -L | sh -s prerel

To revert to a non-beta release

curl -L | sh

Got questions? Ask here! Got a problem with the beta? Tell us here! Got answers? Let people know here! Got… you know the drill :slight_smile:


These builders are a great idea!

The Ruby builder has the following description:

Builtin for a Ruby application with a Gemfile. Runs bundle install to build. At runtime, it uses rackup to run app.rb

Shouldn’t that be That’s the Rackup file that Rails uses, which framework uses app.rb?

Yes, it should be. The details are from an older builtin config (which tried to generate the which I switched out for a straigh ruby/rackup builtin which is in the beta. Message fixed up to read:

Builtin for a Ruby application with a Gemfile. Runs bundle install to build.
At runtime, it uses rackup to run and start the application as configured.

1 Like

Cool… on the same vein, the Go builder talks about running app.go, but I think it already runs main.go, which is more conventional.

Also updated, and now with support for assets in the resources directory to be copied across to the image. More on that when the docs are done.


New Flyctl Beta. 0.0.138 Beta 8.

All the builder details updates plus…

init now prompts for an internal port for all builders so you can always match it with your app.

the go builtin builder will now also copy over a directory resources if it exists, into the final image allowing Go apps to access static assets. (parity with other builtin builders)

You can now flyctl init --image imagename to deploy a Docker image. This works like the flyctl deploy --image imagename command but the operation is persisted in fly.toml and offers the chance to change ports (see above) and other settings.

Setting secrets where there are no changes to values is now handled with an appropriate error.

Enjoy the update!

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!