We're launching Fly machines today

If I understand the docs correctly, currently the fly proxy is unaware of differences between machines beyond ports.

This means that if you create two completely different machines inside the same app that expose themselves on the same public port (e.g. 80), incoming requests to the proxy will effectively randomly distribute requests between the two completely different machines.

In effect, if you want to use the fly proxy you would currently need to create a separate app for each different machine. Is this correct?

If so, are there any plans to make the proxy “machine aware” so that requests can be routed to specific machines using maybe path routing? Or this is feature more intended for advanced use by internally hitting the machines directly using their IPv6 addresses?

Dedicated CPUs are not available yet for machines. Granted, the error could be clearer about this.


Fly proxy will route to the nearest machines with a service listening on the requested port. Indeed, the proxy does not know if machines on the same port run different code.

The good news is that we’re actively working on ways to route traffic to specific machines or groups of machines. We wanted to get the core functionality in front of developers as early as possible.

1 Like

Thanks for letting me know! That makes sense and no worries re: the error message, I’m guilty of worse :slight_smile:

Are you able to share an approximate timeframe for when dedicated CPUs might become available? Is it on the order of days, weeks, months? (The reason I ask is because I’d like to use them as build agents and 2GB is just a bit too small)

We don’t have any plans to bring the dedicated CPUs back. The 2GB limit is per CPU and not in total (not sure if you were already doing this) so if you request 2 CPUs, you can have up to 4GB of memory (with a max of 8 CPUs and 16GB of memory).

1 Like

That’s brilliant, thank you! I was looking at this code in flyctl which is why I thought that dedicated CPUs were the only way to get more RAM - but maybe the code is outdated.

I can get back to building now. This is a seriously cool product you folks have built :star2:

1 Like

Sorry, I’ve got another follow-up question! How does the pricing work for these machines? E.g. this is a screenshot of the pricing page today:

If I create a machine with guest config {"cpu_kind": "shared", "cpus": 8, "memory_mb": 16384} will it be charged at $0.0000957/s (the price listed for a dedicated-cpu-8x with 16GB)? Likewise, I’m able to create a machine with {"cpu_kind": "shared", "cpus": 8, "memory_mb": 10240} - how would this be priced?

The reason I ask is because it looks like there was a price premium for dedicated, so it’s hard to know what I’ll be charged. Would it be fair to say that even if the pricing isn’t yet determined, those dedicated prices would be a reasonable upper bound on the eventual price?

I was wondering the same thing… did you find out how much will be billed for additional cores?

Can machines and regular applications coexist in the same fly “app”?

Hey, any update on when the docs will be available? I think this will unlock a lot of new possibilities, really excited!

We need to update pricing for Machines, but they’re just multiplied by 2x, 4x, or 8x. So shared-cpu-8x costs about $14.72/mo and includes 2GB RAM.

1 Like

They can’t! Right now, regular apps are orchestrated via Nomad. We decided it would be simpler not to co-mingle machines + Nomad.

Soon, regular applications will just be machines though.

You can use volumes with machines now. It’s just not a great UX through flyctl.

fly volumes list

This will show you a list of volume IDs. You can run a machine against one like this:

fly machines run <image> -v vol_k0o6d42klz1487gy:/data

It’s safe to use them, we just want to make the UX nicer before we make a big deal out of it.

awesome thanks! I peaked in the flyctl source code and saw some undocumented stuff for machines and postgres, so just wanted to mention that I’m trying to rig something together with sqlite/litestream and machines.

i’d love to be able to upload to the volume straight from the application code via an API, kind of like how you can PUT to an s3 bucket - Uploading to Amazon S3 directly from a web or mobile application | AWS Compute Blog. does this seem feasible? is there a better place to ask questions like this?

Oh nice!

There’s no built in way to upload to a volume. If I were doing this, I’d add a tiny little API in each machine that could accept files and put them where you needed them.

This is something we will have features for at some point, but it’s going to be a while.

Ok cool, that makes sense, thanks!

@kurt I’m curious what you think of https://tus.io/ ? it seems like if i can get that onto a machine, it would save me the trouble of implementing the file upload part of the tiny api, which seems to be the tricky part. i’d probably try to copy something like Resumable Uploads  |  YouTube Data API  |  Google Developers which seems like a pain

tus.io looks pretty cool! I didn’t know about it before, but that it looks worth trying.

If you just need temporary access, you could start a machine with a Filebrowser image, do what you need, the update the machine with a new image.

1 Like

@kurt are env vars set in an app’s fly.toml sent to all machines in that app? Or do they have to be set on each newly created machine?

Right now, they need to be set on each machine. However, work is being done now to make fly.toml work with machine-based apps. Stay tuned!

1 Like