Self-hosted
Run M3 Forge and Marie AI entirely inside your own environment.
This is the Kubernetes-first deployment model for customers who want full control over infrastructure, networking, storage, upgrades, and compliance boundaries.
Deployment models
M3 Forge self-hosting is designed to support three installation shapes:
| Installation shape | What you deploy | Best for |
|---|---|---|
m3forge only | Control plane only | staged rollout, internal admin plane, control-plane-first installs |
marie-ai only | Data plane only | runtime-only installs, hybrid data planes, standalone execution clusters |
| Full platform | m3forge + marie-ai | complete self-hosted deployment |
Current implementation status
| Capability | Status |
|---|---|
Standalone m3forge chart | Available |
| Full platform umbrella chart | In progress |
| Hybrid listener/operator package | In progress |
| Kubernetes-native webapp runner | In progress |
The current self-hosted chart work is production-oriented for the control plane, but the full umbrella install and Hybrid data-plane package are still being implemented. Treat the chart as the first deployment slice, not the final platform packaging.
What gets deployed today
The current m3forge chart deploys:
- API Deployment + Service
- frontend Deployment + Service
- migration Job for Prisma schema updates
- optional PVC-backed
/datamount for filesystem-backed workspace and repository paths - Ingress or Gateway API entrypoint
- optional runner deployment, disabled by default
Required external services
- PostgreSQL
- S3-compatible object storage
- ClickHouse for production observability and analytics
AWS S3 works directly. On GCP and Azure, use MinIO or another S3-compatible layer today. Native GCS and Azure Blob adapters are not yet the default runtime contract for M3 Forge.
Installation workflow
Choose your control-plane scope
Start with standalone m3forge if you are bringing up the control plane first, or wait for the umbrella chart if you want a single-package full-platform install.
Provision external dependencies
Create PostgreSQL, object storage, secrets, ingress, and ClickHouse according to your provider baseline.
Publish or reference split images
The chart expects separate API and frontend image repositories and tags.
Configure Helm values
Start from one of the example values files under deploy/helm/charts/m3forge/examples/.
Install the chart
helm install m3forge ./deploy/helm/charts/m3forge \
-f ./deploy/helm/charts/m3forge/examples/self_hosted_external.yamlVerify the control plane
Confirm:
- migration job succeeds
- API
/healthresponds - frontend loads
- ingress or HTTPRoute resolves correctly
Storage and scaling notes
The control plane is not fully stateless today. Workspace and repository flows still use filesystem-backed paths. That means:
- the first chart can run with a single API replica and a PVC-backed
/data - multi-replica API scaling requires shared RWX storage or a later storage redesign
- autoscaling should stay conservative until those filesystem assumptions are reduced
Provider guides
Related reference
LangSmith’s self-hosted overview splits its model into observability-only, full control plane plus data plane, and standalone server patterns. We are following the same high-level deployment family while adapting it to M3 Forge and Marie AI. Source: