Staging vs production environnement with the same code base


I have a golang project that runs on fly.

I wanted to have a staging envrionnement.

I’m confused on what to do to setup this staging environnement.

Can anybody help ?

I have tried to have a fly.staging.toml file with a different appname, but when I try to deploy it It gives me a error. “Error failed to fetch an image or build from source: Could not find App”.

My main fly.toml app name is xxx and the fly.staging.toml app name is xxx-staging.

I run my production code on the main git branch and my staging code on the dev branch.

Thanks for your help

You may have to fly launch --no-deploy --org <org-name> (run this cmd in an empty dir) the app in the correct org first?

Hi @ignoramous,

Thanks for your reply.

Just to make sure I understand the part where you say "run this cmd in an empty folder).
The empty folder can be anywhere ? I not sure I understand that part.

I have my master branch and my dev branch. Is it possible to work on my master and deploy my production environnement and have my dev branch and deploy on a stage environnement on fly ?


From your PC (or exec this cmd just once, from where-ever you are). flyctl launch is basically to create a new Fly app (docs).

Yes, many ways to do so.

There’s also fly-pr-apps (apparently, unmaintained): Simulating PR Review Apps via GitHub Actions


Once I have create the flyctl launch in a empty directory.

How does it help to manage different environnement (staging, production) with the same code base.

I must say I’m dont understand.

Say, you create two Fly apps (with flyctl launch or flyctl apps create), devdw-app-test and devdw-app-prod and add corresponding entries for it in fly.toml.

If staging and prod use same fly.toml but different dockerfiles, you’d do:

# for staging
flyctl deploy -c fly.toml -a devdw-app-test --dockerfile /path/to/dockerfile-test
# for prod
flyctl deploy -c fly.toml -a devdw-app-prod --dockerfile /path/to/dockerfile-prod

If staging and prod use the same dockerfile but different fly.toml (with app name predefined in the toml itself), you’d do:

# for staging
flyctl deploy  --dockerfile /path/to/dockerfile -c fly.staging.toml
# for prod
flyctl deploy  --dockerfile /path/to/dockerfile -c

and so on…

Fly is working to make multi-environment deploys easy still: Feedback/requests from a Rails perspective: apps grouped with a shared deployment story, one-off apps/machines, and pipelines - #2 by Brad

See also: Managing multiple environments - #14 by indirect

Ref docs: Monorepo and Multi-Environment Deployments · Fly Docs

Here’s a codebase that I deploy to four different Fly apps, for reference (check out the .tomls, .dockerfiles, and .github/workflows): GitHub - serverless-dns/serverless-dns: The RethinkDNS resolver that deploys to Cloudflare Workers, Deno Deploy, and


Hi @ignoramous ,

thanks for your help.

Once I did the fly launch --no-deploy --org <org-name> command in a empty folder.

I was able after that with Gitlab CICD deploy different branches to different environnements or apps.

On fly, I have applive and appstage.

In gitlab, I did add in variable to my cicd for the fly auth token. And added a protected branch, because by default only main is a protected branch.

In my CICD, I have this ::

  image: golang:1.18.3
    - apt-get update -qq && apt-get install -y curl
    - curl -L | sh

  # - test
  - deploy

# test:
#   stage: test
#   script:
#     - echo "Test stage"

  stage: deploy
    - staging
    - /root/.fly/bin/flyctl deploy --app appstage

  stage: deploy
    - main
    - /root/.fly/bin/flyctl deploy --app applive

This works like a charm.

Thank you very much for your help and replies!!! Greatly appreciate !!!

You saved my life !!


Glad it worked. I think, even if I hadn’t helped, you’d have figured it out given the numerous other such threads on these forums and the official Fly docs themselves.

How do you intend to repay me? (:


How would you pass secrets for the production app ( --app applive) in a gitlab yaml file ?

How would you pass secrets for the production app ( --app applive) in a gitlab yaml file ?

build-time secrets or run-time?

Don’t use GitLab, but one can import secrets into its CI env via GitLab secrets, I believe?


Yes, I was going to use the Gitlab cicd secrets, so the first time it would push secrets on the main branch of the app. Something like :

  stage: deploy
    - staging
    - /root/.fly/bin/flyctl deploy --app projectname

  stage: deploy
    - main
    - /root/.fly/bin/flyctl deploy --app projectname-live
    - /root/.fly/bin/flyctl secrets set GIN_MODE=$VAR_NAME

unfortunatly, the ‘/root/.fly/bin/flyctl secrets set GIN_MODE=$VAR_NAME’ line does not put secrets in the projectname-live app but in the projectname app.

Could I do something like :

  • /root/.fly/bin/flyctl --app projectname-live secrets set GIN_MODE=$VAR_NAME


I was able to put secrets in my live app.

What I did is delete my live app that had nothing in it so far.

I created a empty folder with the name of my live app on my local machine. I did it at the same level where my main app lives.

I run the no-deploy function like we earlier discuss.

The run the flyctl secrets command from there.

And that worked.

But did not made it work with gitlab cicd.

1 Like