[Catalog] Add Formbricks

[onel]

App: Formbricks
Repo: https://github.com/formbricks/formbricks
Docs: https://formbricks.com/docs

Open-source survey and experience-management platform — build in-app, link, and website surveys; analyse responses with AI insights.

---

How to do this: follow Authoring catalog apps with an agent. Paste the prompt, append the inputs above, run it inside the malmo repo.

Gate findings (static screen, commit 9291f255c100):

GO (degraded) — four Gate D limitations to record in the manifest.

Compose architecture (7 services):

• pgvector/pgvector:pg18 — Postgres sidecar at elected uid 999 (brings pgvector extension; do NOT swap to managed Postgres — the migration requires pgvector and managed images don't have it)
• valkey/valkey — Redis-compatible cache sidecar (standard pattern)
• formbricks-migrate — init container (node migration script, exits cleanly)
• ghcr.io/formbricks/formbricks:latest — main Next.js app, runs as nextjs uid 1001 (clean)
• hub-migrate — init container for Hub (goose + river migrations)
• ghcr.io/formbricks/hub:latest — Formbricks Hub Go API, required
• cubejs/cube:v1.6.6 — semantic analytics layer, requires ./cube/cube.js and ./cube/schema/ config files mounted read-only (must be bundled in the catalog entry)

Key adapt notes:

• Postgres sidecar: set user: "999:999" so the official entrypoint skips chown+gosu — no stripped caps needed
• NEXTAUTH_SECRET, ENCRYPTION_KEY, CRON_SECRET, HUB_API_KEY, CUBEJS_API_SECRET all map to secrets: cleanly
• WEBAPP_URL / NEXTAUTH_URL → MALMO_APP_URL
• SMTP vars → MALMO_MAIL_*; declare mail: {optional: true}
• Boot-time: confirm SAML DB setup (create-saml-database.js) completes against the pgvector sidecar or fails gracefully when SAML is unconfigured

Gate D limitations to record:

1. Link surveys / external reachability — sharing survey URLs with respondents outside the LAN is broken until remote access ships; in-app and embedded surveys work on LAN (no-public-url, open)
2. OAuth callbacks link-local — WEBAPP_URL/NEXTAUTH_URL injected as .local mDNS; OAuth logins and email verification links break off-LAN (app-url-injection, same class as docuseal, open)
3. SMTP optional — maps to MALMO_MAIL_*; email verification and password reset disabled by default without SMTP (smtp-relay, mitigated)
4. Third-party integrations — Google Sheets, Airtable, Slack, Notion, social SSO (GitHub, Google, Azure AD, OIDC, SAML), EE enterprise license key all require operator-supplied env vars with no in-app config surface (operator-env-config, open)

Done when:

• catalog/<id>/manifest.yml and catalog/<id>/compose.yml exist
• go run ./cmd/malmo manifest check catalog/<id>/manifest.yml passes — schema + admission in one (run it yourself, don't trust the agent's claim)
• docker compose -f catalog/<id>/compose.yml config -q passes
• go run ./cmd/malmo manifest resolve catalog/<id>/manifest.yml run to fill image digests/sizes — or images: omitted with a note if the registry was unreachable
• PR body includes Closes #<N>

[bogdanpydev]

Boot-tested — Blocked under the current sandbox. The static "GO (degraded)" verdict doesn't hold.

I built the full adaptation (7-service stack: bundled pgvector/pgvector:pg18 Postgres + bundled valkey:8 + two migration init-containers + the Next.js app + the Hub Go API + Cube with the bundled cube.js/schema config). manifest check, docker compose config -q, and manifest resolve all pass — footprint 1.1 GB download / 3.6 GB disk. Then I boot-tested under a faithful sandbox replica: every service pinned to a non-root UID, cap_drop: ALL, no-new-privileges, ./data binds chowned to that UID, tmpfs for the Postgres socket.

Result: the stack cannot run, for a structural reason that is over-determined:

Service	Needs	Verified failure on the other path
formbricks (and -migrate)	UID 1001	migration runner (packages/database/src/scripts/migration-runner.ts:73-74) mandatorily rm+mkdirs /home/nextjs/packages/database/migrations (baked 1001:101, 755). Even root under cap_drop: ALL can't write it — no CAP_DAC_OVERRIDE. → EACCES: rmdir …/migrations
bundled postgres	a non-root UID	as root under cap_drop: ALL the entrypoint chown fails: chown: changing ownership of '/var/lib/postgresql/18/docker': Operation not permitted — no CAP_CHOWN

malmo assigns one UID to every service in an app, and never 1001 (service_user → host band ≥2100; folderless default → root). No single assignable UID satisfies both constraints → unstartable. This isn't tunable away within the legal adaptations.

On this issue's plan: user: "999:999" on the Postgres sidecar is rejected by admission (internal/admission/admission.go — "malmo assigns every app's runtime UID; remove it") and would be overridden anyway. The correct mechanism is service_user: true + a tmpfs socket, which I used — and with it Postgres booted fine ("ready to accept connections", a real 47 MB initialized data dir). The blocker is the Formbricks app image assuming uid 1001, not the bundled DB.

Also worth recording (the issue's four Gate-D limits undercount): Formbricks requires S3-compatible storage for all file uploads — survey images/backgrounds/logos and the File Upload + Picture Selection question types — and has no local-filesystem fallback; the bundled RustFS option needs a second dedicated subdomain malmo can't route. So those features are disabled out of the box (a 5th limitation), on top of link-survey reachability, OAuth/SSO callbacks, optional SMTP, and third-party integrations.

This is a platform limitation, not a Formbricks quirk — filed as #193 for triage. Marking this blocked; re-shippable if malmo gains per-service UIDs or an opt-in "run as the image's declared USER".

[bogdanpydev]

Unblocking and picking this up. Re-examined the block: it was the one-UID-per-app limitation I filed as #193. onel's triage there (#193 comment) settled it — the headline blocker doesn't need the heavy fix:

• The nextjs/uid-1001 baked-path write targets /home/nextjs/packages/database/migrations (plural), which is a regenerable staging dir wiped every run — the source of truth is migration/ (singular), untouched. So it can be shadowed with a writable bind that malmo creates + chowns to the assigned runtime UID (the Brain prepares only ./data, so multi-dir & folder apps get root-owned bind dirs (breaks them in prod and dev) #147 mechanism).
• onel reproduced malmo's Tier-3 sandbox in plain Docker: the migrate container run as a non-root malmo-band UID (2150, not 1001) under cap_drop: ALL + no-new-privileges, with that shadow bind → migrate-1 exited with code 0. No EBUSY, no EACCES.
• Case 2 (conflicting per-service UID needs) dissolves once Case 1 is solved: with the shadow bind the app adopts whatever UID malmo assigns, so a single service_user band UID satisfies the app, both migrate jobs, and the bundled pgvector Postgres at once.

So Formbricks is not in the hardcoded-internal-UID class — it's adaptable today with already-shipped capabilities (service_user: true + shadow bind + the kan completion-gate migrate pattern). Removing blocked and starting the catalog entry.

Caveat carried forward (onel's): the repro proved the named migrate blocker, not the whole 7-service stack — formbricks/hub/hub-migrate/cube could still surface a different baked-path write only a real boot reveals. Authoritative proof is a QEMU medium-lane boot, which is currently blocked on this box (#189); I'll do a Docker sandbox-replica boot smoke test and flag the medium-lane gap in the PR.