Agent workspace · Deployment & operations
Multica
A self-hosted Multica workspace for coordinating AI agents and tasks. The deployment runs the frontend, backend, and PostgreSQL as separate Kubernetes services.
Implementation scope
Custom work covers deployment configuration, service connections, persistent storage, access control, and health checks. Multica's upstream contributors maintain the application.
Self-hosting · K8s · Postgres
Implementation evidence
Explicit service boundaries
The manifests define separate frontend, backend, and PostgreSQL deployments and services, with application connections configured between them.
Basis: Kubernetes deployment and service manifests
Independent storage lifecycle
Backend uploads and PostgreSQL data use distinct persistent-volume claims.
Basis: Volume claims and container mounts
Process and traffic checks
Backend liveness/readiness probes and database readiness are configured separately. All services use single replicas; backend and database updates use Recreate, while the frontend uses RollingUpdate.
Basis: Probe, replica, and deployment strategy configuration
System flow
Access boundary
Protected entry
Requires authorized access to the working environment.
Authorized request
Upstream application
Frontend
Serves the workspace interface through its own deployment and service.
Application requests
Upstream application
Backend
Handles workspace operations and connections to stored data.
Upload volumeSeparate persistent claim for backend files.
Database operations
Persistent state
PostgreSQL
Stores application records on a database-specific persistent claim.
These are logical request relationships. The contribution is deployment and operational configuration; upstream contributors own the application. Single replicas do not provide node-level failover.
Design decisions
Separate application roles
Separate deployments allow application containers to be replaced while stored data remains on persistent volumes. Connections and compatible versions still need coordination. Persistent storage survives container replacement; backups and restore procedures are a separate concern.
Keep the workspace private
The workspace requires authorized access to protect task content and agent context. Public notes describe the deployment without exposing the working environment. Signed-in workflows need their own checks beyond the public entry point.
Operate a repeatable deployment
Kubernetes manifests make the deployment repeatable. The backend and database use Recreate updates, accepting interruption during replacement; the frontend rolls out incrementally. Readiness controls when traffic reaches a service, while liveness can restart a failed process.
Access and limitations
Authorized access is required. Current services use single replicas, so the deployment does not provide node-level failover. Agent output quality and multi-step workflow completion require separate evaluation.
Updated