Ir al contenido
#0924
Containers

The customer's Settings page writes their environment

Your Settings page has a toggle for beta search. On a shared-tenant app, that toggle is a row in a settings table, a cache in front of it, and an if (customer.flags.includes('beta-search')) in every handler that cares.

Here each customer runs in their own container, and the toggle does PUT /api/v1/containers/{id}/env with {"FEATURE_FLAGS": "beta-search"}. Merge semantics: the key you send is updated, the keys you don't send stay. The value lands in the container runtime and in /etc/environment. Anything that starts after the write sees it; anything already running keeps the old value until it restarts. Keys starting with HOODY_ are refused, so a customer's settings can never shadow the platform's.

Your code reads process.env.FEATURE_FLAGS. It doesn't know which customer it is, because it doesn't need to.

There is no settings table, only the customer's machine, and machines have environments.