Deploy failing w/: "Error error creating a new machine machine: failed to launch VM: To create more than 1 machine per app please add a payment method."

[michaelscruz]

Hi! I’m new to Fly.io, and in the process of building my first Phoenix/Liveview app, and decided to give fly.io a try. I tried following the instructions on the getting started page, but ran into the following error when trying to deploy:

Error error creating a new machine machine: failed to launch VM: To create more than 1 machine per app please add a payment method.

When I check my Machines tab, I see one for each deploy attempt I’ve made, but they all have a state of “destroyed”, so I shouldn’t have more than 1 machine during the deploy process (I would think).

Am I missing something simple? This question from back in August seems similar, but that appears to have been resolved by a bug fix. I am using the latest version of flyctl (0.0.509) on homebrew, so I assume it’s not the same issue.

Thanks!

[allison]

My best guess: if your fly.toml has a release_command value, that is likely the issue. Release commands run in separate, ephemeral machines, and many framework launchers in fly launch end up setting release commands.

Typically these commands are for things like running database migrations - things you don’t want your app to do every time it starts up, only when there’s a new version being deployed, but that you can’t do in the dockerfile setup.

In the case of Phoenix, it seems like the flyctl launch scanner for Phoenix only adds a release command if ecto is used in your project.
In that case, you might be able to get by with commenting out the release command in your fly.toml and adding this to it:

[processes]
app = "/bin/sh -c '/app/bin/migrate && /app/entry start'"

This overrides the command that’s specified in the dockerfile, appending the ecto migration script to the startup command of the app’s machine.

This is probably fine (no guarantees!), but would likely not be a great idea if you were running multiple machines. Of course, if you were running multiple machines, you could just go back to running release commands. This is just a temporary solution to get you unstuck

[michaelscruz]

Thanks, @allison - thank you for your response, and sorry for my late reply! Life happened and I am just now getting back to this project

This seems to have worked (though I had to amend the script to run /app/bin/server instead of /app/entry start). I will need to read up to understand this solution a bit better, though. I am a little surprised that the default behavior for a simple Phoenix deploy needs to be overridden.

[Mark]

Welcome @michaelscruz!

I’m glad it got worked out. You are correct, it should not have required something to be overridden. A new Phoenix app and a new launch/deploy should just work. Especially around the Dockerfile config and the fly.toml command. Anyway, glad it’s working!

[amorant]

Just chiming in to say that I encountered a very similar issue setting up a rails app.

The initial, default setup steps produced a working configuration that I was able to deploy successfully. This included running db migrations on deploy. I tried to move that to a release_step following the docs, and deploys started failing with an error message similar to yours.

I fixed my issue by reverting to the original config setup. The reason I tried to do the switch is that, from my understanding, the deploy steps will be run for every machine running the app, and while trying to run migrations more than once won’t break anything, it’s not really necessary so a release step that runs once per release (regardless of the number of machines) would have been better. Not an issue for today as I have a single machine running the app, of course.