Ephemeral fly machine?

1

Hey all, just wondering if you can create and run a machine that automatically destroy’s itself after it exits?

My understanding is you have to manually destroy a machine and it accrues (a very small) cost when it is in an idle state. But it would be handy to just do the following and have no trace of the machine afterwards:

fly machine run --rm my-docker-image

I use to use heroku and frequently took advantage of heroku run for all kinds of tiny operations workflows like e.g. account exports, or taking manual backups of the db and uploading them to a store.

My understanding is, if I use machines in a similar way I’ll end up with a lot of idle machines accrued over time. Is that correct? Is there a simple way to manage ephemeral machines?

1 Like
2

My understanding is, if I use machines in a similar way I’ll end up with a lot of idle machines accrued over time.

A single instance of a machine app (one that’s stopped but not destroyed) can continue to serve multiple requests over its lifetime, even concurrently if required (see soft_limit / hard_limit in concurrency).

I like to think of machine apps as Amazon API Gateway + AWS Lambda.

My workflow is: After creating a Fly machine app, I flyctl deploy the docker image (to which ever regions), and then send http, tls, or tcp requests to it (unsure if machines support udp; edit: udp should work), after having allocated it v4 / v6 public ips. I am not really sure if machines work with Flycast IPs (it’d be cool, if they did).

When a machine app isn’t serving any requests, it is free to stop itself (or can be stopped with flyctl m stop <machine-id>. Fly guarantees that stopped machines will be woken up whenever a request comes in (typical cold starts: 300ms).

This Fly blog post has a nice rundown of deploying a machine with flyctl (which is what I prefer using over Fly’s GraphQL / REST API).

if I use machines in a similar way I’ll end up with a lot of idle machines accrued over time. Is that correct?

If I am not wrong, if one keeps destroying but also recreating more machines, I don’t think they’ll accrue a collection of them. Destroyed machines are relegated to the dustbins of history, never to be seen again (except for in that month’s invoice).

My understanding of machine apps is just from fiddling with it for the past few hours, so that’s one disclaimer. And for the next one: I do not know anything about Heroku, so I can’t really answer your question of what’s the Fly equivalent of heroku run.

3

Thanks for the reply. What I’m asking is, is there a way to automatically destroy a machine when it stops without having to manually invoke a call to destroy?

So if I go fly machine run ubuntu ls that machine is created, runs the ls command and then destroys itself after it stops.

E.g. with docker, you can run a container that will automatically destroy itself after exiting via the --rm CLI flag e.g.

docker run --rm ubuntu ls starts an ubuntu container, runs ls, stops, and then is automatically deleted because of the --rm flag.

Is there a way to do something similar with fly machines without having to do an explicit API call to destroy?

1 Like
4

There’s not yet! fly machine update might work, though. It updates and starts an existing machine. You may be able to keep one around and run “update” instead of creating a new one each time.

2 Likes
5

Ah that’s a cool pro tip thanks!