spike(ops): is a feature flag manager worth adopting, and is a free one viable here #318

New Issue

2026-09-08T12:09:24-05:00

bermudalamb commented

2026-09-08 12:09:24 -05:00

Investigate whether this project should adopt feature flag management, and if so whether a free option fits the constraints. Establish whether it is needed before comparing tools — the answer may be that it is not.

Why this is a spike and not a build

There is no CD here. Every change reaches production through a manual NAS rebuild, so the usual headline argument for flags — decouple deploy from release — buys less than it does on a pipeline that ships many times a day. What flags would actually buy on this project is narrower and worth naming honestly before shopping:

A kill switch. Turning something off without a rebuild. Given a rebuild is the slow, error-prone step in this project's history, this is probably the strongest case.
Shipping half-finished work behind a flag rather than holding a long-lived branch.
Per-environment behaviour without another env var and another compose entry.

Against that: this is a single-developer homelab. Flags have a real cost — every one is a branch in the code that has to be removed later, and stale flags are their own kind of debt.

The option that costs nothing

admin_settings already exists. It is a key/value store with an admin UI (backend/src/routes/adminSettings.ts, frontend/src/admin/Settings.tsx), it is already admin-configurable at runtime, and cart_expiry_hours already proves the pattern end to end.

A boolean flag in that table, read at request time, would deliver the kill-switch case with no new service, no new container, and no new dependency on the NAS. This should be the baseline every other option is measured against, not an afterthought — a spike that starts by comparing hosted platforms will find one and never ask whether the table already there was enough.

What it would not give: percentage rollouts, per-customer targeting, audit history, or a scheduled expiry. Whether any of those are actually wanted here is the question.

If a real tool is wanted

Constraints that rule things in and out: the NAS is CPU and RAM limited, Portainer manages the stacks, and cost should stay at zero. Anything needing its own Postgres plus Redis plus ClickHouse is a poor fit for the machine.

Candidates worth a look, roughly in order of how well they suit this environment:

Tool	Notes
Flipt	Lightest of the group — single binary, no heavy datastore requirement. Best fit for a NAS if a real tool is wanted at all.
Flagsmith	Open source, self-host free with no feature limits, Docker Compose deployment. Heavier than Flipt.
GrowthBook	Free self-hosted and a free cloud starter tier. Flags and experiments are designed together, which is more than this project needs today.
Unleash	Best known, but OSS Edge is sunsetting on 2026-12-31, after which self-hosters at scale need Enterprise Edge. Worth confirming what that means for a deployment this small before adopting — a free tool with a paid dependency arriving in three months is the wrong shape for this project.

A free hosted tier is also an option, but note it makes the storefront depend on a third party being reachable to decide behaviour, which is a new outage mode for a site that currently has none of those.

What to establish

Is there a concrete change now or soon that a flag would actually help ship? A spike that cannot name one should conclude "not yet".
Does admin_settings cover that case? If yes, the answer is probably no tool.
If not, what specifically is missing — targeting, rollout percentages, audit trail?
For any candidate: memory and container footprint on the NAS, whether it survives a restart cleanly, and what happens to the storefront when the flag service is down. Fail-safe behaviour matters more than features here — a flag service that takes the shop down when it is unreachable is worse than no flags.
Licence and the realistic cost trajectory, given the Unleash Edge change above.

Out of scope

Adopting anything. This is a spike; implementation is a separate issue if the answer is yes.

Done when

There is a short document under docs/ops/ saying whether flags are worth adopting here, what would carry them if so, and — if the answer is that admin_settings is sufficient — that written down too, so the question does not get reopened from scratch later.

Prices, tiers and the Unleash Edge sunset were checked on 2026-09-08 and are worth re-confirming at decision time.

Investigate whether this project should adopt feature flag management, and if so whether a free option fits the constraints. **Establish whether it is needed before comparing tools** — the answer may be that it is not. ## Why this is a spike and not a build There is no CD here. Every change reaches production through a manual NAS rebuild, so the usual headline argument for flags — decouple deploy from release — buys less than it does on a pipeline that ships many times a day. What flags would actually buy on this project is narrower and worth naming honestly before shopping: - **A kill switch.** Turning something off without a rebuild. Given a rebuild is the slow, error-prone step in this project's history, this is probably the strongest case. - **Shipping half-finished work behind a flag** rather than holding a long-lived branch. - **Per-environment behaviour** without another env var and another compose entry. Against that: this is a single-developer homelab. Flags have a real cost — every one is a branch in the code that has to be removed later, and stale flags are their own kind of debt. ## The option that costs nothing **`admin_settings` already exists.** It is a key/value store with an admin UI (`backend/src/routes/adminSettings.ts`, `frontend/src/admin/Settings.tsx`), it is already admin-configurable at runtime, and `cart_expiry_hours` already proves the pattern end to end. A boolean flag in that table, read at request time, would deliver the kill-switch case with no new service, no new container, and no new dependency on the NAS. **This should be the baseline every other option is measured against**, not an afterthought — a spike that starts by comparing hosted platforms will find one and never ask whether the table already there was enough. What it would not give: percentage rollouts, per-customer targeting, audit history, or a scheduled expiry. Whether any of those are actually wanted here is the question. ## If a real tool is wanted Constraints that rule things in and out: the NAS is CPU and RAM limited, Portainer manages the stacks, and cost should stay at zero. Anything needing its own Postgres plus Redis plus ClickHouse is a poor fit for the machine. Candidates worth a look, roughly in order of how well they suit this environment: | Tool | Notes | | --- | --- | | **Flipt** | Lightest of the group — single binary, no heavy datastore requirement. Best fit for a NAS if a real tool is wanted at all. | | **Flagsmith** | Open source, self-host free with no feature limits, Docker Compose deployment. Heavier than Flipt. | | **GrowthBook** | Free self-hosted and a free cloud starter tier. Flags and experiments are designed together, which is more than this project needs today. | | **Unleash** | Best known, but **OSS Edge is sunsetting on 2026-12-31**, after which self-hosters at scale need Enterprise Edge. Worth confirming what that means for a deployment this small before adopting — a free tool with a paid dependency arriving in three months is the wrong shape for this project. | A free hosted tier is also an option, but note it makes the storefront depend on a third party being reachable to decide behaviour, which is a new outage mode for a site that currently has none of those. ## What to establish - Is there a concrete change now or soon that a flag would actually help ship? A spike that cannot name one should conclude "not yet". - Does `admin_settings` cover that case? If yes, the answer is probably no tool. - If not, what specifically is missing — targeting, rollout percentages, audit trail? - For any candidate: memory and container footprint on the NAS, whether it survives a restart cleanly, and what happens to the storefront when the flag service is down. **Fail-safe behaviour matters more than features here** — a flag service that takes the shop down when it is unreachable is worse than no flags. - Licence and the realistic cost trajectory, given the Unleash Edge change above. ## Out of scope Adopting anything. This is a spike; implementation is a separate issue if the answer is yes. ## Done when There is a short document under `docs/ops/` saying whether flags are worth adopting here, what would carry them if so, and — if the answer is that `admin_settings` is sufficient — that written down too, so the question does not get reopened from scratch later. Prices, tiers and the Unleash Edge sunset were checked on 2026-09-08 and are worth re-confirming at decision time.

bermudalamb referenced this issue from a commit

2026-09-09 13:37:40 -05:00

docs(ops): feature flags are not worth a manager here (#318)

bermudalamb referenced a pull request that will close this issue

2026-09-09 13:37:58 -05:00

docs(ops): feature flags are not worth a manager here (#318) #329

bermudalamb closed this issue

2026-09-09 13:39:06 -05:00

bermudalamb referenced this issue from a commit

2026-09-09 13:39:25 -05:00

Merge pull request 'docs(ops): feature flags are not worth a manager here (#318)' (#329) from spike/318-feature-flags into main

Sign in to join this conversation.