diff --git a/.readme/static/borrowed/Icon_Stackable.svg b/.readme/static/borrowed/Icon_Stackable.svg
new file mode 100644
index 00000000..35e132a9
--- /dev/null
+++ b/.readme/static/borrowed/Icon_Stackable.svg
@@ -0,0 +1,20 @@
+<svg id="Ebene_1" data-name="Ebene 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 507.97 517.33">
+  <g>
+    <polygon points="0 44 0 115.99 254.37 71.99 254.37 0 0 44" style="fill: #0080bd"/>
+    <polygon points="0 325.52 0 397.52 254.37 353.52 254.37 281.53 0 325.52" style="fill: #0080bd"/>
+    <polygon points="254.37 72 507.97 113.59 507.97 41.61 254.37 0 254.37 72" style="fill: #b90069"/>
+    <polygon points="254.37 211.18 507.97 252.77 507.97 180.78 254.37 139.18 254.37 211.18" style="fill: #b90069"/>
+    <polygon points="254.37 517.33 507.96 517.33 507.96 461.14 254.37 419.55 254.37 517.33" style="fill: #b90069"/>
+    <polygon points="254.43 517.33 0.85 517.33 0.85 461.14 254.43 419.55 254.43 517.33" style="fill: #0080bd"/>
+    <polygon points="0.01 183.18 0.01 255.17 104.61 237.07 104.61 165.09 0.01 183.18" style="fill: #0080bd"/>
+    <polygon points="170.61 153.67 170.61 225.67 254.37 211.18 254.37 139.19 170.61 153.67" style="fill: #0080bd"/>
+    <polygon points="336.46 294.99 254.37 281.53 254.37 353.52 336.46 366.99 336.46 294.99" style="fill: #b90069"/>
+    <polygon points="507.97 113.59 403.19 96.4 403.19 163.59 507.97 113.59" style="fill: #245987"/>
+    <polygon points="507.97 252.77 403.19 235.58 403.19 302.62 507.97 252.77" style="fill: #245987"/>
+    <polygon points="507.97 394.84 403.19 377.65 403.19 444.19 507.97 394.84" style="fill: #245987"/>
+    <polygon points="0 115.99 104.61 165.09 104.5 97.92 0 115.99" style="fill: #245987"/>
+    <polygon points="0.01 255.17 104.61 307.49 104.61 236.48 0.01 255.17" style="fill: #245987"/>
+    <polygon points="0 397.52 104.61 444.11 104.5 379.52 0 397.52" style="fill: #245987"/>
+    <polygon points="507.97 394.84 507.97 319.8 403.19 302.62 403.19 377.65 507.97 394.84" style="fill: #b90069"/>
+  </g>
+</svg>
diff --git a/.readme/static/borrowed/stackable_overview.png b/.readme/static/borrowed/stackable_overview.png
new file mode 100644
index 00000000..0ef39130
Binary files /dev/null and b/.readme/static/borrowed/stackable_overview.png differ
diff --git a/AGENTS.md b/AGENTS.md
index 981cc176..f365ec4a 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,41 +1,63 @@
-# Instructions for Claude
+# Instructions for AI Agents
 
 ## Project Overview
 
-This is the **Stackable Unified Data Platform UI** - a SvelteKit application that serves as the first module of a unified platform UI for Stackable's data infrastructure. The initial module is a **Trino SQL query editor** with SSO, authorisation, and catalogue browsing.
+**Stackable Cockpit** is a SvelteKit application that serves as the web UI of the Stackable Data Platform. It is built as a set of modules behind a shared OIDC login:
 
-The application is designed with a **plugin/module architecture** so future Stackable services (trino-lb queue management, etc.) can be integrated as additional modules.
+- **Trino** — SQL editor (Monaco + ANTLR grammar) with catalogue browser and query lifecycle management
+- **Storage** — S3 file browser with preview, upload/download, archives, search and transfers (HDFS is a stub)
+- **Settings** — user-managed storage connections, stored in PostgreSQL
+- **Dashboard** with per-user bookmarks (stored in PostgreSQL) across modules
+
+The Trino connection is either fixed via `STACKABLE_COCKPIT_TRINO_URL` or entered per user on `/trino` and held in server memory.
+
+Further modules are added the same way: a route under `src/routes/(app)/<module>/`, server code under `src/lib/server/<module>/`, components under `src/lib/components/<module>/`.
 
 ## Tech Stack
 
-- **SvelteKit** with **Svelte 5** - Always use Svelte 5 syntax with runes (`$props`, `$state`, `$derived`, etc.)
-- **Tailwind CSS v4** - No tailwind.config.js file (uses CSS-based configuration)
-- **DaisyUI** - Use DaisyUI components/classes where possible for consistent UI - This is DaisyUI v5! A lot of classes you know about DON'T EXIST anymore. Check <https://daisyui.com/docs/upgrade/?lang=enj> if needed
-- **Icon Library** - Use **unplugin-icons** with the `material-symbols` icon set (`@iconify-json/material-symbols`). Import icons as virtual Svelte components: `import IconMenu from 'virtual:icons/material-symbols/menu'`.
-- **Monaco Editor** - SQL editor component (dynamic import, SSR-safe)
-- **ANTLR4** (antlr4ng) - Trino SQL parsing for syntax highlighting and code completion
-- **zod & superforms** - All forms are to use zod & superforms
-- **Generic OIDC** (openid-client) - Authentication via any OIDC provider
-- **OPA** - Authorisation / feature visibility
-- **prom-client** - Prometheus metrics, exposed at `/metrics`
+- **SvelteKit** with **Svelte 5** — always use runes (`$props`, `$state`, `$derived`, ...), adapter-node
+- **Tailwind CSS v4** — CSS-based configuration in `src/app.css`, no `tailwind.config.js`
+- **DaisyUI v5** — use its components/classes where possible. Many v4 classes no longer exist; check <https://daisyui.com/docs/upgrade/> if needed
+- **Icons** — `unplugin-icons` with the `material-symbols` set: `import IconMenu from 'virtual:icons/material-symbols/menu'`
+- **Monaco Editor** + **ANTLR** (`antlr-ng` generator, `antlr4ng` runtime, `antlr4-c3` completion) for Trino SQL
+- **zod + sveltekit-superforms** — all forms
+- **better-auth** with the `genericOAuth` plugin — authentication via any OIDC provider
+- **PostgreSQL + Drizzle ORM** — users/sessions, storage connections, bookmarks, recent searches, download manifests. See `docs/DATABASE.md`
+- **AWS SDK v3** — S3 storage access
+- **Paraglide-JS v2** — i18n
+- **pino** — logging; **prom-client** — Prometheus metrics at `/metrics`
 
 ## Project Structure
 
-This is a **single SvelteKit application** (not a monorepo).
+Single SvelteKit application (not a monorepo).
 
 ```text
 ├── src/
-│   ├── lib/              # Shared utilities, components, stores
-│   ├── routes/           # SvelteKit routes
-│   │   └── (app)/        # Authenticated app routes
-│   ├── app.css           # Global styles (Tailwind + DaisyUI)
-│   ├── app.d.ts          # Type declarations
-│   ├── app.html          # HTML template
-│   └── hooks.server.ts   # Server hooks (auth middleware)
-├── e2e/                  # Playwright E2E tests
-├── static/               # Static assets
-├── docker/Dockerfile     # Production container image
-└── CLAUDE.md             # AI assistant instructions
+│   ├── lib/
+│   │   ├── server/         # Server-only code: auth, db, logging, metrics, feature flags, trino/, storage/
+│   │   ├── components/     # Svelte components (shared ones at top level, per-module subfolders)
+│   │   ├── client/         # Client-only utilities
+│   │   ├── stores/         # Svelte stores (*.svelte.ts)
+│   │   ├── storage/        # Client-side storage module logic
+│   │   ├── editor/         # Monaco/ANTLR Trino SQL support (grammar/, generated/, completion/)
+│   │   ├── dashboard/      # Dashboard and bookmarks
+│   │   ├── types/          # Shared types
+│   │   ├── test-utils/     # Unit test helpers (e.g. mock-logger.ts)
+│   │   └── paraglide/      # Generated i18n code (do not edit)
+│   ├── routes/
+│   │   ├── (app)/          # Authenticated routes: trino, storage, settings, api
+│   │   ├── auth/           # Login/logout
+│   │   ├── healthz/        # Health check (public)
+│   │   └── metrics/        # Prometheus endpoint (public)
+│   ├── architecture-tests/ # Architecture fitness functions
+│   ├── test/               # Unit test setup and stubs
+│   └── hooks.server.ts     # Auth middleware, request logging, metrics
+├── messages/               # i18n message files (en.json, de.json)
+├── e2e/                    # Playwright E2E tests
+├── dev/                    # Local dev environment (kind cluster setup)
+├── deploy/helm/            # Helm chart
+├── docker/Dockerfile       # Production container image
+└── docs/                   # Further documentation
 ```
 
 ## Tech Debt
@@ -46,111 +68,84 @@ When introducing shortcuts, known issues, or deferred security work, file an iss
 
 ### Browser Compatibility
 
-- The application must work in both **Firefox** and **Chromium-based browsers** (Chrome, Edge).
-- Do not use browser-specific features or CSS without verifying cross-browser support.
-- E2E tests run on both Firefox and Chromium (desktop) plus a mobile Chromium viewport.
+The application must work in **Firefox** and **Chromium-based browsers**. Do not use browser-specific features or CSS without verifying cross-browser support. E2E tests run on both.
 
 ### CSS & Styling
 
-- **All UI must work in both light and dark mode automatically.** Never use hard-coded colours (e.g., `text-gray-700`, `bg-white`, `border-slate-200`). Always use DaisyUI semantic colour classes (`text-base-content`, `bg-base-100`, `bg-base-200`, `border-base-300`, `text-primary`, `bg-error`, etc.) and Tailwind opacity modifiers on those classes (`text-base-content/80`, `bg-primary/10`) so that colours adapt to the active theme.
-- **Secondary text uses `text-muted`** (defined in `src/app.css`), never `text-base-content` at 60% opacity or less, and never `text-muted` with an opacity: those fail the 4.5:1 contrast ratio in the light theme. `aria-hidden` is no exemption, sighted users still read hidden text. Lower opacities are only allowed on `aria-hidden` icon components that duplicate adjacent text; icons that show a state (e.g. an expand chevron) need 3:1 and also use `text-muted` (enforced by `npm run test:arch`).
-- **All pages and components must be mobile-friendly.** Use responsive Tailwind breakpoints (`sm:`, `md:`, `lg:`) and test layouts at mobile viewport widths. Navigation must be accessible on small screens.
-- Use Tailwind v4 `@source` directive for component CSS scanning
+- **Light and dark mode must work automatically.** Never use hard-coded colours (`text-gray-700`, `bg-white`, ...). Use DaisyUI semantic classes (`text-base-content`, `bg-base-200`, `border-base-300`, `text-primary`, `bg-error`, ...) with opacity modifiers (`text-base-content/80`) where needed.
+- **Secondary text uses `text-muted`** (defined in `src/app.css`), never `text-base-content` at 60 % opacity or less, and never `text-muted` with an opacity: both fail 4.5:1 contrast in the light theme. `aria-hidden` is no exemption. Lower opacities are only allowed on `aria-hidden` icon components that duplicate adjacent text; state icons (e.g. an expand chevron) need 3:1 and use `text-muted` too (enforced by `npm run test:arch`).
+- **Mobile-friendly**: use responsive breakpoints (`sm:`, `md:`, `lg:`) and check layouts at mobile widths. Navigation must work on small screens.
 
 ### Accessibility (WCAG 2.2 AA)
 
-The application must comply with **WCAG 2.2 AA**. This covers **BITV 2.0** (German accessibility regulation, based on WCAG 2.1 AA). The axe tests in `e2e/accessibility.spec.ts` check the WCAG 2.0, 2.1 and 2.2 A/AA rules. Key requirements:
+The application must comply with **WCAG 2.2 AA**, which covers **BITV 2.0** (based on WCAG 2.1 AA). The axe tests in `e2e/accessibility.spec.ts` check the WCAG 2.0, 2.1 and 2.2 A/AA rules.
 
-- **Semantic HTML**: Use correct elements (`<nav>`, `<main>`, `<header>`, `<button>`, `<a>`, headings in order). Never use `<div>` or `<span>` for interactive elements.
-- **Keyboard navigation**: All interactive elements must be reachable and operable via keyboard. Visible focus indicators are required.
-- **ARIA attributes**: Use `aria-label`, `aria-current`, `aria-disabled`, `aria-expanded`, `role` where semantic HTML is insufficient. Do not use ARIA to fix what semantic HTML can handle.
-- **Colour contrast**: Text must meet WCAG AA contrast ratios (4.5:1 normal text, 3:1 large text). Never convey information through colour alone.
-- **Target size**: Interactive targets must be at least 24×24 CSS px, or have enough spacing to undersized neighbours (WCAG 2.5.8).
-- **Form labels**: Every form control must have a visible, associated `<label>` (see label-element association rule below).
-- **Alt text**: Every `<img>` must have a meaningful `alt` attribute (or `alt=""` for decorative images).
-- **Language**: The `<html>` element must have a `lang` attribute. Use `lang` attributes on content in other languages.
-- **Screen reader support**: Ensure content is announced correctly. Hide decorative elements with `aria-hidden="true"`.
+- **Semantic HTML**: correct elements (`<nav>`, `<main>`, `<button>`, `<a>`, headings in order). Never use `<div>`/`<span>` for interactive elements.
+- **Keyboard navigation**: everything reachable and operable via keyboard, with visible focus indicators.
+- **ARIA** only where semantic HTML is insufficient (`aria-label`, `aria-current`, `aria-expanded`, ...).
+- **Colour contrast**: 4.5:1 for normal text, 3:1 for large text. Never convey information through colour alone.
+- **Target size**: interactive targets at least 24×24 CSS px, or enough spacing to undersized neighbours (WCAG 2.5.8).
+- **Form labels**: every control has a visible label, associated via `for`/`id` (see below).
+- **Alt text** on every `<img>` (`alt=""` for decorative images); hide decorative elements with `aria-hidden="true"`.
+- **Language**: `lang` on `<html>` and on content in other languages.
 
 ### Logging
 
-The project uses **pino** for structured JSON logging (server-side only).
-
-**Two usage patterns:**
+Server-side logging uses **pino** (structured JSON). Include logging at `debug` and `info` level as appropriate in server code.
 
-1. **Request-scoped** (in `+page.server.ts`, `+server.ts`, hooks) — use the logger from `event.locals`:
+- **Request-scoped** (`+page.server.ts`, `+server.ts`, hooks): `const log = event.locals.logger;`
+- **Module-level** (singletons, services): `const log = logger.child({ module: 'trino-client' });` with `import { logger } from '$lib/server/logging';`
 
-   ```typescript
-   const log = event.locals.logger;
-   log.info({ catalog_name: name }, 'Loading catalogue');
-   ```
+Levels: `trace` for request lifecycle noise, `debug` for operational detail, `info` for significant business events (login, query executed), `warn` for recoverable problems, `error` for failures needing investigation.
 
-2. **Module-level** (singletons, services) — create a child logger:
+Conventions:
 
-   ```typescript
-   import { logger } from '$lib/server/logging';
-   const log = logger.child({ module: 'trino-client' });
-   log.info({ trino_url: url }, 'Connecting to Trino');
-   ```
+- Context object first, message second: `log.info({ user_id }, 'User logged in')`
+- snake_case field names (`request_id`, `user_id`, `duration_ms`, `status_code`, ...)
+- Never log tokens, credentials or full request/session objects — add redaction paths to `src/lib/server/logging/redaction.ts`
 
-**Log level guidance:**
-
-- `trace` — request lifecycle noise and highly detailed diagnostics (for example request start/completion for successful requests)
-- `debug` — verbose operational detail (cache hits, query plans, non-request-flow diagnostics)
-- `info` — significant business events (user login, query executed, service discovered)
-- `warn` — recoverable problems needing attention (deprecated config, retry succeeded)
-- `error` — failures requiring investigation (unhandled exceptions, external service down)
-
-**Conventions:**
+### Metrics
 
-- Context object first, message string second: `log.info({ user_id }, 'User logged in')`
-- Use snake_case field names for queryability: `request_id`, `user_id`, `module`, `duration_ms`, `status_code`, `path`, `method`
-- Never log tokens, credentials, or full request/session objects directly — add redaction paths to `src/lib/server/logging/redaction.ts`
+`/metrics` is served by `src/routes/metrics/+server.ts`; HTTP request duration is tracked for all routes in `hooks.server.ts`. Define further metrics in `src/lib/server/metrics.ts` (server-only) for new API endpoints, background operations and external service calls.
 
 ### Monaco Editor
 
-- Always use **dynamic imports** to avoid SSR issues (`import('monaco-editor')`)
-- The editor must be loaded client-side only
-- Use the custom `trinosql` language registration for Trino SQL support
+- Monaco (and modules that import it, such as `trinosql.ts`) must be **dynamically imported** and loaded client-side only (SSR safety).
+- Use the custom `trinosql` language registration.
 
-### Updating the Trino SQL Grammar (ANTLR)
+### Updating the Trino SQL Grammar
 
-The grammar lives at `src/lib/editor/grammar/SqlBase.g4`. The authoritative source is the main Trino repository:
-
-```text
-core/trino-grammar/src/main/antlr4/io/trino/grammar/sql/SqlBase.g4
-```
-
-Fetch the latest version with:
+The grammar lives at `src/lib/editor/grammar/SqlBase.g4`. Its source is `core/trino-grammar/src/main/antlr4/io/trino/grammar/sql/SqlBase.g4` in the Trino repository:
 
 ```bash
 gh api "repos/trinodb/trino/contents/core/trino-grammar/src/main/antlr4/io/trino/grammar/sql/SqlBase.g4" \
   --jq '.download_url' | xargs curl -s -o src/lib/editor/grammar/SqlBase.g4
+npm run generate:antlr
 ```
 
-Then regenerate the TypeScript lexer/parser:
+Afterwards compare the token list in the generated `SqlBaseLexer.ts` against `src/lib/editor/tokenMap.ts`. Missing tokens fall back to the `'identifier'` scope (no colour); add them with an appropriate scope.
 
-```bash
-npm run generate:antlr
-```
+### Database
 
-After regeneration, compare the new token list against `src/lib/editor/tokenMap.ts`. Any token present in `SqlBaseLexer.ts` but missing from `tokenMap.ts` will fall back to `'identifier'` scope (no colour). Add missing tokens with an appropriate scope (`'keyword'`, `'delimiter'`, `'string'`, etc.).
+PostgreSQL via Drizzle ORM; schema in `src/lib/server/schema.ts` (better-auth tables in `auth-schema.ts`), migrations in `src/lib/server/migrations/`. Generate migrations with `npm run db:generate` and commit the SQL together with `meta/`. Migrations run automatically at startup, so never edit one that has already been released. See `docs/DATABASE.md`.
 
-### Metrics
+For **new features**, do not add data migrations or legacy-data compatibility paths unless persisted data or an external consumer already exists and requires it. Ask if unclear.
+
+### Feature Flags and Configuration
 
-The app exposes a Prometheus scrape endpoint at `/metrics` via `src/routes/metrics/+server.ts`. HTTP request duration is tracked automatically for all routes in `hooks.server.ts`.
+Environment variables are parsed with zod at startup using the helpers in `src/lib/env-schema.ts`; invalid values stop the server. Feature toggles and other settings live in separate modules:
 
-- **Adding custom metrics**: Define new counters, histograms, or gauges in `src/lib/server/metrics.ts` and import them in the relevant server-side code (e.g. track query execution counts, Trino errors, cache hits)
-- **Server-only**: Never import from `src/lib/server/metrics.ts` in client-side code or `.svelte` files
-- **When to add metrics**: New API endpoints, background operations, external service calls, and any operation where latency or error rates are operationally significant
+- **Feature flags**: `src/lib/server/feature-flags.ts`, client-visible `PUBLIC_*` flags in `src/lib/client/feature-flags.ts` (re-exported by the server where it enforces them)
+- **Limits and defaults**: `src/lib/client/config.ts` (`PUBLIC_*`), server-side ones per module (e.g. `src/lib/server/storage/config.ts`)
+
+Document new variables in `README.md` and `.env.example`; don't read `env` ad hoc.
 
 ### Code Style & Best Practices
 
-- Use spaces not tabs
-- Run npm run format
-- Use British English
-- **New Features**: Do not add database migrations, data migrations, or legacy-data compatibility paths for a new feature unless persisted data or an external consumer already exists and requires it. Ask before adding one if that need is unclear.
-- For the server side only: Always include logging at debug and info levels as appropriate
-- **Redirects**: Never wrap `throw redirect()` in try-catch. Put redirect AFTER try-catch to avoid it being caught.
+- Run `npm run format`.
+- British English.
+- Use `resolve()` from `$app/paths` for internal links and `goto` (`svelte/no-navigation-without-resolve`).
+- **Redirects**: never wrap `throw redirect()` in try-catch; put it after the try-catch.
 
   ```typescript
   try {
@@ -158,11 +153,11 @@ The app exposes a Prometheus scrape endpoint at `/metrics` via `src/routes/metri
   } catch (err) {
     return fail(500, { error: 'Failed' });
   }
-  throw redirect(303, '/path'); // Outside try-catch
+  throw redirect(303, '/path');
   ```
 
-- **Public Routes**: Update `hooks.server.ts` when adding unauthenticated pages. The `/metrics` endpoint is permanently public (Prometheus scraping) — never add auth in front of it.
-- **Label-Element Association**: Always explicitly associate `<label>` elements with their form controls using `for` and `id` attributes. Generate unique IDs with `$props.id()` (see <https://svelte.dev/docs/svelte/$props#$props.id()>). Never rely on implicit association (wrapping the input inside the label).
+- **Public routes**: add unauthenticated paths to `PUBLIC_PATHS` in `hooks.server.ts`. `/metrics` and `/healthz` are permanently public — never put auth in front of them.
+- **Label-element association**: always use `for`/`id`, with IDs from `$props.id()`. Never wrap the input in the label.
 
   ```svelte
   <script>
@@ -173,127 +168,95 @@ The app exposes a Prometheus scrape endpoint at `/metrics` via `src/routes/metri
   <input id="{uid}-name" class="input" />
   ```
 
-- **Modals**: Always use a shared `Modal` component. Never use raw `<dialog>` elements directly. Control modals with a boolean `$state` and `bind:open`.
-- **Date/Time Pickers**: Always use a shared `DateTimePicker` component. Never use native `<input type="date">` or `<input type="datetime-local">` elements.
+- **Modals**: use the shared `Modal` component with a boolean `$state` and `bind:open`. Never use `<dialog>` directly.
+- **Date/time pickers**: use the shared `DateTimePicker` component. Never use native date inputs.
 
 ### Internationalisation (i18n)
 
-The application uses **Paraglide-JS v2** for type-safe, compiler-based internationalisation. English is the default/fallback locale; German is also supported.
+English is the default/fallback locale; German is also supported.
 
-- **Message files**: All user-visible strings go in `messages/en.json` and `messages/de.json`. Both files must always have the same keys.
-- **Import pattern**: `import * as m from '$lib/paraglide/messages.js'` — then use `m.key_name()` in templates and script blocks.
-- **Key naming**: Use flat keys with a feature prefix and underscores, e.g. `dashboard_welcome`, `nav_dashboard`, `header_user_menu`.
-- **Reactivity**: Data structures containing translated strings (e.g. nav sections, page title maps) must use `$derived` so they update when the locale changes.
-- **No hardcoded strings**: Never hardcode user-visible strings in `.svelte` files. This includes text content, `aria-label`, `title`, `placeholder`, and `alt` attributes.
-- **Adding new strings**: Add the key to both `messages/en.json` and `messages/de.json`, then run `npx @inlang/paraglide-js compile --project ./project.inlang --outdir ./src/lib/paraglide` to regenerate typed message functions.
+- All user-visible strings go into `messages/en.json` **and** `messages/de.json` (same keys in both). This includes `aria-label`, `title`, `placeholder` and `alt`.
+- Use them via `import * as m from '$lib/paraglide/messages.js'` and `m.key_name()`.
+- Flat keys with a feature prefix: `dashboard_welcome`, `nav_dashboard`, `header_user_menu`.
+- Data structures containing translated strings must be `$derived` so they follow locale changes.
+- The Vite plugin compiles messages during `dev`/`build`. For `npm run check`/`lint` outside Vite, compile manually: `npx @inlang/paraglide-js compile --project ./project.inlang --outdir ./src/lib/paraglide`.
 
 ## Commands
 
 ### Node.js Version
 
-The required Node.js version is pinned in `.node-version` for CI and `.nvmrc` for NVM. Keep both files synchronised. Use `nvm` to install and activate it before running any `npm` commands — `npm` will hard-fail with engine errors otherwise (`.npmrc` sets `engine-strict=true`).
+The Node.js version is pinned in `.node-version` (CI) and `.nvmrc` (nvm); keep both in sync. Activate it with `nvm install && nvm use` before running `npm` — `.npmrc` sets `engine-strict=true`.
 
-```bash
-nvm install   # installs the version from .nvmrc
-nvm use       # activates it in the current shell
-```
+`.npmrc` also sets `min-release-age=7`: package versions published less than seven days ago don't resolve (supply-chain cooldown). Use `min-release-age-exclude` only for urgent fixes.
 
 ### Local Setup
 
-For a pre-configured local dev environment using OIDC, deploy & configure Keycloak and Trino on a kind cluster:
+Either copy `.env.example` to `.env` and point it at your own OIDC provider, PostgreSQL and Trino, or use the pre-configured kind environment:
 
 ```bash
-./dev/setup.sh           # Creates and configures Keycloak. Deploys Trino with OIDC authentication. Writes to .env.development which is used by dev server.
+./dev/setup.sh           # Requires a running kind cluster and stackablectl. Deploys Keycloak, Trino,
+                         # Garage (S3) and PostgreSQL, runs migrations and writes .env.development
+npm run dev              # Start dev server
+npm run build            # Build for production (npm run preview to serve it)
 ```
 
-### Development
+### Quality Checks (run after major changes)
 
 ```bash
-npm run dev              # Start dev server
+npm run format               # Format code
+npm run lint                 # prettier, eslint, svelte-check, knip, architecture tests
+pre-commit run --all-files   # All of the above plus markdownlint, yamllint, shellcheck,
+                             # actionlint, hadolint, typos, helm lint
 ```
 
-### Building
+### Enforced Rules
 
-```bash
-npm run build            # Build for production
-npm run preview          # Preview production build
-```
+Most conventions in this file are checked automatically; fix violations instead of disabling rules.
 
-### Quality Checks (run after major changes)
+- **ESLint** (`eslint.config.js`): no server imports from client code (`src/lib/client`, `stores`, `storage`, `editor`, `types`) and vice versa, file naming (PascalCase components, stores as `*.svelte.ts`), file size limits (`max-lines`), no `<dialog>` outside `Modal.svelte`, a subset of hard-coded colour classes (`bg-white`, `text-gray-*`, ...), no `console` in server code.
+- **Architecture tests** (`npm run test:arch`, `src/architecture-tests/`): no circular dependencies in `src/lib` and `src/routes`, i18n key parity and no unused message keys, no static English `aria-label`, no native date inputs, `<img>` with `alt`, no clickable `<div>`/`<span>`, no low-opacity `text-base-content` for text (use `text-muted`). `npm run test:arch:report` additionally writes dependency/metrics reports to `reports/`.
 
-```bash
-npm run format               # Format code
-pre-commit run --all-files   # Run all checks: lint (prettier + eslint + knip), type checking,
-                             # markdownlint, yamllint, shellcheck, actionlint, hadolint, helm lint
-```
+When you add a new architectural rule, prefer an ESLint rule; otherwise add a `.spec.ts` in `src/architecture-tests/` following the existing patterns.
 
 ### Dead Code (knip)
 
 ```bash
-npm run knip                 # Report unused files, exports, types and dependencies (part of npm run lint)
+npm run knip                 # Report unused files, exports, types and dependencies
 npm run knip:fix             # Remove unused exports and dependencies; review the diff and run npm install afterwards
 ```
 
-knip fails on unused files, exports, types and dependencies. Delete dead code rather than silencing knip. For genuine false positives, configure `knip.json`: add files that nothing imports statically (CLI scripts, config files) to `entry`, and packages loaded at runtime by name (e.g. `pino-pretty`) or used only outside the source tree (e.g. in the Dockerfile) to `ignoreDependencies`, each with a comment explaining why.
+Delete dead code rather than silencing knip. For genuine false positives, configure `knip.json`: add files nothing imports statically (CLI scripts, config files) to `entry`, and packages loaded at runtime by name (e.g. `pino-pretty`) or used only outside the source tree to `ignoreDependencies`, each with a comment explaining why.
 
-### Architecture Fitness Functions
+## Testing
+
+### Unit Tests
 
 ```bash
-npm run test:arch            # Run all architecture fitness function tests (~5 s)
-npm run test:arch:report     # Same, plus generate HTML dependency/metrics reports in /reports/
+npm run test:unit            # Vitest
+npm run test:unit:coverage   # With coverage (run in CI)
 ```
 
-Architecture tests live in `src/architecture-tests/*.spec.ts` and use [ArchUnitTS](https://github.com/LukasNiessen/ArchUnitTS) together with plain Node.js `fs` checks. They run in CI and must remain **green at all times**.
-
-**Run `npm run test:arch` whenever you:**
+Vitest has two projects (`vite.config.ts`):
 
-- Add a new file to `src/lib/server/` (verify it doesn't break client-boundary rules)
-- Add a new Svelte component (PascalCase naming and UI-pattern checks)
-- Add or remove message keys in `messages/en.json` (both locale files must stay in sync)
-- Refactor the Trino sub-layer (circular-dependency rules)
+- `client` — `*.svelte.test.ts` / `*.svelte.spec.ts`, run in headless Chromium (component and rune tests)
+- `server` — all other `*.test.ts` / `*.spec.ts`, run in Node
 
-**What the fitness functions enforce:**
+Place unit tests next to the code they test. Add them for new server logic, stores and non-trivial components. Every test must assert (`requireAssertions`); use `src/lib/test-utils/mock-logger.ts` when testing server code that logs. The client project needs the Playwright Chromium browser.
 
-| Category                 | What is checked                                                                                               |
-| ------------------------ | ------------------------------------------------------------------------------------------------------------- |
-| Server / Client Boundary | `src/lib/client`, `stores`, `storage`, `editor`, `types` must not import `src/lib/server/**`                  |
-| No Circular Dependencies | `src/lib/**` (excluding Trino) and `src/routes/**` must be cycle-free                                         |
-| Naming Conventions       | Stores → `*.svelte.ts`; lib components → PascalCase `.svelte`; server files → no `.svelte.ts` extension       |
-| Code Size Limits         | `.ts` files < 2 400 LOC; `.svelte` files < 1 100 LOC; test files < 1 000 LOC                                  |
-| UI Pattern Enforcement   | No native date inputs; `<img>` must have `alt`; no clickable `<div>` or `<span>` (with documented exceptions) |
-| i18n Compliance          | `messages/en.json` and `messages/de.json` must have the same keys; no static `aria-label="English text"`      |
-
-**Extending the fitness functions:**
-When you add a new architectural rule (e.g., a new layer, a new naming convention), add a new `.spec.ts` file in `src/architecture-tests/` following the existing patterns. Use archunit for TypeScript dependency/cycle rules and plain Node.js `fs` for content checks on Svelte files.
-
-### E2E Testing
+### E2E Tests
 
 ```bash
-npm run test:e2e         # Run all E2E tests
+npm run test:e2e             # Builds with .env.test, then runs Playwright
 ```
 
-## E2E Testing Guidelines
-
-E2E tests use **Playwright** and are located in `e2e/`.
-
-### When to Add Tests
-
-- **MANDATORY**: Always add E2E tests when creating new pages, UI features, or API endpoints. This is not optional - every frontend-visible feature must have corresponding E2E tests before the work is considered complete.
-- **Always** add tests for user flows (navigation, form submissions, filters)
-- **Always** add tests for API endpoints (status codes, response structure)
-- **Always** run `npm run test:e2e` after making UI changes to ensure nothing broke
+Plain `playwright test` serves a stale build. The E2E setup starts PostgreSQL and Garage via testcontainers (requires Docker) plus mock OIDC and mock Trino servers (`e2e/support/`).
 
-### When to Run Tests
-
-- Before committing UI changes
-- After modifying routes, layouts, or navigation
-- After changing form behaviour or validation
-- As part of quality checks before pushing
-
-### Writing Tests
+- **Mandatory**: every new page, UI feature or API endpoint needs E2E tests before the work is complete — user flows (navigation, forms, filters) and API endpoints (status codes, response structure).
+- Run the E2E tests after UI, route, layout or form changes, and before committing UI changes.
+- Import `test` and `expect` from `e2e/support/fixtures.ts`, not `@playwright/test`. Its worker-scoped fixture logs each worker in via the mock OIDC server as its own user, so parallel workers never share server-side state. Opt out with `test.use({ storageState: { cookies: [], origins: [] } })`.
 
 ```typescript
-import { test, expect } from '@playwright/test';
+import { test, expect } from './support/fixtures.js';
 
 test('example test', async ({ page }) => {
   await page.goto('/some-page');
@@ -301,14 +264,6 @@ test('example test', async ({ page }) => {
 });
 ```
 
-### Authentication
-
-Import `test` and `expect` from `e2e/support/fixtures.ts`, not `@playwright/test`. Its worker-scoped fixture logs each worker in via the mock OIDC server as its own user, so parallel workers never share server-side state. Opt out with `test.use({ storageState: { cookies: [], origins: [] } })`.
-
-## Important Notes
-
-- **Environment**: The app needs a `.env` file for proper env var access
-- **SSR Safety**: Monaco Editor and ANTLR must be dynamically imported to avoid SSR issues
-- **Service Discovery**: The app can auto-discover Trino instances via K8s API or use static configuration
+## Documentation
 
-For documentation tasks, always update both the primary document AND any related README files that reference it.
+When changing behaviour that is documented, update the related docs too: `README.md` (configuration, feature flags), `docs/`, `.env.example` and the Helm chart values.
diff --git a/README.md b/README.md
index 1e2b6c16..156c8704 100644
--- a/README.md
+++ b/README.md
@@ -1,89 +1,66 @@
-# Stackable Cockpit
+<p align="center">
+  <img width="150" src="./.readme/static/borrowed/Icon_Stackable.svg" alt="Stackable Logo"/>
+</p>
 
-[![License OSL 3.0](https://img.shields.io/badge/license-OSL--3.0-blue)](./LICENSE)
+<h1 align="center">Stackable Cockpit</h1>
 
-Stackable Cockpit is the unified web UI for the [Stackable Data Platform (SDP)](https://stackable.tech/).
-It provides a single place to work with the data services running on your platform.
-
-> [!WARNING]
-> Stackable Cockpit is experimental.
+[![Maintenance](https://img.shields.io/badge/Maintained%3F-yes-green.svg)](https://GitHub.com/stackabletech/cockpit/graphs/commit-activity)
+[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-green.svg)](https://docs.stackable.tech/home/stable/contributor/index.html)
+[![License OSL3.0](https://img.shields.io/badge/license-OSL3.0-green)](./LICENSE)
 
-## About The Stackable Data Platform
+[Stackable Data Platform](https://stackable.tech/) | [Platform Docs](https://docs.stackable.tech/) | [Discussions](https://github.com/orgs/stackabletech/discussions) | [Discord](https://discord.gg/7kZ3BNnCAF)
 
-This application is part of the Stackable Data Platform, a curated selection of best-of-breed data applications and tools that you can deploy and operate on Kubernetes.
-The platform builds on open-source projects and provides Kubernetes operators to manage them, including:
+Stackable Cockpit is the unified web UI for the Stackable Data Platform (SDP).
+It provides a single place to work with the data services running on your platform.
 
-- [Apache Airflow](https://github.com/stackabletech/airflow-operator)
-- [Apache Druid](https://github.com/stackabletech/druid-operator)
-- [Apache HBase](https://github.com/stackabletech/hbase-operator)
-- [Apache Hadoop HDFS](https://github.com/stackabletech/hdfs-operator)
-- [Apache Hive](https://github.com/stackabletech/hive-operator)
-- [Apache Kafka](https://github.com/stackabletech/kafka-operator)
-- [Apache NiFi](https://github.com/stackabletech/nifi-operator)
-- [OpenSearch](https://github.com/stackabletech/opensearch-operator)
-- [Apache Spark](https://github.com/stackabletech/spark-k8s-operator)
-- [Apache Superset](https://github.com/stackabletech/superset-operator)
-- [Trino](https://github.com/stackabletech/trino-operator)
-- [Apache ZooKeeper](https://github.com/stackabletech/zookeeper-operator)
+It is part of the Stackable Data Platform, a curated selection of the best open source data apps like Apache Kafka®, OpenSearch, Trino or Apache Spark™, [all](#other-operators) working together seamlessly. Based on Kubernetes, it runs everywhere – on prem or in the cloud.
 
-Read more about the platform in the [documentation](https://docs.stackable.tech/) and on the [Stackable Hub](https://hub.stackable.tech/).
+> [!WARNING]
+> Stackable Cockpit is experimental.
 
 ## Features
 
 - Single sign-on via any OIDC provider
 - Trino SQL query editor and schema browser, with queries submitted under the logged-in user's name
+- S3 file browser with preview, upload/download and search (opt-in, see [Feature Flags](#feature-flags))
+- User-managed storage connections, stored in PostgreSQL
+- Dashboard with bookmarks to frequently used tools
 
 More modules will be added over time.
 
-## Accessibility
+## Installation
 
-Stackable Cockpit targets [WCAG 2.2](https://www.w3.org/TR/WCAG22/) level AA.
-This is a superset of [BITV 2.0](https://www.gesetze-im-internet.de/bitv_2_0/), which is based on [WCAG 2.1](https://www.w3.org/TR/WCAG21/) level AA.
-As the project is still experimental, it may not fully meet these requirements yet.
-We treat every accessibility violation as a bug, so please [open an issue](https://github.com/stackabletech/cockpit/issues) if you find one.
-
-## Quick Start
-
-The required Node.js version is pinned in [`.node-version`](./.node-version).
+> [!IMPORTANT]
+> Serve Cockpit over HTTPS, because session cookies and credentials such as S3 keys pass through the browser connection.
+> Cockpit itself serves plain HTTP, so terminate TLS at an Ingress or reverse proxy (see [Ingress and reverse proxy](#ingress-and-reverse-proxy)).
 
-```bash
-# Install dependencies
-npm install
-
-# Start the development server (http://localhost:5173)
-npm run dev
-```
-
-Copy [`.env.example`](./.env.example) to `.env` and adjust the values for your OIDC provider and Trino endpoint.
-For a fully pre-configured local environment (Keycloak and Trino on a local kind cluster), see [`dev/setup.sh`](./dev/setup.sh).
+### Helm
 
-## Development
+A Helm chart for Kubernetes is included under [`deploy/helm/cockpit`](./deploy/helm/cockpit):
 
 ```bash
-npm run dev          # Start the dev server
-npm run build        # Build for production
-npm run preview      # Preview the production build
-
-npm run format       # Format all code
-npm run check        # Type checking
-npm run lint         # Linting
-npm run knip         # Report unused files, exports and dependencies
-npm run test:e2e     # Run the Playwright end-to-end tests
-
-npm run generate:antlr   # Regenerate the lexer/parser after editing the SQL grammar
+helm install cockpit ./deploy/helm/cockpit -f your-values.yaml
 ```
 
-## Deployment
+The chart needs an existing PostgreSQL database (`database.*` values). See the [chart README](./deploy/helm/cockpit/README.md) for the full list of values, and [docs/DATABASE.md](./docs/DATABASE.md) for the database settings, including TLS.
 
-### Helm
+#### Ingress and reverse proxy
 
-A Helm chart for Kubernetes is included under [`deploy/helm/cockpit`](./deploy/helm/cockpit):
+The chart creates a ClusterIP Service on port 3000.
+Expose it with the chart's `ingress` values, or put your own Ingress, Gateway or load balancer in front of the Service.
+Set `origin` and `auth.baseUrl` to the `https://` URL users open in the browser.
+Behind a reverse proxy, also set the forwarded headers Cockpit trusts:
 
-```bash
-helm install cockpit ./deploy/helm/cockpit -f your-values.yaml
+```yaml
+origin: https://cockpit.example.com
+auth:
+  baseUrl: https://cockpit.example.com
+proxy:
+  protocolHeader: x-forwarded-proto
+  hostHeader: x-forwarded-host
 ```
 
-The chart needs an existing PostgreSQL database (`database.*` values). See the [chart README](./deploy/helm/cockpit/README.md) for the full list of values, and [docs/DATABASE.md](./docs/DATABASE.md) for the database settings, including TLS.
+Only set the `proxy` headers if the proxy overwrites them, otherwise clients can spoof them.
 
 ### Docker
 
@@ -106,7 +83,7 @@ Invalid values (e.g. `abc` for an integer) stop the server at startup with an er
 | Variable                                            | Type                             | Default | Description                                                                                                                                                                             | Example                                                  |
 | --------------------------------------------------- | -------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
 | `STACKABLE_COCKPIT_COMPLETION_ENABLED`              | `boolean` (`"false"` to disable) | `true`  | Enables the SQL editor code-completion provider and the metadata endpoint. Set to `"false"` to fall back to plain syntax highlighting.                                                  | `STACKABLE_COCKPIT_COMPLETION_ENABLED=false`             |
-| `STACKABLE_COCKPIT_STORAGE_BROWSER_ENABLED`         | `boolean` (`"true"` to enable)   | `false` | Shows the S3/HDFS file browser in the sidebar and activates routes under `/storage`. Must be explicitly opted in to expose storage credentials and the file-browser UI.                 | `STACKABLE_COCKPIT_STORAGE_BROWSER_ENABLED=true`         |
+| `STACKABLE_COCKPIT_STORAGE_BROWSER_ENABLED`         | `boolean` (`"true"` to enable)   | `false` | Shows the S3 file browser in the sidebar and activates routes under `/storage`. Must be explicitly opted in to expose storage credentials and the file-browser UI.                      | `STACKABLE_COCKPIT_STORAGE_BROWSER_ENABLED=true`         |
 | `PUBLIC_STACKABLE_COCKPIT_STORAGE_TRANSFER_ENABLED` | `boolean` (`"true"` to enable)   | `false` | Shows Cut, Copy, Paste and Rename in the file browser and enables drag-and-drop move. When disabled, the server rejects copies, moves and renames via `/api/storage/transfer` with 404. | `PUBLIC_STACKABLE_COCKPIT_STORAGE_TRANSFER_ENABLED=true` |
 
 ### Storage Preview Limits
@@ -130,40 +107,101 @@ Invalid values (e.g. `abc` for an integer) stop the server at startup with an er
 | ----------------- | ---------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
 | `BODY_SIZE_LIMIT` | `string` (bytes) | `6M` in the container image (adapter: `512K`) | Maximum request body size accepted by the Node.js server ([adapter-node](https://svelte.dev/docs/kit/adapter-node#Environment-variables-BODY_SIZE_LIMIT)). Must be at least `PUBLIC_STACKABLE_COCKPIT_MAX_EDITABLE_FILE_SIZE`, otherwise saving larger files in the text editor fails. | `BODY_SIZE_LIMIT=12M` |
 
-## Documentation
+## Development
 
-- Platform documentation: <https://docs.stackable.tech/>
-- Stackable website: <https://stackable.tech/>
-- Stackable Hub: <https://hub.stackable.tech/>
+The required Node.js version is pinned in [`.node-version`](./.node-version).
+Copy [`.env.example`](./.env.example) to `.env` and adjust the values for your OIDC provider, PostgreSQL database and Trino endpoint.
+For a fully pre-configured local environment (Keycloak, Trino, Garage S3 and PostgreSQL on a local kind cluster), see [`dev/setup.sh`](./dev/setup.sh).
 
-## Contributing
+```bash
+npm install          # Install dependencies
+npm run dev          # Start the dev server (http://localhost:5173)
+npm run build        # Build for production
+npm run preview      # Preview the production build
 
-Contributions are welcome!
-Please open an issue or pull request.
-Before submitting changes, run the quality checks:
+npm run format       # Format all code
+npm run check        # Type checking
+npm run lint         # Linting
+npm run knip         # Report unused files, exports and dependencies
+npm run test:unit    # Run the Vitest unit tests
+npm run test:arch    # Run the architecture tests
+npm run test:e2e     # Run the Playwright end-to-end tests (requires Docker)
 
-```bash
-npm run format
-npm run check
-npm run lint
-npm run test:e2e
+npm run generate:antlr   # Regenerate the lexer/parser after editing the SQL grammar
 ```
 
-Contributions require agreeing to a Contributor License Agreement (CLA).
-When you open your first pull request, the CLA assistant will guide you through signing it.
+## Documentation
 
-## Support
+Database setup and migrations are described in [`docs/DATABASE.md`](./docs/DATABASE.md).
 
-- [GitHub Discussions](https://github.com/orgs/stackabletech/discussions)
-- [Discord](https://discord.gg/7kZ3BNnCAF)
-- [Commercial support plans](https://stackable.tech/en/plans/)
+The documentation for all Stackable products can be found at [docs.stackable.tech](https://docs.stackable.tech).
 
-## Sponsor
+If you have a question about the Stackable Data Platform, contact us via our [homepage](https://stackable.tech/) or ask a public question in our [Discussions forum](https://github.com/orgs/stackabletech/discussions).
+
+## Accessibility
+
+Stackable Cockpit targets [WCAG 2.2](https://www.w3.org/TR/WCAG22/) level AA.
+This is a superset of [BITV 2.0](https://www.gesetze-im-internet.de/bitv_2_0/), which is based on [WCAG 2.1](https://www.w3.org/TR/WCAG21/) level AA.
+As the project is still experimental, it may not fully meet these requirements yet.
+We treat every accessibility violation as a bug, so please [open an issue](https://github.com/stackabletech/cockpit/issues) if you find one.
+
+## About The Stackable Data Platform
+
+Stackable Cockpit is written and maintained by [Stackable](https://stackable.tech) and it is part of a larger data platform.
+
+![Stackable Data Platform Overview](./.readme/static/borrowed/stackable_overview.png)
+
+Stackable makes it easy to operate data applications in any Kubernetes cluster.
+
+The data platform offers many operators, new ones being added continuously. All our operators are designed and built to be easily interconnected and to be consistent to work with.
+
+The [Stackable GmbH](https://stackable.tech/) is the company behind the Stackable Data Platform. Offering professional services, paid support plans and custom development.
+
+We love open-source!
+
+## Other Operators
+
+These are the operators that are currently part of the Stackable Data Platform:
+
+- [Stackable Operator for Apache Airflow](https://github.com/stackabletech/airflow-operator)
+- [Stackable Operator for Apache Druid](https://github.com/stackabletech/druid-operator)
+- [Stackable Operator for Apache HBase](https://github.com/stackabletech/hbase-operator)
+- [Stackable Operator for Apache Hadoop HDFS](https://github.com/stackabletech/hdfs-operator)
+- [Stackable Operator for Apache Hive](https://github.com/stackabletech/hive-operator)
+- [Stackable Operator for Apache Kafka](https://github.com/stackabletech/kafka-operator)
+- [Stackable Operator for Apache NiFi](https://github.com/stackabletech/nifi-operator)
+- [Stackable Operator for OpenSearch](https://github.com/stackabletech/opensearch-operator)
+- [Stackable Operator for Apache Spark](https://github.com/stackabletech/spark-k8s-operator)
+- [Stackable Operator for Apache Superset](https://github.com/stackabletech/superset-operator)
+- [Stackable Operator for Trino](https://github.com/stackabletech/trino-operator)
+- [Stackable Operator for Apache ZooKeeper](https://github.com/stackabletech/zookeeper-operator)
+
+And our internal operators:
 
-If you find this project useful, consider [sponsoring Stackable](https://github.com/sponsors/stackabletech).
+- [Commons Operator](https://github.com/stackabletech/commons-operator)
+- [Listener Operator](https://github.com/stackabletech/listener-operator)
+- [OpenPolicyAgent Operator](https://github.com/stackabletech/opa-operator)
+- [Secret Operator](https://github.com/stackabletech/secret-operator)
+
+## Contributing
+
+Contributions are welcome.
+Follow our [Contributors Guide](https://docs.stackable.tech/home/stable/contributor/index.html) to learn how you can contribute.
+Before submitting changes, run the formatting, type checks, linting and end-to-end tests listed under [Development](#development).
+All contributors will have to sign a [Contributor License Agreement](https://github.com/stackabletech/.github/blob/main/cla.md).
+This is enforced automatically when you submit a Pull Request where a bot will guide you through the process.
 
 ## License
 
-Licensed under the [Open Software License version 3.0](./LICENSE).
+[Open Software License version 3.0](./LICENSE).
+
 This project bundles the Trino SQL grammar and code derived from it, which are licensed under the [Apache License, Version 2.0](./LICENSE-Apache-2.0).
 The relevant source files carry upstream attribution headers.
+
+## Support
+
+Get started with the community edition! If you want professional support, [we offer subscription plans and custom licensing](https://stackable.tech/en/plans/).
+
+## Sponsor
+
+If you want to support our work but don't need professional support please consider [sponsoring](https://github.com/sponsors/stackabletech) our work.
diff --git a/docs/DATABASE.md b/docs/DATABASE.md
index af7a40b5..14321de0 100644
--- a/docs/DATABASE.md
+++ b/docs/DATABASE.md
@@ -74,8 +74,9 @@ npm run db:migrate:run
 
 Migrations are stored in `src/lib/server/migrations/`.
 
-The current migration history is a single baseline migration. Existing databases
-created with the prior migration sequence must be reset before applying it.
+The migration history starts with a baseline migration (`0000_initial_schema.sql`).
+Databases created with the migration sequence from before that baseline must be reset.
+Never edit a migration that has already been released; migrations run automatically at startup.
 
 ## NPM Scripts