# ClearML Server: Self-Hosted Backend for the ClearML MLOps Platform

> ClearML Server is the self-hosted backend infrastructure for the ClearML MLOps platform, comprising a web UI, a REST API, and a file server deployable via Docker or Kubernetes. It enables teams to run experiment management, pipeline orchestration, and model tracking on their own infrastructure instead of the hosted service.

**clearml/clearml-server** — ClearML - Auto-Magical CI/CD to streamline your AI workload. Experiment Management, Data Management, Pipeline, Orchestration, Scheduling & Serving in one MLOps/LLMOps solution

- Repository: https://github.com/clearml/clearml-server
- Website: https://clear.ml/docs
- Stars: 470 · Forks: 164
- Language: Python
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/clearml-clearml-server

## What ClearML Server Provides and Who Deploys It

ClearML Server is the backend infrastructure component that makes the ClearML MLOps platform functional for a team. Without it, ClearML's client library can only log locally; with it, multiple users can collaborate, view each other's experiments in a shared web UI, store models and images in a central file server, and query experiment history through a REST API.

The README describes three components: the ClearML Web-App (a single-page UI for experiment management and browsing), a RESTful API for documenting and querying experiment information including statistics and results, and a locally-hosted file server for storing images and models. These three components run as separate services with distinct ports.

The primary audience is a team or organisation that has already adopted the ClearML client library for ML experiment tracking and wants to move from the free hosted service at app.clear.ml to self-hosted infrastructure. This might be for data residency reasons, for cost at scale, or because the organisation's security policy prohibits using an external service. A developer who is not yet using ClearML would evaluate the whole platform, not just this repository.

## System Design: Three Services on Three Ports

ClearML Server supports two deployment configurations. In the single-IP configuration, the three services listen on distinct ports on the same host: the web application on port 8080, the API service on port 8008, and the file storage service on port 8081. In the sub-domain configuration, each service gets its own subdomain (app.*, api.*, files.*) using default HTTP or HTTPS ports, with no port number required in the client configuration.

The port requirement is a practical constraint: ports 8080, 8081, and 8008 must all be available before deploying. The README shows how to check whether a port is in use:

```bash
sudo lsof -Pn -i4 | grep :8080 | grep LISTEN
```

The file server stores images and models generated by experiments. Accessing these from the web UI requires the file server to be reachable from the browser, which has implications for network configuration in cloud or VPN environments where the file server port might not be publicly accessible.

The web UI is a single-page application, so all browsing happens in the client's browser after the initial page load. The REST API is what the ClearML client library calls to log experiment data; it is not designed for direct human consumption.

## Deploying with Docker and Connecting the ClearML Client

The README lists four deployment methods: a pre-built AWS EC2 AMI, a pre-built GCP Custom Image, a pre-built Docker image (for Linux, macOS, and Windows), and Kubernetes (via Helm or manual installation). Docker Compose is the most common path for teams not already on Kubernetes.

After launching, connect the ClearML client to the server by running clearml-init for interactive setup, or by editing ~/clearml.conf directly. The README gives the required structure:

```
api {
    # API server on port 8008
    api_server: "http://localhost:8008"

    # web_server on port 8080
    web_server: "http://localhost:8080"

    # file server on port 8081
    files_server: "http://localhost:8081"
}
```

For a sub-domain deployment, no port numbers are needed in these values. After configuration, experiments logged with the ClearML client appear at the web server address, for example http://localhost:8080.

Restarting the server requires stopping and starting the containers:

```bash
docker-compose down
docker-compose -f docker-compose.yml up
```

The README notes that the web login authentication feature and the non-responsive experiments watchdog are available as manually enabled advanced options, with configuration details in the documentation at clear.ml/docs.

## ClearML-Agent Services for Long-Running Background Jobs

Since version 0.15 of ClearML Server, dockerised deployments include a ClearML-Agent Services container running alongside the main services. This component differs from a regular ClearML Agent in that it is designed for long-lasting jobs rather than training tasks.

The README lists several use cases for the services container: an auto-scaler service that spins up instances on demand, controllers that implement pipelines or DevOps logic, optimisers for hyperparameter tuning or sweeping, and application containers for data transparency tools such as Bokeh apps. Any task pushed to the dedicated `services` queue is picked up and launched as a new tracked node in the system.

The README includes a specific warning about this queue: training and inference tasks should not be pushed to it. The services queue is intended for lightweight orchestration tasks, not for compute-heavy workloads. Putting a training job there adds unnecessary load to the server itself rather than dispatching it to dedicated compute.

This separation of concerns reflects ClearML's overall architecture: the server manages state and coordination, while agents handle the actual computation. The services container occupies a middle tier, running orchestration logic that needs to run continuously but does not need dedicated compute hardware.

## Upgrade Procedure and the Backup Requirement

The README describes a multi-step upgrade process for Docker-based deployments. The first step is shutting down the containers:

```bash
docker-compose down
```

The README strongly recommends backing up the data directory before upgrading. For a deployment where data lives at /opt/clearml, the backup command given in the README is:

```bash
sudo tar czvf ~/clearml_backup.tgz /opt/clearml/data
```

This is a significant operational requirement. ClearML Server stores experiment data, model files, and image artifacts in the data directory. Without a backup, an upgrade that goes wrong can result in permanent data loss. The README emphasises this step before providing the actual upgrade commands.

The docker compose configuration file in the repository (docker/docker-compose.yml) is updated with each release, and the README notes that upgrades are reflected there. This means upgrading requires pulling the new configuration file and restarting, not just updating the container image tag.

No automated migration tooling is described. Each upgrade is a manual process. Teams running ClearML Server at scale should build this backup step into their upgrade automation before relying on the server for important experiment data.

## License and Maintenance Status

The README badge identifies the license as SSPL (Server Side Public License). SSPL is a license created by MongoDB that is more restrictive than open-source licenses such as Apache-2.0 or MIT. The key implication is that anyone who offers ClearML Server as a service to third parties must release the entire software stack used to provide that service under SSPL. This prohibits commercial SaaS products built on ClearML Server without a separate commercial agreement. Teams running it for their own internal use are not affected by this restriction.

The last push to the clearml/clearml-server repository was on 2026-03-24, and the most recent release is v2.4.0, published on 2026-03-08. The previous releases were v2.3.0 in November 2025 and v2.2.0 in July 2025, indicating a roughly quarterly release cadence through early 2026. No further releases or pushes appear after March 2026.

## ClearML Server vs. MLflow Tracking

MLflow Tracking is an open-source experiment tracking server widely used in the ML community. It is Apache-2.0 licensed and deployable with a single command. The comparison with ClearML Server highlights what each prioritises.

MLflow Tracking focuses narrowly on logging parameters, metrics, and artifacts from ML experiments, with a simple UI for comparison. It does not include an agent orchestration layer, a pipeline scheduler, or a task queue. ClearML Server covers a broader surface: experiments, pipelines, data management, agent orchestration, and serving, all in a single integrated platform.

For a team that only needs experiment logging, MLflow's simpler architecture and Apache-2.0 license reduce operational overhead significantly. For a team that needs the full MLOps lifecycle including automated pipelines and agent management, ClearML Server provides more built-in functionality in a single deployment. The SSPL license difference is meaningful for any team building a commercial product on top of the infrastructure: MLflow permits that without restriction, while ClearML Server requires a commercial agreement.

## Conclusion

ClearML Server suits teams that need full experiment management, pipeline orchestration, and file storage on their own infrastructure and cannot use the hosted service at app.clear.ml. It is the wrong choice for teams starting out with experiment tracking on a budget: the SSPL license prohibits offering ClearML Server as a hosted service without a commercial agreement, and the deployment requires managing three separate services and their ports. MLflow Tracking covers the core experiment logging use case with a far simpler deployment and an Apache-2.0 license. The most recent release was v2.4.0, published on 2026-03-08, and the last push to the repository was on 2026-03-24.

## FAQ

### How does ClearML work?

ClearML consists of a client library and a server. The client library is added to ML training code; it automatically logs parameters, metrics, and artifacts to the ClearML Server backend. The server stores that data and makes it available through a web UI at port 8080 and a REST API at port 8008.

### Is ClearML open source?

The ClearML Server repository is licensed under SSPL (Server Side Public License), which restricts commercial use as a hosted service without a separate agreement. The README also mentions a free hosted service at app.clear.ml maintained by the ClearML team.

### What is the difference between ClearML Server and the hosted ClearML service?

The hosted service at app.clear.ml is maintained by the ClearML team and is open to anyone without requiring infrastructure management. ClearML Server is the self-hosted version for teams that need data residency, custom networking, or control over their deployment configuration.

## Sources

- [clearml/clearml-server on GitHub](https://github.com/clearml/clearml-server)
- [Issues](https://github.com/clearml/clearml-server/issues)
- [Project website](https://clear.ml/docs)
- [README](https://github.com/clearml/clearml-server/blob/master/README.md)
- [Releases](https://github.com/clearml/clearml-server/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clearml-clearml-server