Chat auto-titling and chat follow-up suggestions are gated on the server-side
LLM layer, which reads MULTICA_LLM_API_KEY / MULTICA_LLM_BASE_URL through
os.Getenv. The self-host compose file enumerates backend environment
explicitly and has no env_file, and those three vars were not in the list — so
setting them in .env did nothing, the container never saw them, and the layer
was off on every compose deployment regardless of configuration. .env.example
documents them, which made it look configurable.
That was survivable while quick actions were generated by the daemon's own
provider pass, which needed no server key. MUL-5573 moved generation server-
side and removed the daemon path, so on those deployments the feature stopped
appearing entirely rather than degrading.
Adds the passthrough, and one startup line reporting whether the layer is
enabled. Every consumer degrades silently by design, so without that line an
unset key is indistinguishable from a broken feature — which is exactly how
this surfaced. Helm already supports it through the operator-managed Secret;
values.yaml now says so instead of leaving it undocumented.
Co-authored-by: multica-agent <github@multica.ai>
* feat(vcs): gate self-hosted Git providers to self-host deployments only (MUL-3772)
The Forgejo/Gitea/GitLab integration is intended for self-hosted Multica, where
Multica can reach a Git instance on the operator's own network. On the managed
multi-tenant cloud it adds an SSRF surface (connect validates a user-supplied
instance URL from the server) and would store third-party Git tokens for all
tenants under one key, while only serving the small subset of users whose
instance is publicly reachable. Product decision: offer it on self-host only.
- Add an explicit deployment switch MULTICA_VCS_INTEGRATION_ENABLED (default
off). Connect, rotate, and webhook now require BOTH the switch on AND a valid
MULTICA_VCS_SECRET_KEY — the switch is the product boundary, not key presence
alone. When off, connect/rotate return 404 and the webhook returns a bare 404
(no config leak), independent of the frontend.
- /api/config exposes vcs_integration_available (mirrors the switch, omitted
when false) so the Settings UI hides the whole "Git providers" section on
cloud instead of surfacing an operator-only "missing key" hint.
- docker-compose.selfhost.yml defaults the switch on; .env.example documents it.
- Docs (en/zh) lead with a callout: available on self-hosted Multica only, not
Multica Cloud, and clarify "self-hosted" means Multica itself, not just Git.
#5006 / #5883 stay in place — the schema and backend capability are retained;
this only gates availability. No cloud VCS connection can exist (connect always
required the key, which the cloud never set), so nothing needs migrating.
Verified: go build/vet + VCS/config handler tests on a fresh migrated DB
(incl. a new disabled-deployment 404 test); pnpm typecheck (core + views) and
the integrations-tab + core schema/config vitest suites pass.
Co-authored-by: multica-agent <github@multica.ai>
* fix(vcs): complete self-host integration gating (MUL-5138)
Co-authored-by: multica-agent <github@multica.ai>
---------
Co-authored-by: Bohan-J <bohan@devv.ai>
Co-authored-by: multica-agent <github@multica.ai>
* fix(web): resolve upstream URLs at runtime
* fix(web): keep unconfigured upstreams same-origin
* fix(web): restore dev-only localhost fallbacks for API and docs upstreams
`next dev` on a developer machine now falls back to the conventional
http://localhost:8080 backend (honoring BACKEND_PORT) and
http://localhost:4000 docs origin when nothing is configured, so a bare
`pnpm dev:web` keeps proxying out of the box. Builds and the runtime
proxy keep the strict resolvers, so prebuilt images still leave unset
upstreams unproxied.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Naiyuan Qing <145280634+NevilleQingNY@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Closes#4237
Add a `postgres.external.enabled` toggle (default: false) so operators
can skip the built-in Deployment/PVC/Service and point Multica at any
externally managed PostgreSQL (CNPG, RDS, Cloud SQL, Neon, etc.).
When enabled:
- postgres Deployment, PVC, and ClusterIP Service are not rendered
- The hard-coded DATABASE_URL env var is omitted from the backend pod;
DATABASE_URL must be supplied in existingSecret and reaches the
container through the existing envFrom.secretRef mechanism
- POSTGRES_DB / POSTGRES_USER are omitted from the ConfigMap (unused
when DATABASE_URL is provided directly)
Also update the existingSecret creation example in values.yaml to show
both the built-in and external-postgres variants so users know to add
DATABASE_URL instead of POSTGRES_PASSWORD when switching modes.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
cmd/migrate previously ran a check-then-apply loop on a *pgxpool.Pool
with no locking, so two backend pods starting at the same time (multi-
replica Deployment, scale-up, or a manual run overlapping with pod
startup) could both pass the EXISTS check on a pending migration and
race on the DDL or the schema_migrations INSERT, crashing the loser.
Take a single connection from the pool, hold a session-level
pg_advisory_lock for the entire migration loop, and release it on the
way out. We use the blocking variant so a late arriver queues behind
the current runner and then no-ops on the EXISTS checks instead of
crash-looping. The loop deliberately stays outside a transaction so
existing CREATE INDEX CONCURRENTLY migrations keep working.
Also refresh the values.yaml / backend.yaml comments next to
backend.replicas: the chart still ships replicas: 1 by default, but
that is now a recommendation (Recreate strategy, no leader split), not
a correctness requirement.
Refs https://github.com/multica-ai/multica/issues/3647
Co-authored-by: multica-agent <github@multica.ai>
Adds a value (default true for backward compatibility) that gates the
uploads PersistentVolumeClaim, the backend container's volumeMount, and
the pod-spec volume. Operators who serve uploads from S3 (S3_BUCKET set)
can now set backend.uploads.persistence.enabled=false to drop the PVC
entirely, removing the ReadWriteOnce Multi-Attach barrier on the storage
side for replicas > 1.
Also makes the PVC accessModes configurable (default [ReadWriteOnce]) so
operators with a ReadWriteMany-capable StorageClass can share the
uploads volume across replicas without object storage.
Documentation: values.yaml comments and the SELF_HOSTING.md resource
list are updated to describe the new toggle.
Refs: https://github.com/multica-ai/multica/issues/3646
Co-authored-by: multica-agent <github@multica.ai>
* feat(self-host): DISABLE_WORKSPACE_CREATION env var (MUL-2777, #3433)
When self-hosters set DISABLE_WORKSPACE_CREATION=true, POST /api/workspaces
returns 403 for every caller and the UI hides every "Create workspace"
affordance (sidebar, modal, /workspaces/new page, onboarding Step 2). This
closes the gap where ALLOW_SIGNUP=false still let any signed-in user open
an isolated workspace the platform admin couldn't see.
- server: new Config.DisableWorkspaceCreation, gate in CreateWorkspace,
workspace_creation_disabled in /api/config, Go tests.
- frontend: new workspaceCreationDisabled in configStore, hide sidebar
entry, swap NewWorkspacePage / CreateWorkspaceModal / onboarding
StepWorkspace to a "creation disabled, ask for invite" state when the
flag is on, EN + zh-Hans locale strings.
- ops: .env.example, docker-compose.selfhost, helm values + configmap,
SELF_HOSTING.md, SELF_HOSTING_ADVANCED.md, environment-variables docs
(EN + zh).
Co-authored-by: multica-agent <github@multica.ai>
* fix(onboarding): drive create path off workspaceCreationAllowed (#3433)
PR #3441 review: when DISABLE_WORKSPACE_CREATION=true and the user already
has a workspace, StepWorkspace still walked the resume copy (`headline_resume`
/ `lede_resume` mentioning "or start another") and `creatingActive` ignored
the flag, leaving a stale clickable create CTA possible if /api/config
arrived late.
Refactor StepWorkspace to derive a single `workspaceCreationAllowed`
boolean from the config store. It now drives:
- Initial `mode` state (defaults to "existing" when disabled + reusing so
the CTA is pre-armed for the only valid action).
- `creatingActive` so the footer CTA cannot fall back into the create
branch even mid-render.
- Eyebrow / headline / lede strings — adds
`creation_disabled_{eyebrow,headline,lede}_resume` (EN + zh-Hans) for
the disabled + reusing variant.
Tests: cover the three reachable shapes — flag off + no existing, flag on
+ no existing, flag on + existing.
Co-authored-by: multica-agent <github@multica.ai>
---------
Co-authored-by: J <j@multica.ai>
Co-authored-by: multica-agent <github@multica.ai>
* Include k8s deployment instructions
* Use helm for deployment
* docs(self-host): add Helm / Kubernetes deployment to quickstart (en + zh)
* fix(helm): gate backend ExternalName alias behind a value
The unprefixed Service/backend in the chart is load-bearing, but as
written it limits the chart to one release per namespace and fails
helm install whenever a Service/backend already exists in the
namespace (without --take-ownership).
Gate the alias behind frontend.compatibility.backendAlias (default
true, so existing installs are unchanged). Operators running a web
image with a patched REMOTE_API_URL can set it to false to drop the
Service entirely. Document the one-release-per-namespace constraint
and the opt-out in values.yaml and the SELF_HOSTING.md Kubernetes
section.
Addresses review item #1 on PR #2377.
* fix(helm): add backend startupProbe so cold installs survive migrations
The entrypoint runs `./migrate up` before serving traffic. On a cold
cluster (Postgres still coming up) this can take minutes, during which
the livenessProbe (initialDelaySeconds 30 / periodSeconds 30) trips and
restarts the pod 1-2 times.
Add a startupProbe on /healthz (failureThreshold 30, periodSeconds 10,
~5 min budget). Kubernetes disables liveness/readiness until it passes,
so migrations finish without the pod being killed, and the aggressive
livenessProbe is untouched for steady-state. Update the SELF_HOSTING.md
install step, which no longer expects 1-2 restarts.
Addresses review item #2 on PR #2377.
* fix(helm): roll backend pods on config/secret change via checksum annotations
envFrom does not watch the referenced ConfigMap/Secret, and helm
upgrade alone does not change the pod template hash, so editing
values.yaml + `helm upgrade` left the old backend pods running stale
config.
Add checksum/config (hash of the rendered configmap.yaml) and
checksum/secret (hash of the live existingSecret via lookup, since it
is created out-of-band and has no chart template) to the backend pod
template. Config edits now actually re-roll the backend on upgrade,
and Secret rotations do too. lookup is empty under
`helm template`/`--dry-run`; that placeholder is harmless and
documented inline.
Addresses review item #3 on PR #2377.
* docs(self-host): sync quickstart with new startupProbe behavior
SELF_HOSTING.md was updated to reflect that the backend now stays
Running but not Ready while Postgres comes up (startupProbe absorbs
it, so no restart), but the EN/ZH quickstart docs still described the
pre-startupProbe behavior of "may restart 1-2 times". Bring them in
line.
Co-authored-by: multica-agent <github@multica.ai>
---------
Co-authored-by: Bohan Jiang <52446949+Bohan-J@users.noreply.github.com>
Co-authored-by: multica-agent <github@multica.ai>
