I keep the app name in the fly toml the staging app, and when I want to deploy production I promote the latest staging image to production, so I never build a new image for production, simply deploy one of staging’s images:
@drio I’m new to fly.io but I generally like what you’ve got here. one question about it though, how are you providing environment vars to your container when running it locally? the handling of env vars for locals is the one piece of the equation that i don’t quite understand yet with fly.io…
I’m a little confused about how to implement the multiple environments. I have an app deployed called myapp-back-end and I want to have it deployed as two different apps, dev and production, so that I can deploy different branches on the dev app.
I tried running: fly deploy -a myapp-back-end-dev
because I was hoping that would deploy the same branch onto a different app called myapp-back-end-dev running on another machine. But I got this error:
==> Verifying app config
Validating C:\Users\username\Documents\Node projects\myapp-back-end\fly.toml
Platform: machines
--> Verified app config
✓ Configuration is valid
Error: Could not find App "myapp-back-end-dev"
Hi… If you want to continue with flyctl itself, you can just register the new app name first:
fly app create myapp-back-end-dev
fly deploy -a myapp-back-end-dev
(I use this all the time.)
The differences between fly app create, fly deploy, and fly launch do confuse a lot of people… Basically, the middle one is for apps that already exist—at least in a minimal, metadata form.