feat(apps): add Umami app template

[Jcorderop02]

Summary

Adds Umami (lightweight, privacy-focused, cookie-free website analytics) as an installable app in the catalog.

Motivation

Requested in #532: users want a self-hostable analytics option that doesn't require cookie consent banners.

Related issue

Closes #532

Changes

• packages/core/src/apps/catalog/umami.json: new catalog entry — two-service docker-compose (Postgres + ghcr.io/umami-software/umami:postgresql-latest), auto-generated POSTGRES_PASSWORD shared into DATABASE_URL via {{config:...}} templating, auto-generated APP_SECRET. Host port pinned to 3009:3000 (not the image's default 3000:3000) to avoid colliding with other catalog apps that already claim host port 3000.
• packages/core/src/apps/catalog.json: regenerated via bun scripts/gen-catalog.ts.
• apps/dashboard/src/components/AppLogo.tsx: added umami: { slug: "umami" } so the dashboard renders Umami's real brand mark instead of the generic fallback icon.

Verification

$ bun run test src/apps/catalog.test.ts
 ✓ src/apps/catalog.test.ts (20 tests) 11ms
 Test Files  1 passed (1)
      Tests  20 passed (20)

$ bun run --cwd packages/core lint
$ tsc --noEmit
$ bun run --cwd apps/dashboard lint
$ tsc --noEmit

Also deployed live via docker-compose on a self-hosted Openship instance: both services (umami-db, umami) started healthy, ran their Prisma migrations, and the app served HTTP 200 on the pinned host port with no port collisions.

Screenshots

N/A (catalog/backend change; app UI is Umami's own, unmodified).

Checklist

• One change per PR — one bug, or one agreed feature, with nothing unrelated bundled in
• The diff is scoped — no reformatting or lint fixes on lines I wasn't otherwise changing
• A test fails without this change and passes with it (or I explained above why there isn't one) — the existing catalog.test.ts schema-validation and sync tests cover any new bundled app automatically
• bun run test, bun run --cwd <workspace> lint, and bun format all pass locally
• I understand every line of this diff and can explain it in review

[Hydralerne]

Thanks for this, @Jcorderop02 — and sorry for the collision. Your commit landed at 11:04 on Aug 10; Umami went into main about five hours later as part of the 0.6.2 patch (698893e, merged via #536) before we'd triaged this PR. That's on us for not claiming #532 first, not on you. The "conflict" GitHub is showing is just the two Umami templates landing on the same three files.

Since the shipped template is a superset of this one, I'm going to close this rather than merge it. Concretely, what's on main adds:

• ghcr.io/umami-software/umami:postgresql-v2.19.0 instead of postgresql-latest. We pin every catalog image — an unpinned tag means a redeploy silently jumps versions, which for Umami means Prisma migrations run against a schema the operator didn't ask to change.
• Healthchecks on both services (/api/heartbeat for umami, pg_isready for the db). Without one, a container that starts and then crashes reads as a successful deploy.
• secretEnv: ["DATABASE_URL"] on the umami service. This is the one I'd flag as a real bug rather than a difference: DATABASE_URL is built from environment and interpolates {{config:POSTGRES_PASSWORD}}, so without that entry the generated DB password gets written as plaintext compose env. Worth knowing for future templates — secretEnv covers keys that come from environment, whereas a configFields entry with secret: true is already encrypted on its own (see the isSecret computation in app-install.service.ts), so the secretEnv: ["APP_SECRET"] in this diff was a no-op.
• DATABASE_TYPE: postgresql, plus routes, endpoints, management, and connection.guide — the routing and connection metadata the dashboard needs to front the app and render its Connect card.
• darkInvert: true on the AppLogo entry. Umami's brand mark is near-black (#000000), so without the flag it disappears on the dark and dim tiles.

On the host port: the reasoning in your description was sound, but 3009:3000 isn't needed here. For a service that's exposed: true with routes, withLoopbackPublish (apps/api/src/lib/loopback-publish.ts) replaces the routed port's binding with 127.0.0.1:<pinned>:3000, so the declared host port is discarded under the default route strategy — which is why 25 of the 28 catalog apps declare a plain N:N. Hardcoded publishes only bite on services with no routes (mongodb.json is the outstanding example).

None of this is wasted effort on your part — the template was structurally right, and the config templating and generated-secret wiring were both correct. If you're up for another one, #512 (Shoutrrr), #513 (Kan.bn), and #415 (OpenTelemetry Collector) are all open catalog requests and unclaimed. Comment on whichever you want and it's yours, and I'll review quickly this time.

[Jcorderop02]

Thanks for the pointers. Turns out all three already have an open PR from someone else. #512 has #526 (thisisrakshith). #513 has #522 (SulimanAbdulrazzaq). #415 has #416 (giomartinsdev). All three look complete, not abandoned stubs, just unreviewed.

Happy to pick a different unclaimed catalog request if you have one, or take a pass at reviewing/testing one of those three PRs instead if that's more useful to you than a fourth person building the same thing.