diff --git a/content/features/developer-tools.md b/content/features/developer-tools.md
index 487e2e5..909c3c5 100644
--- a/content/features/developer-tools.md
+++ b/content/features/developer-tools.md
@@ -52,3 +52,21 @@ See [Privacy & Crash Reporting](../privacy) for information on enabling or disab
 # In-App Bug Report
 
 Type `/bugreport` in any room's compose box to open the bug report form. This prefills a GitHub issue template with your description and optionally attaches your recent debug log export.
+
+# Features & Experiments
+
+The **Features & Experiments** panel (Settings → Developer Tools → Features & Experiments) shows
+the feature flags and A/B experiments defined in your deployment's `config.json`.
+
+For each configured experiment you can see:
+
+- **Enabled** — whether the experiment is active for any users
+- **Rollout** — the percentage of users enrolled
+- **Your Variant** — the variant you have been assigned, and whether you are in the
+  experiment group or the control group
+
+This is useful for verifying that a flag was deployed correctly, or for confirming which arm
+of an experiment you are currently in.  Variant assignment is deterministic: the same account
+always receives the same variant for a given experiment key, across devices and sessions.
+
+See [Installation → Feature flag and experiment configuration](../installation/#feature-flag-and-experiment-configuration) for how operators define experiments.
diff --git a/content/installation/_index.md b/content/installation/_index.md
index 7119295..ba07d0d 100644
--- a/content/installation/_index.md
+++ b/content/installation/_index.md
@@ -61,3 +61,48 @@ After that, you can copy the dist/ directory to your server and serve it.
 
 * To deploy on subdirectory, you need to rebuild the app youself after updating the `base` path in [`build.config.ts`](build.config.ts).
     * For example, if you want to deploy on `https://sable.moe/app`, then set `base: '/app'`.
+
+## Injecting config at build time
+
+If you build Sable in a CI/CD pipeline, you can inject `config.json` overrides without
+editing the file directly. Set the `CLIENT_CONFIG_OVERRIDES_JSON` environment variable to
+a JSON object before running `pnpm run build`; the build script will deep-merge it into the
+bundled `config.json`.
+
+```sh
+export CLIENT_CONFIG_OVERRIDES_JSON='{"defaultHomeServer": "matrix.example.com"}'
+pnpm run build
+```
+
+Set `CLIENT_CONFIG_OVERRIDES_STRICT=true` to make the build fail hard if the JSON is
+malformed (useful in CI where silent failures are dangerous).
+
+### Feature flag and experiment configuration
+
+The `experiments` block in `config.json` lets server operators define feature flags with
+optional percentage-based rollout.  Each key is a free-form experiment name; the value
+controls who gets it.
+
+```json
+{
+  "experiments": {
+    "myFeature": {
+      "enabled": true,
+      "rolloutPercentage": 50,
+      "variants": ["treatment-a", "treatment-b"],
+      "controlVariant": "control"
+    }
+  }
+}
+```
+
+| Field | Type | Description |
+|---|---|---|
+| `enabled` | boolean | Master switch; `false` means no users receive the experiment |
+| `rolloutPercentage` | number (0–100) | Percentage of users bucketed into the experiment |
+| `variants` | string[] | Names for each treatment arm |
+| `controlVariant` | string | The variant name given to users outside the rollout |
+
+Bucketing is deterministic and stable: the same user always receives the same variant for
+a given experiment key.  You can see your current variant assignments in
+**Settings → Developer Tools → Features & Experiments**.