**Implementing Option A (per-request DB swap via monkey-patching) now.** A cleaner upstream refactor (contextvars-based dependency injection) is sketched below and will be proposed to redimp as a separate PR. Option A is throwaway work if the upstream refactor lands, but unblocks per-wiki permissions immediately.

| Component | Swapped? | How |

|-----------|----------|-----|

| GitStorage | Yes | Monkey-patches `storage` across 7 modules |

| GitHttpServer | Yes | Recreated per-request |

| `app.config["REPOSITORY"]` | Yes | Direct assignment |

| SQLAlchemy `db` | **No** | All wikis share one DB |

| `app_renderer` | No | Created once at import time |

| Flask-Mail | No | Never swapped |

| `app.config` (other keys) | No | SITE_NAME, permissions, etc. are global |

1. Resolver calls `_swap_database(wiki_slug)` after `_swap_storage(repo_path)`

2. Updates `app.config["SQLALCHEMY_DATABASE_URI"]` to `sqlite:////srv/data/wikis/{slug}/wiki.db`

3. Calls `db.engine.dispose()` to close connections to previous DB

4. Lazy-creates `wiki.db` with schema if it doesn't exist (first request)

5. Calls `update_app_config()` to reload Preferences into `app.config`

Raw SQL in management API (avoids importing Otterwiki's server.py). Creates 4 tables matching `otterwiki/models.py`: `preferences`, `drafts`, `user`, `cache`. Seeds `SITE_NAME`.

**Platform ACLs remain authoritative.** ProxyHeaderAuth trusts proxy headers, ignores READ_ACCESS/WRITE_ACCESS. No change to auth flow. Per-wiki Preferences used only for wiki appearance/behavior settings.

Already handled — resolver injects `@handle` in the email header field. No User table rows needed under ProxyHeaderAuth.

Lazy: if `wiki.db` doesn't exist when resolver hits it, create and seed on the spot. No data migration from shared default DB.

- **Flask-SQLAlchemy engine caching**: `dispose()` + config update should work with FSA 3.x lazy engine creation. Fallback: access `db._engines` internals.

- **Worker model**: Assumes gunicorn sync workers. Async/threaded workers would race on global state.

- **`update_app_config()` side effects**: Recreates Flask-Mail per-call. Harmless.

- **Renderer**: Holds reference to `app.config` dict, so Preferences updates propagate. But `RENDERER_HTML_WHITELIST` parsed at init time won't update per-wiki.

- `get_storage()`, `get_db()`, `get_renderer()`, `get_mail()`, `get_githttpserver()`

- Each falls back to the current module-level singleton when no context override is set

- `wiki_context()` context manager sets overrides for a block

- `db` stays importable for model definitions (`db.Model`, `db.Column`)

- All `@app.route` decorators unchanged

- `models.py` unchanged

- `storage` → `get_storage()`

- `app.config[...]` → `current_app.config[...]`

- `db.session.X()` → `get_db().session.X()`

- One lazy-init fix for `_serializer` in `helper.py`

**PR 2** (wide, mechanical): Migrate remaining modules.

- Flask best practice: `current_app` over direct `app` import

- Plugin flexibility: temporary renderer/storage overrides

- Backward compatible: getters fall back to singletons

- Read-heavy workload

- Single VPS, tens-to-hundreds of tenants

- Already using SQLite with per-wiki git repos