flyctl secrets appear to be totally ignored when using docker-compose

1

According to my testing, flyctl secrets don’t work when using the build.compose option in fly.toml. At all.

As an example, consider this fly.toml:

app = 'flyio-envvar-bug'
primary_region = 'sjc'

[build.compose]
  file = "Dockerfile"

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1
  memory_mb = 1024

With a trivial Dockerfile:

FROM alpine
CMD ["tail", "-f", "/dev/null"]

I can run flyctl apps create to create the app, then flyctl deploy and flyctl scale count 1 to get a simple testing app.

If I run flyctl secrets set FOOBAR=secret then the deployed machines are automatically updated. When I run fly ssh console -C env the environment variables of the deployed container are printed, including the secret that was just set.

This is all working as documented. However, now I change the fly.toml to say:

[build.compose]
  file = "docker-compose.yml"

instead of the original Dockerfile configuration. With a trivial docker-compose.yml file added:

services:
  web:
    build: .

Now when running flyctl deploy, the deployed containers are replaced again. I can run flyctl secrets set QUUX=alsosecret to see the same output as before, machines are updated automatically with the new secret.

But fly ssh console -C env shows that there are no secrets in the environment variables. Not the previously-working one nor the new one that was just added.

What gives? The documentation at Multi-container Machines · Fly Docs clearly states:

Secrets are global. Secrets set with fly secrets are available to every container in the Machine. You can’t scope a secret to a single service.

So, secrets are still supposed to be exposed as environment variables, and in fact there is no way to configure it otherwise. This documentation does not match the behavior I observe.

1 Like
3

Hm… It does say that, but Docker Compose compatibility was always rather early/preview-ish and isn’t getting further updates (as far as I know), :snowflake:. I wouldn’t be surprised if it had unknowingly slipped out of synch with the rest of their system at this point…

Can you use the machine_config style, instead?

{
  "containers": [
    {"name": "c1",
     "secrets":[{"env_var": "FOOBAR"}],
     "cmd": ["sleep", "inf"]}
  ]
}

That would go with the following fly.toml:

app = "flyio-envvar-works-now"
primary_region = "ewr"

machine_config = "solo-config.json"

[build]
  image = "debian:bookworm"

Multi-container Machines have rough edges here and there, no matter which approach you take, but this other style would generally be smoother.

(I don’t work for Fly.io, incidentally, and these really are just my own opinions & guesses.)