Skip to content

Update refactor and compose consistency to templates - #283

Open
michaelhodges wants to merge 8 commits into
tailscale-dev:mainfrom
michaelhodges:update_env
Open

michaelhodges wants to merge 8 commits into
tailscale-dev:mainfrom
michaelhodges:update_env

Conversation

@michaelhodges

Copy link
Copy Markdown
Contributor

[Service Name]: [Summary of changes]

Refactor environment variables.
Edit compose to match template formate

Description

Edit compose files so they are consistent with template layout.
Now users should only have to edit .env file to get a container running.

Related Issues

  • None.

Verification

Checklist

  • I have performed a self-review of my code and followed the templates structure.
  • I have added verification that the stack works as expected.
  • I have updated necessary documentation (e.g. frontpage README.md ).
  • I have selected the correct label(s) for this PR.

Additional Context

  • None.

github-actions Bot and others added 2 commits April 18, 2026 20:33
Edit compose files to match template. (volumes, enviroment, restart ect..)

@michaelhodges michaelhodges left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crypt0rr
I know this is a lot but it should make it easier for users as they only have to edit .env
Also compose files are now consistant with template

michaelhodges and others added 3 commits April 21, 2026 20:00
@crypt0rr
crypt0rr self-requested a review April 27, 2026 07:46
@crypt0rr crypt0rr added the enhancement New feature, change or request label Apr 27, 2026
@crypt0rr

Copy link
Copy Markdown
Collaborator

@crypt0rr I know this is a lot but it should make it easier for users as they only have to edit .env Also compose files are now consistant with template

Thank you for the suggestion, will have a look later today, I need to do a small test to make sure this approach doesn't introduce errors. When a pointing variable in the compose is not made available anywhere, I think this by default throws an error.

@michaelhodges

michaelhodges commented Apr 27, 2026 via email

Copy link
Copy Markdown
Contributor Author

@crypt0rr

Copy link
Copy Markdown
Collaborator

Alright, so it created warning lines when variables are present but not set, defaulting to a blank string. In case of actual-budget, the app runs fine. But, if a blank "" is set, and the application expects a value of some sort, it may break downstream...

$ docker compose config 
WARN[0000] The "ACTUAL_HTTPS_KEY" variable is not set. Defaulting to a blank string. 
WARN[0000] The "ACTUAL_HTTPS_CERT" variable is not set. Defaulting to a blank string. 
name: actualbudget
services:
  application:
    container_name: app-actual-budget
    depends_on:
      tailscale:
        condition: service_healthy
        required: true
    environment:
      ACTUAL_HTTPS_CERT: ""
      ACTUAL_HTTPS_KEY: ""
      ACTUAL_PORT: "5006"
      ACTUAL_UPLOAD_FILE_SIZE_LIMIT_MB: "20"
      ACTUAL_UPLOAD_FILE_SYNC_SIZE_LIMIT_MB: "20"
      ACTUAL_UPLOAD_SYNC_ENCRYPTED_FILE_SYNC_SIZE_LIMIT_MB: "50"
      PGID: "1000"
      PUID: "1000"
      TZ: Europe/Amsterdam
    healthcheck:
      test:
        - CMD-SHELL
        - node src/scripts/health-check.js
      timeout: 10s
      interval: 1m0s
      retries: 3
      start_period: 20s
    image: docker.io/actualbudget/actual-server:latest
    network_mode: service:tailscale
    restart: always
    volumes:
      - type: bind
        source: /home/docker-user/actualbudget/actual-budget-data
        target: /data
        bind: {}
  tailscale:
    cap_add:
      - net_admin
    configs:
      - source: ts-serve
        target: /config/serve.json
    container_name: tailscale-actual-budget
    devices:
      - source: /dev/net/tun
        target: /dev/net/tun
        permissions: rwm
    environment:
      TS_AUTH_ONCE: "true"
      TS_AUTHKEY: tskey-auth-k7Q4c1uu[...REDACTED...]7enGxA9P
      TS_ENABLE_HEALTH_CHECK: "true"
      TS_LOCAL_ADDR_PORT: 127.0.0.1:41234
      TS_SERVE_CONFIG: /config/serve.json
      TS_STATE_DIR: /var/lib/tailscale
      TS_USERSPACE: "false"
    hostname: actual-budget
    healthcheck:
      test:
        - CMD
        - wget
        - --spider
        - -q
        - http://127.0.0.1:41234/healthz
      timeout: 10s
      interval: 1m0s
      retries: 3
      start_period: 10s
    image: tailscale/tailscale:latest
    networks:
      default: null
    restart: always
    volumes:
      - type: bind
        source: /home/docker-user/actualbudget/config
        target: /config
        bind: {}
      - type: bind
        source: /home/docker-user/actualbudget/ts/state
        target: /var/lib/tailscale
        bind: {}
networks:
  default:
    name: actualbudget_default
configs:
  ts-serve:
    name: actualbudget_ts-serve
    content: |
      {"TCP":{"443":{"HTTPS":true}},
      "Web":{"$${TS_CERT_DOMAIN}:443":
          {"Handlers":{"/":
          {"Proxy":"http://127.0.0.1:5006"}}}},
      "AllowFunnel":{"$${TS_CERT_DOMAIN}:443":false}}

@michaelhodges

michaelhodges commented Apr 29, 2026 via email

Copy link
Copy Markdown
Contributor Author

@crypt0rr

Copy link
Copy Markdown
Collaborator

If an application requires a variable to be set then it requires it and it should be declared in the .env file.
…
-- Michael Hodges
On Wed, Apr 29, 2026, 9:59 AM Bart @.> wrote: crypt0rr left a comment (tailscale-dev/ScaleTail#283) <#283 (comment)> Alright, so it created warning lines when variables are present but not set, defaulting to a blank string. In case of actual-budget, the app runs fine. But, if a blank "" is set, and the application expects a value of some sort, it may break downstream... $ docker compose config WARN[0000] The "ACTUAL_HTTPS_KEY" variable is not set. Defaulting to a blank string. WARN[0000] The "ACTUAL_HTTPS_CERT" variable is not set. Defaulting to a blank string. name: actualbudget services: application: container_name: app-actual-budget depends_on: tailscale: condition: service_healthy required: true environment: ACTUAL_HTTPS_CERT: "" ACTUAL_HTTPS_KEY: "" ACTUAL_PORT: "5006" ACTUAL_UPLOAD_FILE_SIZE_LIMIT_MB: "20" ACTUAL_UPLOAD_FILE_SYNC_SIZE_LIMIT_MB: "20" ACTUAL_UPLOAD_SYNC_ENCRYPTED_FILE_SYNC_SIZE_LIMIT_MB: "50" PGID: "1000" PUID: "1000" TZ: Europe/Amsterdam healthcheck: test: - CMD-SHELL - node src/scripts/health-check.js timeout: 10s interval: 1m0s retries: 3 start_period: 20s image: docker.io/actualbudget/actual-server:latest network_mode: service:tailscale restart: always volumes: - type: bind source: /home/docker-user/actualbudget/actual-budget-data target: /data bind: {} tailscale: cap_add: - net_admin configs: - source: ts-serve target: /config/serve.json container_name: tailscale-actual-budget devices: - source: /dev/net/tun target: /dev/net/tun permissions: rwm environment: TS_AUTH_ONCE: "true" TS_AUTHKEY: tskey-auth-k7Q4c1uu[...REDACTED...]7enGxA9P TS_ENABLE_HEALTH_CHECK: "true" TS_LOCAL_ADDR_PORT: 127.0.0.1:41234 TS_SERVE_CONFIG: /config/serve.json TS_STATE_DIR: /var/lib/tailscale TS_USERSPACE: "false" hostname: actual-budget healthcheck: test: - CMD - wget - --spider - -q - http://127.0.0.1:41234/healthz timeout: 10s interval: 1m0s retries: 3 start_period: 10s image: tailscale/tailscale:latest networks: default: null restart: always volumes: - type: bind source: /home/docker-user/actualbudget/config target: /config bind: {} - type: bind source: /home/docker-user/actualbudget/ts/state target: /var/lib/tailscale bind: {} networks: default: name: actualbudget_default configs: ts-serve: name: actualbudget_ts-serve content: | {"TCP":{"443":{"HTTPS":true}}, "Web":{"$${TS_CERT_DOMAIN}:443": {"Handlers":{"/": {"Proxy":"http://127.0.0.1:5006"}}}}, "AllowFunnel":{"$${TS_CERT_DOMAIN}:443":false}} — Reply to this email directly, view it on GitHub <#283 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZM4H3QYXKNOVFHQNMGJ2T4YG765AVCNFSM6AAAAACYBLCZNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBSGIZDQOBYG4 . You are receiving this because you were assigned.Message ID: @.>

We agree on that. However, if an application has a default value of, for instance, ”false”, and we set an empty variable that reflects in ””, the application might behave unexpectedly, right?

@michaelhodges

michaelhodges commented Apr 29, 2026 via email

Copy link
Copy Markdown
Contributor Author

@jackspiering

Copy link
Copy Markdown
Collaborator

Hi @michaelhodges, thanks again for this big consistency pass, and sorry it has been waiting so long. In the meantime main has moved on a lot: the service template was updated, and the TZ (#356, #357) and health check changes landed. This branch now conflicts with main in 72 of its 104 files.

If you'd still like to continue, here is what would make it reviewable and mergeable (see CONTRIBUTING.md and the current service template):

  1. Split it into small PRs, for example one per service or a handful of related services. Each one then needs only a short review and a docker compose config --quiet check, and conflicts stay small.

  2. Start each one from the latest main instead of rebasing this branch. That is probably faster than resolving 72 conflicts.

  3. Resolve the empty-variable issue that @crypt0rr raised. When a variable is commented out in .env but still listed in compose.yaml, the app receives an empty string instead of its own default. For example, ACTUAL_HTTPS_KEY= in actual-budget can switch on behavior the user never asked for. Two options:

    • keep optional settings commented out in compose.yaml (as before), or
    • give them the upstream default in compose.yaml, for example ${ACTUAL_PORT:-5006}.

    Only move a variable into .env when the user has to set it.

  4. Report per PR what you tested: at least docker compose config --quiet, and for services you changed in behavior, that the stack still starts.

If you don't have time for this anymore, no worries. Just let us know and we'll close this PR. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature, change or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants