Best practice for build-time secrets?

Questions / Help Build debugging
9

OK, you definitely caught my attention with “fleet of 256 MB instances”.

A few brainstorming ideas.

  • If all you need is some memory right before launch, consider defining a swapfile. This may not be the solution you ultimately go with, but it is the quickest to get up and running. Here’s a script that you can steal from: dockerfile-rails/docker-entrypoint at c7f85b21d44078ba94a7d10c3da899227f420a0b · rubys/dockerfile-rails · GitHub
  • If you are indeed very interested in a custom credentials tool, check to see if there is one already implemented for you. node-credentials - npm looks promising.
  • You’ve got your credentials on your development machine, and made them available to github actions. You could build SSG server side generated HTML in either of those places.
  • Since you are using GitHub actions, you have a multi-stage build process. What’s one more step? :slight_smile: Define a second fly application. GIve it as much resources as it needs. Make it a fly machine so that it created when needed but goes away when you exit. A deploy of this app will have the full source to your application and access to all of your secrets. Have it do your SSG, and then do a deploy of your fleet from there. Just like how you can install flyctl on github actions, you can install flyctl on your fly application.

I definitely empathize with the problem you are dealing with, and would like to help. I’m also aware of the damage that a wholesale leaking of secrets can cause. Over time I expect fly’s auth token to become more fine grained as to the amount of access an individual token can provide. The approaches listed above should limit the impact such changes will have on you.

2 Likes