Tease us with more "machine" info?

@kurt mentioned that the Machines feature is “not yet released” but it sounds intriguing. I wonder if you could share just a touch more about how we would be able to use machines. As it is I am unable to complete an end to end scenario but really don’t know what to expect so am sure it’s on me.

Here’s what I’ve done so far.

  1. git clone https://github.com/fly-apps/hellonode-builtin
  2. fly launch take the defaults
  3. fly create machinetest
  4. fly machine run -a machinetest registry.fly.io/<app image name from step 2>

That seems to have gotten a machine up and running

app[8d413be3] iad [info] HelloNode app listening on port 3000!

but I am not able to send requests to it. All of the following curl commands result in Could not resolve host: <host>.fly.dev or Could not connect to server.

  • curl http://machinetest.fly.dev:3000 – app name
  • curl http://purple-mountain-2208.fly.dev:3000 – machine name
  • curl -g -6 http://[fdaa:0:543a:a7b:775b:8d41:3be3:2]:3000/ – IP address of machine

Can you point to an end-to-end example of using a machine (where end to end starts with user source code and ends with a response to a user request from that code running on a machine.


We don’t have one yet! It’s part of what we’re doing to release machines.

That last curl should have worked if you’re connected to wireguard, but I’m not positive our HelloNode example listens on IPv6.

To expose it publicly, I believe you need to add and argument like this: fly machine run ... -p 3000:80/tcp:http.

The machines commands are in flux, though, so nothing is guaranteed to work the way I think it does!

We’re launching machines for people who need to build:

  1. Builders. Our remote docker builders are machines. You could use them to run CI builders, or manage builds for a product like Vercel or Netlify
  2. Functions as a service: if you want to build Lambda, you can use machines
  3. Database as a service: if you poke around in branches of GitHub - superfly/flyctl: Command line tools for fly.io services, you’ll see our postgres apps implemented using machines

They’re intended to be driven with API calls. We have a big API mesh that’s not fully rolled out yet, so when you start a machine in Sydney from Sydney, your traffic stays local. It lets you start machines in 500ms or so.

fly machines are a convenience wrapper around the API. When we started documenting the API, we realized APIs are kind of hard to poke at. So the CLI has commands that approximate the API. :slight_smile:

1 Like

Thanks for the quick response. I added -p 3000:80/tcp:http but still get the same errors. Having done that, what curl command should work?

FWIW, I’m very much in the API camp and am focused on high volume lambdas (your #2) with modest volume build (#1). Right now I’m scripting the CLI but would much rather be calling an API. All in due time, I get it. Right now I just need to do a proof of concept that this can actually work.

Oh I missed a step.

You’ll need to run fly ips allocate-v4 to put an anycast IP on that app. Then run fly ips list and use that IP in curl. We don’t setup the *.fly.dev certificate for machine apps yet.

OK. Feels like I’m getting closer but still not quite there. I added an IP address but now get a Connection reset by peer error with curl and nothing shows up in the machine’s console output. Here’s my updated set of steps:

  1. git clone https://github.com/fly-apps/hellonode-builtin
  2. fly launch --remote-only – using the defaults. just to get the code built and image published
  3. fly create machinetest – need an app for the machine to use
  4. fly ips allocate-v4 -a machinetest – setup an ip4 address for the machine’s app
  5. fly m run -p 3000:80/tcp:http -a machinetest registry.fly.io/<app image name from step 2>

At that point I have a machine listening on port 3000 (great) and an IP4 address for the machinetest app. curling that address however either gets me Connection refused or Connection reset errors depending if I use port 3000 or port 80 (respectively).

For the -p option, the CLI doc says it’s format is edgePort[:machinePort]/[protocol[:handler]]. Since the code is listening on 3000 should that be the machinePort? I tried using 3000:3000/tcp:http but that didn’t change anything.

Other suggestions? I did poke around in the branches as suggested but didn’t find anything particularly illuminating.

(interestingly and perhaps unrelated, fly m list shows an empty list even though I’m running the machine)

1 Like

Oh yeah I got the edge/machine ports backwards. You’re reading that right. -p 80:3000/tcp:http should be correct.

Hmmm, that’s not working either. I tried 80:3000 and curl as well as 3000:3000 and curl Hitting 3000 always gets an immediate Connection refused. Going for port 80 thinks for a bit and then gives a Connection reset.

Does any part of the fly.toml play a role in the networking built into the image being run by the machine? In my step 2 (launch), I let it generate the config. That includes a bunch of services.ports and other networking settings. Could they be messing me up here?