Application Config is Env Var Order Dependant #233

New Issue

OVERLORD · 2026-02-04T18:50:29+03:00

OVERLORD commented

2026-02-04 18:50:29 +03:00

Originally created by @mohammed90 on GitHub (Feb 16, 2019).

This is a weird bug that threw me off for a long time. At first I thought it might be related to #359, but now it seems like something else. The docker-compose file here doesn't enable the /admin path, despite the ADMIN_TOKEN being set. You'll keep getting 404. It's definitely set because it shows when I ran env inside the container.

Here's where it gets freaky, it works if I move the ADMIN_TOKEN to the top of the list, i.e. before ROCKET_PORT.

version: "3"

services:
  bitwarden:
    image: mprasil/bitwarden:latest
    restart: always
    volumes:
      - ./bw-data:/data
    ports:
      - "8080:8080" # Vault portal
      - "3012:3012/tcp" # Websocket
    environment:
      ROCKET_PORT: "8080"
      WEBSOCKET_PORT: "3012"
      WEBSOCKET_ADDRESS: "0.0.0.0"
      WEBSOCKET_ENABLED: "true" # Required to use websockets
      SIGNUPS_ALLOWED: "true" # set to false to disable signups
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "ZQpoXSKWI3ux3sV7AYFwMsN5uplvofXyY/hr1Uofqw0xBsayLXgnxxZepZSiL3Ur" # doesn't work here, but works when put as first item
      SMTP_HOST: [redacted]
      SMTP_FROM: [redacted]
      SMTP_PORT: [redacted]
      SMTP_SSL: "true"
      SMTP_USERNAME: [redacted]
      SMTP_PASSWORD: [redacted]
      SHOW_PASSWORD_HINT: "false"

I ran env inside the container and the ADMIN_TOKEN variable is set:

ROCKET_WORKERS=10
SMTP_SSL=true
SHOW_PASSWORD_HINT=false
HOSTNAME=68b6952df777
WEBSOCKET_ADDRESS=0.0.0.0
SMTP_FROM=[redacted]
SMTP_PASSWORD=[redacted]
WEBSOCKET_PORT=3012
ROCKET_ENV=staging
PWD=/
HOME=/root
WEBSOCKET_ENABLED=true
SMTP_HOST=[redacted]
SIGNUPS_ALLOWED=true
ADMIN_TOKEN=ZQpoXSKWI3ux3sV7AYFwMsN5uplvofXyY/hr1Uofqw0xBsayLXgnxxZepZSiL3Ur
INVITATIONS_ALLOWED=true
ROCKET_PORT=8080
TERM=xterm
SMTP_USERNAME=[redacted]
SHLVL=1
WEB_VAULT_ENABLED=true
SMTP_PORT=587
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
_=/usr/bin/env

Originally created by @mohammed90 on GitHub (Feb 16, 2019). This is a weird bug that threw me off for a long time. At first I thought it might be related to #359, but now it seems like something else. The docker-compose file here doesn't enable the `/admin` path, despite the ADMIN_TOKEN being set. You'll keep getting 404. It's definitely set because it shows when I ran `env` inside the container. Here's where it gets freaky, it works if I move the `ADMIN_TOKEN` to the top of the list, i.e. before `ROCKET_PORT`. ```yaml version: "3" services: bitwarden: image: mprasil/bitwarden:latest restart: always volumes: - ./bw-data:/data ports: - "8080:8080" # Vault portal - "3012:3012/tcp" # Websocket environment: ROCKET_PORT: "8080" WEBSOCKET_PORT: "3012" WEBSOCKET_ADDRESS: "0.0.0.0" WEBSOCKET_ENABLED: "true" # Required to use websockets SIGNUPS_ALLOWED: "true" # set to false to disable signups INVITATIONS_ALLOWED: "true" ADMIN_TOKEN: "ZQpoXSKWI3ux3sV7AYFwMsN5uplvofXyY/hr1Uofqw0xBsayLXgnxxZepZSiL3Ur" # doesn't work here, but works when put as first item SMTP_HOST: [redacted] SMTP_FROM: [redacted] SMTP_PORT: [redacted] SMTP_SSL: "true" SMTP_USERNAME: [redacted] SMTP_PASSWORD: [redacted] SHOW_PASSWORD_HINT: "false" ``` I ran `env` inside the container and the ADMIN_TOKEN variable is set: ``` ROCKET_WORKERS=10 SMTP_SSL=true SHOW_PASSWORD_HINT=false HOSTNAME=68b6952df777 WEBSOCKET_ADDRESS=0.0.0.0 SMTP_FROM=[redacted] SMTP_PASSWORD=[redacted] WEBSOCKET_PORT=3012 ROCKET_ENV=staging PWD=/ HOME=/root WEBSOCKET_ENABLED=true SMTP_HOST=[redacted] SIGNUPS_ALLOWED=true ADMIN_TOKEN=ZQpoXSKWI3ux3sV7AYFwMsN5uplvofXyY/hr1Uofqw0xBsayLXgnxxZepZSiL3Ur INVITATIONS_ALLOWED=true ROCKET_PORT=8080 TERM=xterm SMTP_USERNAME=[redacted] SHLVL=1 WEB_VAULT_ENABLED=true SMTP_PORT=587 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin _=/usr/bin/env ```

OVERLORD closed this issue

2026-02-04 18:50:32 +03:00

OVERLORD commented

2026-02-04 18:50:36 +03:00

@mprasil commented on GitHub (Feb 16, 2019):

Can you start with docker compose that has the ADMIN_TOKEN in the wrong place and see if you really see the variable in the docker inspect output?

I can't imagine a scenario where the order of the variables would matter, because at the end of the day they are just variables set for the process and as such they don't really have order. And if it does, this really sounds like docker-compose problem. But let's see if something else is at play here.

@mprasil commented on GitHub (Feb 16, 2019): Can you start with docker compose that has the `ADMIN_TOKEN` in the wrong place and see if you really see the variable in the `docker inspect` output? I can't imagine a scenario where the order of the variables would matter, because at the end of the day they are just variables set for the process and as such they don't really have order. And if it does, this really sounds like docker-compose problem. But let's see if something else is at play here.

OVERLORD commented

2026-02-04 18:50:45 +03:00

@dani-garcia commented on GitHub (Feb 16, 2019):

I had a similar problem with the .env file, I was setting the SMTP_FROM_NAME as a value with spaces but no quotes, and that broke the env loading, any variables after that one would stop loading.

Like this would make the third one not load:

#.env
FIRST=abc
SECOND=def ghi
THIRD=jkl

That was specific about the .env file, but maybe this is similar?

Otherwise, I have no idea where this could come from, the order the variables are set doesn't influence anything.

I would do what @mprasil said, and I'd also test if it only works on the first position. Do something like move it one position back each time to see when it breaks.

@dani-garcia commented on GitHub (Feb 16, 2019): I had a similar problem with the .env file, I was setting the SMTP_FROM_NAME as a value with spaces but no quotes, and that broke the env loading, any variables after that one would stop loading. Like this would make the third one not load: ```sh #.env FIRST=abc SECOND=def ghi THIRD=jkl ``` That was specific about the .env file, but maybe this is similar? Otherwise, I have no idea where this could come from, the order the variables are set doesn't influence anything. I would do what @mprasil said, and I'd also test if it only works on the first position. Do something like move it one position back each time to see when it breaks.

OVERLORD commented

2026-02-04 18:50:52 +03:00

@mohammed90 commented on GitHub (Feb 16, 2019):

Okay, I'm not able to reproduce it now even though I was able to do it constantly before creating the issue. Not sure whether I unknowingly changed something more. Anyways, I'll close this now and will come back with more stuff if it recurs.

@mohammed90 commented on GitHub (Feb 16, 2019): Okay, I'm not able to reproduce it now even though I was able to do it constantly before creating the issue. Not sure whether I unknowingly changed something more. Anyways, I'll close this now and will come back with more stuff if it recurs.

OVERLORD referenced this issue

2026-02-05 04:51:38 +03:00

[PR #233] [MERGED] Update PROXY.md #2649

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#233