Skip to content

feat(worker): operator settings that survive a reinstall (worker.local.env) - #176

Merged
marinom2 merged 1 commit into
mainfrom
feat/worker-local-env
Jul 29, 2026
Merged

feat(worker): operator settings that survive a reinstall (worker.local.env)#176
marinom2 merged 1 commit into
mainfrom
feat/worker-local-env

Conversation

@marinom2

Copy link
Copy Markdown
Owner

Adding anything to the worker's environment currently means editing the container by hand — and the next install from the app silently throws it away. The run command is generated fresh each time, so a manually-added -e flag disappears with the old container, and the operator has no way to know until a capability quietly stops being advertised.

The installer now applies <keys-dir>/../worker.local.env via --env-file when it exists.

Why a file, not a UI field: a credential typed into the app would travel through the generated script, and that script is streamed to the install log and rendered on screen. A file the operator writes once never passes through either.

Ordering matters: the flag goes before the -e flags this script emits, so script-managed values win. A stale local file must not be able to repoint RPC_URL and leave the worker talking to the wrong chain.

Windows builds the flag as an array rather than a string — splatting an empty string into a docker argument list leaves a stray empty arg, which docker rejects.


⚠️ Worth knowing: the worker binary reads SEARCH_ENABLED (with a D). strings /bin/worker lists SEARCH_ENABLED, SEARCH_MAX_RESULTS, SEARCH_TIMEOUT, TAVILY_API_KEY. The SEARCH_ENABLE spelling that circulates is read by nothing — the worker starts cleanly, looks healthy, and never advertises search. Might be worth correcting wherever that's documented.

Verified: tsc clean · 673 tests · eslint clean · bash -n parses the 667-line generated installer · a worker started from such a file reports the SEARCH_* vars with chain settings intact.

Adding anything to the worker's environment meant editing the container by hand,
and the next install from the app silently threw it away - the run command is
generated fresh each time, so any -e flag added manually disappeared with the old
container. The operator had no way to know until a capability quietly stopped
being advertised.

The installer now applies `<keys-dir>/../worker.local.env` via --env-file when it
exists. That covers web search (SEARCH_ENABLED, TAVILY_API_KEY,
SEARCH_MAX_RESULTS, SEARCH_TIMEOUT - all read by the worker binary today) and
anything similar later.

A file rather than a field in the UI, deliberately. A credential typed into the
app would travel through the generated script, and that script is streamed to the
install log and rendered on screen. A file the operator writes once never passes
through either.

The flag goes BEFORE the -e flags this script emits, so script-managed values win.
A stale local file must not be able to repoint RPC_URL or a registry address and
leave the worker talking to the wrong chain.

Windows builds the flag as an array instead of a string: splatting an empty string
into a docker argument list leaves a stray empty argument, which docker rejects.

Verified: tsc clean, 673 tests, eslint clean, `bash -n` parses the 667-line
generated installer, and a worker started from such a file reports the SEARCH_*
variables with the chain settings still intact.

Worth recording for whoever reads this next: the binary reads SEARCH_ENABLED,
with a D. `SEARCH_ENABLE` appears in some docs and is read by nothing - the worker
starts cleanly, looks healthy, and never advertises search.
@vercel

vercel Bot commented Jul 29, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
lightnode Ready Ready Preview, Comment Jul 29, 2026 1:03pm

Request Review

@marinom2
marinom2 merged commit 2f7fb61 into main Jul 29, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant