Add Multica template

[enemyrr]

Summary

Adds a blueprint for Multica — an open-source managed agents platform for teams (assign tasks to AI coding agents like Claude Code, Codex, OpenClaw, etc.).

Services

• postgres — pgvector/pgvector:pg17
• backend — Go API + WebSocket server, port 8080 (built from https://github.com/multica-ai/multica.git#main with Dockerfile)
• frontend — Next.js 16, port 3000 (built with Dockerfile.web)

Multica doesn't publish pre-built images yet, so the template builds from the remote git context — same pattern as firecrawl/nuq-postgres.

Traefik domains

Two public domains are exposed:

• ${app_domain} → frontend:3000
• ${api_domain} → backend:8080 (needed by the multica CLI/daemon)

NEXT_PUBLIC_WS_URL is baked into the frontend build at deploy time pointing at wss://${api_domain}/ws, so WebSocket traffic routes through the api domain.

Login

Out of the box, non-production environments accept verification code 888888 for any email. For production, set RESEND_API_KEY / RESEND_FROM_EMAIL.

Test plan

• PR preview deploys successfully
• Import template into a Dokploy instance, deploy
• Open app_domain, log in with 888888
• Verify backend is reachable at api_domain
• Install CLI locally and run multica setup self-host --server-url https://<api_domain> --app-url https://<app_domain>

Greptile Summary

Adds a new Multica blueprint (three services: pgvector/postgres, Go backend, Next.js frontend) with two auto-generated domains, strong auto-generated secrets, and all optional integrations (Resend, Google OAuth, S3/CloudFront) defaulting to empty strings. The template follows established two-domain and remote-build-context patterns already present in the repo (e.g., openpanel, firecrawl). The signoz files in the diff are pre-existing changes on the branch, not introduced in the latest commit.

Confidence Score: 5/5

Safe to merge; only P2 style/documentation suggestions remain.

No P0 or P1 findings. The two remaining comments are P2: one about pinning the mutable #main build ref (acknowledged pattern in the repo), and one about documenting multi-line PEM key encoding for the optional CloudFront integration. Neither blocks functionality or deployment.

blueprints/multica/template.toml — CLOUDFRONT_PRIVATE_KEY documentation; blueprints/multica/docker-compose.yml — build context pin.

_{Reviews (1): Last reviewed commit: "Add Multica template" | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[enemyrr]

Closing — opening a clean PR with only the Multica commit off upstream/main.

[greptile-apps]

Build context pinned to mutable #main ref

Both services build from https://github.com/multica-ai/multica.git#main, which always resolves to the latest commit on main. Any breaking upstream change silently breaks all future deployments of this template with no way to roll back. Pinning to a specific commit SHA or semver tag (once the project cuts releases) would make deployments reproducible and safe to re-deploy.

This matches the acknowledged firecrawl/nuq-postgres pattern; at minimum, a comment noting "pin this to a release tag once available" would help future maintainers.

[greptile-apps]

Multi-line PEM key may not survive plain env-var assignment

CLOUDFRONT_PRIVATE_KEY is a CloudFront signing key — an RSA-2048 private key in PEM format with embedded newlines. Setting it as a bare environment variable (e.g., pasting a PEM block in Dokploy's env editor) typically breaks because the newlines are stripped or mis-parsed. A convention comment (e.g., encode newlines as \n, or base64-encode the value and have the application decode it) would save users from silent signing failures.

Since this defaults to "" and is only needed for S3/CloudFront media uploads, it won't block the initial deployment — but documentation here would prevent a confusing runtime error later.