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.
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
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?
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).
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.
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…
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.
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
I essentially added all my environment variables to [build.args]
[build.args]
SECRET="123"
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.
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?!
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).