Introduction

mlflow ui is just a web server process for browsing tracking data. Safely shutting it down usually means stopping that process gracefully with SIGINT or SIGTERM, letting in-flight requests finish, and avoiding abrupt process termination with kill -9 unless the process is already hung.

Understand what mlflow ui does and does not do

The UI process serves pages and API responses backed by the MLflow tracking store. Stopping the UI does not terminate experiment runs that are logging elsewhere, and it does not delete tracking data by itself.

That means graceful shutdown is simpler than shutting down a database server, but it is still worth doing properly because:

• active browser requests can be interrupted
• reverse proxies or load balancers may still be sending traffic
• the process may share the same backend store as other MLflow components

If you started it in a terminal, use Ctrl+C

The safest local shutdown is usually the simplest one. If you started MLflow like this:

mlflow ui --host 0.0.0.0 --port 5000

then stop it with:

Ctrl+C

That sends an interrupt signal and gives the process a chance to exit cleanly. This is better than closing the terminal window abruptly or killing the process from another shell for no reason.

If it is running in the background, send SIGTERM

For a background process, find the PID and send a normal termination signal:

ps aux | grep "mlflow ui"
kill -TERM <pid>

If you prefer a single command:

pkill -f "mlflow ui"

Wait a moment and then verify the server is gone:

lsof -i :5000

Avoid kill -9 as a first step. SIGKILL gives the process no chance to clean up and should be reserved for stuck processes that ignored graceful termination.

Service and container environments

If MLflow UI is managed by an init system or container runtime, stop it through that layer instead of killing individual processes by hand.

Systemd example:

sudo systemctl stop mlflow-ui
sudo systemctl status mlflow-ui

Docker example:

docker stop mlflow-ui

Kubernetes example:

kubectl scale deployment/mlflow-ui --replicas=0

These approaches are safer because the supervisor handles signals, restart policy, and lifecycle hooks consistently.

Check for active users and shared backend implications

The UI itself is usually not the only component touching the tracking store. If the backend store is shared with active training jobs, stopping the UI is generally fine, but it may temporarily remove visibility for users who are inspecting experiments.

Before scheduled maintenance, it is still reasonable to check whether the UI is actively in use:

lsof -i :5000

If you front MLflow with nginx, a load balancer, or an ingress, drain traffic there first when uptime matters. That avoids cutting off active browser sessions mid-request.

Make shutdown boring and reversible

Operationally, the safest shutdown plan is:

1. Confirm how the UI is being run.
2. Stop it through the owning process manager.
3. Verify the port is closed and the process is gone.
4. Restart it cleanly when maintenance is over.

For example, restarting after maintenance is usually just:

mlflow ui --host 0.0.0.0 --port 5000

or the equivalent systemctl start, docker start, or deployment scale-up command.

Common Pitfalls

The most common mistake is treating mlflow ui like a stateful database service and overcomplicating the shutdown. It is mostly a web process, so a graceful stop signal is usually enough.

Another issue is using kill -9 immediately. That should be a last resort, not the normal shutdown path.

People also forget that stopping the UI does not stop experiment logging done by clients pointed at a tracking server. If your setup involves a separate MLflow server or backend store, understand which process you are actually stopping.

Finally, do not kill processes manually if systemd, Docker, or Kubernetes is managing them. Use the supervisor so the lifecycle stays consistent.

Summary

• Safely shutting down mlflow ui usually means sending SIGINT or SIGTERM, not SIGKILL.
• Use Ctrl+C for foreground runs and kill -TERM or a supervisor command for managed runs.
• Prefer systemctl stop, docker stop, or scaling a deployment down when a process manager owns the UI.
• Verify the process and port are actually gone after shutdown.
• Stopping the UI affects visibility, but it does not by itself erase experiment data or terminate unrelated MLflow clients.