MLflow Self-Hosted
IntermediateMl ProjectSelf-hosted MLflow: every experiment and model version on your infrastructure.
Published 27 September 2026
About MLflow Self-Hosted
MLflow Self-Hosted runs the MLflow tracking server on your own server with PostgreSQL behind it. The server is a FastAPI application served by Uvicorn, one process and one database for the core: every experiment run, parameter, metric, and model version lands in PostgreSQL through the same REST API every MLflow client already speaks.
Artifacts are a second store you choose. Models, plots, and environment snapshots go to the artifact store you point at: local disk for a single server, or any S3-compatible object store for durability. The model registry, with versions, aliases, and lineage, is part of the same server.
Managed MLflow exists inside other platforms: Databricks runs it as part of its lakehouse, and Amazon SageMaker offers hosted tracking servers billed by the hour. A self-hosted MLflow is the open standard the whole ML ecosystem integrates with, one server process with nothing metered.
The trade is the platform's spartan design. MLflow's built-in basic auth covers users and per-experiment permissions, but HTTPS, SSO, and backups are yours to wire up, the UI is minimal next to hosted tracking platforms, and model serving needs its own stack on top. Teams that want a fuller team platform should compare Weights & Biases Self-Hosted.
Key Features
- ✓MLflow tracking server, a FastAPI application, from a single Docker image or pip install
- ✓PostgreSQL backend store for runs, parameters, metrics, and the model registry
- ✓Artifact storage on local disk or any S3-compatible object store
- ✓The model registry, with stages, versions, and lineage, included in the server
- ✓The same client interface the ML ecosystem already speaks
When to Use MLflow Self-Hosted
- →ML teams tracking experiments and model versions on their own infrastructure
- →Training jobs on cloud GPUs that log to one central tracking server
- →Organizations whose model data and metrics must not leave their network
- →Small teams replacing ad-hoc spreadsheets of runs with a model registry
- →LLM and GenAI projects tracing prompts and evaluations alongside classic ML runs
Pros
- The open standard for experiment tracking: no lock-in, no metering
- One server process and a database is the whole platform
- Artifacts stay on your storage, not a vendor's
Cons
- Built-in auth is basic (users and permissions, no SSO), and HTTPS is yours to add
- The UI is spartan next to hosted tracking platforms
- Model serving needs its own stack on top
Database Options for MLflow Self-Hosted
The production backend store: runs, parameters, metrics, and the model registry live here, and it handles the concurrent writes of parallel training jobs. It also holds the users and permissions of MLflow's basic auth, so a multi-user server wants it behind it. Back it up alongside the artifact store.
A supported backend store alongside PostgreSQL, and the right pick where your platform already runs MySQL. The trade is documentation gravity: MLflow's guides and examples assume PostgreSQL or SQLite, so MySQL is the standardized-estate choice, not the ecosystem's default.
These are highlighted picks. To see all the tools, check the Databases category.
Hosting Options for MLflow Self-Hosted
The default: the tracking server and its SQL backend fit the smallest instances, and a fixed bill keeps experiment volume off the invoice. A CX22-class box at roughly €4/mo carries a small team's server, with artifact storage the first thing that outgrows it.
Root-server Droplets run the same container-plus-database deployment from about $6/mo, with panel-managed snapshots and firewall included. Managed PostgreSQL behind the droplet is the low-ops path when you would rather not run the database yourself; the natural home when a small project's other infrastructure already sits in the DO panel.
The KVM VPS line (intro pricing around $5/mo, renewals higher) is enough for a lab-grade tracking server, with a beginner-friendly panel trading some control for convenience. Enough for a solo server; move up when the team grows or artifacts need durability.
The managed-cloud fit when training runs on EC2 or SageMaker: the tracking server sits in the same VPC, artifacts land in S3, and RDS can host the backend store as a managed database. Pay-as-you-go means an always-on small instance lands around $15/mo before storage, so it earns its place through workload proximity, not price.
The same argument on the Google side: Vertex AI and Compute Engine training jobs reach the server privately, artifacts go to GCS, and Cloud SQL manages the backend store. An always-on e2-small-class instance runs roughly $13/mo before storage; pick it when the training estate is already in GCP.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for MLflow Self-Hosted
Terminates TLS in front of the tracking server from one routing label and renews certificates on its own. Artifact uploads pass through the server when it proxies the artifact store, so there's no body-size limit to raise, unlike NGINX.
Automatic certificates for the tracking endpoint from a short config, giving training jobs an HTTPS tracking URI without a renewal job. Caddy has no default request-size limit, so large model artifacts upload through the server without extra settings.
Self-Hosted PaaS Options for MLflow Self-Hosted
Free and self-hosted, running the MLflow server image with PostgreSQL attached and TLS from Coolify's bundled Traefik. Mount the artifact directory as a persistent volume, or point MLflow at S3-compatible storage, so models survive redeploys.
MLflow Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
Exposes the tracking server without inbound ports, useful for a lab server on a home network or a VPS you would rather not open.
Frequently Asked Questions about MLflow Self-Hosted
Is there a managed MLflow, or is self-hosting the norm?
Standalone MLflow has no vendor cloud of its own. Databricks, where MLflow was created, runs it as part of its platform, and Amazon SageMaker offers managed tracking servers billed by the hour: a Small server, sized for up to 25 users, is $0.60 an hour, around $440 a month if it runs continuously. For everyone else, the self-hosted server is the standard deployment: framework-agnostic, one process and a database, with HTTPS and backups as your side of the bargain.
What does the server need to run?
Very little. The tracking server is a light FastAPI process, so 2 GB of memory and 1-2 vCPUs run it with PostgreSQL for one person, and 4 GB is the comfortable size for a team. Disk is the real variable: artifacts such as model files and checkpoints dominate it, so keep them on a separate volume or in object storage rather than the server's system disk.
Where do my artifacts actually go?
The backend store (PostgreSQL here) holds runs, parameters, metrics, and registry metadata; artifacts, the models, plots, and files, go to a separate artifact store. Local disk is the simple start, and any S3-compatible object store is the durable production choice. By default the server proxies artifact uploads and downloads, so clients only need the tracking URI, not storage credentials.
Can the server track experiments that run in the cloud?
Yes, and that's a common shape: training jobs on cloud GPUs or a managed platform log to this server's tracking URI over HTTPS, with artifacts proxied through the server or written to a store both sides can reach. The server has to be reachable from those jobs and should require login: MLflow's built-in basic auth gives each user or service account credentials and per-experiment permissions, and the reverse proxy provides TLS.
When do I outgrow SQLite?
At the second concurrent writer. SQLite serializes writes to one file, fine for a solo lab, and the first symptom is a database-locked error under parallel training runs. PostgreSQL is the documented production backend; move before the experiment history you care about accumulates, not after.
Stacks Related to MLflow Self-Hosted
Strapi Self-Hosted
InfrastructureSelf-hosted Strapi: an open-source headless CMS with PostgreSQL, on a server you control.
Airflow Self-Hosted
InfrastructureSelf-hosted Apache Airflow: the standard data-pipeline scheduler on your infrastructure.
n8n Self-Hosted
InfrastructureSelf-hosted n8n on your own server, with full control over the database, the host, and how it's exposed to the internet.
GitLab Self-Hosted
InfrastructureSelf-hosted GitLab with Docker: your code, your CI, your infrastructure.
Scores
Popularity4/5
MLflow is the most widely used open-source experiment tracker and is supported by nearly every ML framework and platform.
Learning Curve3/5
Logging runs takes a few lines of client code; running the server adds a database, an artifact store, auth, and TLS, all of it ordinary infrastructure.
Flexibility4/5
Framework-agnostic tracking, a model registry, and GenAI tracing, with any backend database and any S3-compatible artifact store.
Performance3/5
The tracking server is light, so one small instance serves a team; artifact storage grows long before compute does.
Portability5/5
An open standard on plain PostgreSQL and object storage; the same client code logs to a self-hosted server, Databricks, or SageMaker.
Tools in the MLflow Self-Hosted Stack
MLflow Self-Hosted Pricing
The server, PostgreSQL, and artifact storage are all free or nearly, and the smallest instance runs the tracking server for a team. The managed alternative here isn't a product bill so much as a platform bill, Databricks, which this stack only replaces if you weren't paying it anyway.
2 GB of RAM runs the tracking server and PostgreSQL; 4 GB is comfortable for team use.
Apache-licensed, both of them.
S3-compatible storage for model artifacts, optional while local disk suffices.
MLflow Self-Hosted System Requirements
- CPU
- 1-2 vCPU
- RAM
- 2 GB, or 4 GB for team use
- Disk
- 20 GB SSD plus a separate artifact volume, since artifacts dominate disk
- OS
- Any Linux with Docker
No official requirements published — tekyous guidance based on the bundle's services.
Community guidance lands at 2 cores / 4 GB for teams, and AWS's managed MLflow sizes even a 25-user team's server as Small; the tracking server itself is light, so experiment artifacts set the real bill.