Clarification on Environment variables

Are environment variables in .env added when running fly launch to build from a local environment?

I deployed an app and did not set any secret’s for my environment variables but the app worked “out of the box”

This would not work with Heroku and would need to be added first.

So am I right ti assume the launch command pushes up the .env file too?

If so, it this okay to do or should they be added in the .toml file or using secrets set instead?

Unless .env is specified in .dockerignore, it will be uploaded along with the rest of your source code. I wouldn’t recommend this approach, as it means your secrets are available in plaintext on the VMs and in the Docker image containing your code.

You can use fly secrets set or fly secrets import instead, which keeps your secrets safer.

1 Like

Thanks for the clarification, makes perfect sense.

I tried to run

flyctl secrets import

But it would just get stuck with no output and I couldn’t exit out of the terminal

I found this

So I used this command and it worked fine

cat .env | fly secrets import

Could you clarify why does the above work and not the normal secrets import command, what does cat .env do?

1 Like

Yup! fly secrets import takes key=value pairs from standard input (as opposed to as arguments on the command line, as in the case of fly secrets set).

cat $file | fly secrets import sends the file contents to fly secrets import over the pipe.

To supply arguments to fly secrets import interactively, you can enter them each on their own line, and then hit ctrl+D to send an EOF signal. But it’s probably more convenient to either put them in a file if you have more secrets than will fit on a single line :slightly_smiling_face:

1 Like

Thanks, that makes sense now.

I have added the secret keys successfully but when I deploy my deployment is failing. It is saying the keys do not exist.

This is a Nuxt3 Application and as I believe it uses the key during deployment when running nuxt build. So does this mean I need to add these keys in my fly.toml file to get them to be read during deployment?

Actually I think this is more to do with how Nuxt reads the environment variables during build.

For example I am using a Nuxt module for Algolia. For this to work in the Nuxt config I need to set

algolia: {
  apiKey: process.env.ALGOLIA_SEARCH_ONLY_API_KEY,
  applicationId: process.env.ALGOLIA_APP_ID

Looking at the deploy logs when it runs nuxt build I keep getting the error

ERROR [@nuxtjs/algolia] Missing apiKey

If I add the key as a string apiKey: '12345' then try again I get

ERROR [@nuxtjs/algolia] Missing applicationId

So it does not seem to be reading the secrets while running nuxt build

I had added the secrets using fly secrets import and I have also re added my secrets by unsetting and resetting them and no luck.

Yes, fly secrets is only for variables that can be set at runtime. Off the cuff, I’m not sure how it might work with your app’s tooling, but here’s an example for how to set this up with a Dockerfile from our documentation

Yea that mirrors my experience - Node process.env stuff (when compiling static assets) is only read during build-time (in-browser javascript had no concept of process.ENV).

In that case, you can see how to set build-time secrets here: Build Secrets · Fly Docs

After adding secrets to the build stage, you’ll still need to figure out setting the secret as an env var the node process can read during the Docker build.

Ok thanks for the replies.

So it seems currently you cannot use Fly to deploy a nuxt application that needs build-time secrets using Fly Builder Buildpacks similar to how I was doing on Heroku.

I decided to move to Fly because of the performance improvements and newer technology as Heroku is stuck in the past and I have been incredibly impressed so far!

I gained a massive performance boost when I tested my deployment on Fly, On Heroku Google Lighthouse was giving me a 80-88 on performance with all possible tweaks I could do. Moving hosting to Fly shot performance up to 99 with no other changes and it was noticeably faster.

Since I started using Fly yesterday I have been using Fly Builder buildpacks and not Dockerfile to deploy, so it seems the only way around that is to figure out how to use Fly Builder with Dockerfile. I have never used Docker before so I have some figuring out to do…


The fly launch command should detect a Nuxt application automatically. For reference, you can see the Dockefile it would produce for you here: flyctl/Dockerfile at master · superfly/flyctl · GitHub

fly launch automatically uses buildpacks because my project is not a Docker project.

Based on this documentation

Wouldn’t I need to set my project up as a Docker project with a Dockerfile first and then run fly launch for it to deploy it using Dockerfile buildpacks?

I ask because you refer to the Dockerfile that it will produce so I am confused when it would produce this file.

What I did was remove my fly.toml file

Then I added the Dockerfile you referenced to my project and then ran fly launch and it built a new .toml file without the build command for buildpacks and deployed my application and it is working.

Is this the correct way to do this or am I missing something?

I deployed it with the .env file not being ignored so I can test it is all working. Now to figure out how to add the build-time keys in Docker

You can use --build-arg SECRET=abc which will be interpreted as an environment variable by buildpacks. Have you tried this yet?

Build arguments can also be set on the command line.

@jsierles That was it!

I essentially added all my environment variables to [build.args]


Due to how I have built my app and the Nuxt features I am using, I had to add all my environment variables because they are all needed at build time. I believe Nuxt adds/stores them in its server during the build process as part of it’s runtimeConfig.

So for what it’s worth when building a Nuxt application with fly that uses env variables in the nuxt.config and also any env variables defined in runtimeConfig they need to be added in [build.args] of the fly.toml file.

For example I am using Nuxt’s server routes to create an api proxy to endpoints where sensitive keys are required so they are not exposed and these are all needed at build time.

Right - we may need to mention this in our NuxtJS scanner.

I’m having the same problem with recaptcha keys from Google Recaptcha. I’ve got the secret set correctly in the fly secrets but it doesn’t seem to pick it up. Am I to assume from the solution here that I need to put the actual recaptcha key into the build args in the fly.toml file to make this work? If so, how do I keep the secret, errrrr, secret?!

With build-time secrets? Best practice for build-time secrets? - #2 by fideloper-fly

Store these secrets in your OS’ keychain / keystore, or your CI’s vault, depending on where you’re building the docker image.


The direct link to the docs for using secrets at build time are here: Build Secrets · Fly Docs

As @ignoramous mentioned, they won’t require you to store secrets in the fly.toml file (but they do require a tad extra work to use them at build-time).


That’s it - great - thanks so much! All sorted.

1 Like