Managing SECRET_KEY_BASE without Kubernetes/Docker/etc?

Hmm, generally I wouldn’t generate the SECRET_KEY_BASE if it doesn’t exist, I’d instead always pass it in via Env variables. Specifically these are the situations I’ve dealt with before that didn’t involve Kubernetes/Docker:

• App deployed on Heroku - Set an env variable in the UI
• App deployed on Render - Set an env variable in the UI
• App deployed on my own server and managed with systemd - Set EnvironmentFile=/path/to/some/.env file

That way the only snippet you need is something like:

# /config/runtime.exs

# …
if config_env() == :prod do
  # …
  secret_key_base =
    System.get_env("SECRET_KEY_BASE")
    || raise "SECRET_KEY_BASE is required and was not found"
  # …
end

Adding one more option:

• Release started manually
  env $(cat .env | xargs) ./bin/app remote

In the end system env is the complete opposite than catered to the cloud. You can provide those in a million ways and there’s likely one fitting your workflow – and it’s completely independent from the fact that you’re running elixir at all.

Just as a side note: there is a mix task to create a secret key.

The snippet you posted is actually the stock behavior of the phx.new template; I edited it away from that because I don’t want my server to crash on startup just because the technician attempted a perfectly reasonable ZIP installation.

The app isn’t being deployed in any kind of fancy cloud service, either. Heck, right now it’s targeting Windows server (though we hope to move over to Linux at some point.)

I guess that I could bundle extra instructions with the application demanding that the installing technician fiddle with the registry to get basic functionality… but is there really not any established pattern for making Phoenix “just work” in the absence of a fancy managed environment? (And even on Linux, putting a systemd service that references an external file just passes the buck of generating that file…)

That task seems to be hard-coded to send the result to standard output. I actually linked to that line in the comment at the top the bit of my code that does what that task would.

Or maybe I’m X-Y problemming this.

What, specifically, would go wrong if I simply set :secret_key_base randomly on startup whenever the environment doesn’t specify it? Would everything work perfectly so long as the app isn’t being clustered/distributed/whatever, or would I be laying the seeds of—for example—a catastrophic Ecto failure next time the server restarts?

If the former, it seems like it would be pretty simple to raise if and only if it’s unspecified and the app is being run in a way that actually requires a non-arbitrary value for it… am I missing something?

Sessions are signed with the secret key. So all session cookies of user will become invalid, effectively logging them out if the were logged in and dropping any other stuff you might have stored in the session. Similarly csrf token given out (e.g. as part of forms) will become invalid, so users still having a form open won’t be able to successfully submit their forms. Phoenix.Tokens also reply on the secret if you happen to use those.

I see… so if I just randomize it on startup, then users authenticated based on session cookies will be logged out, any CSRF-protected flows will be interrupted, and any Phoenix.tokens will be ungracefully invalidated. Definitely not great.

Since keeping it stable is apparently so crucial to so much of Phoenix’s operation, what are the risks/drawbacks to just storing it in Ecto after automatically generating it on the first run?

I’m wondering if you’re not better off figuring out system env on windows over figuring out how to work around it. Releases support being installed as windows services, which based on the docs allow you to define additional system env values.

erlsrv — OTP 29.0.2 (erts 17.0.2) (See Env parameter)

Hmm, one difficulty I’m running into there is that Ecto isn’t started during config-load time:

** (RuntimeError) could not lookup Ecto repo Foo.Repo because it was not started or it does not exist

import Config
require Ecto.Query

…

if config_env() == :prod do
  database_path =
    System.get_env("DATABASE_PATH")
    || Path.expand("foo.db", :filename.basedir(:user_data, "fooApp"))

  secret_key_base = # https://forum.elixirforum.com/t/managing-secret-key-base-without-kubernetes-docker-etc/67926?u=james_e
    case System.get_env("SECRET_KEY_BASE") do
      s when not is_nil(s) -> s
      nil -> Foo.Util.get_or_insert_one_lazy!(
        Foo.Repo,
        Ecto.Query.from(s in Foo.Repo.Schemas.Secret, where: s.type == "secret_key_base"),
        fn -> %Foo.Repo.Schemas.Secret{type: "secret_key_base", value: Foo.Util.phx_gen_secret} end
      ).value
    end

  …

  config :fooApp, FooWeb.Endpoint,
    …,
    secret_key_base: secret_key_base

  …
end

Is there any best practice for making parts of Endpoint config depend on values stored in Ecto, like that? If I were to start Ecto within this file, I’m pretty sure that’d break the supervisor structure, and I don’t see any obvious clean way to transform the phx.new template to do that. Maybe a separate :ignore process that runs immediately after Ecto.Migrator?

This seems like a LOT of hoops to jump through just to avoid the actual good practice of doing a rolling deploy. And if you can’t rely on an environment variable being present on boot, how are you going to connect to the database anyway? Is that not also configured via an env var?

Zooming out: your app has preconditions to booting. The correct thing to do when those preconditions are not met is to not boot, which allows the currently running instance to continue to serve traffic. The boot failure goes to your logs, which gives you alerts, and you fix it.

None of that is docker or container specific, that’s been the normal rolling deploy pattern for 20+ years now.