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 https://fly.io/install.sh | sh -s prerel

To revert to a non-beta release

curl -L https://fly.io/install.sh | 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:

3 Likes

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 config.ru? 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 config.ru) 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 config.ru 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.

Ding.

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 https://fly.io/install.sh | sh -s prerel

To revert to a non-beta release

curl -L https://fly.io/install.sh | sh

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

Dj

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!

Dj

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/github.com/MonoMicro/zips.server: 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

added:

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

fixed:

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

removed:

  • 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 https://fly.io/install.sh | 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 https://fly.io/install.sh | 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.

Dj

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.

Dj

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

[build]
  builtin = "deno"
  [build.args]
    perms='"--allow-net","--allow-read"'

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.

Thanks!

1 Like