pythondockerdeploymentuv

Deploy python application in production with or without uv

I used to work with Java for many years but in the last project I need to use python and I learn the ecosystem these days.

We use UV and have a project with a bunch of dependencies. On my development machine I run uv run main.py. However I was wondering how should we prepare a deployment artifact for our application? We'll use python and uv stack in 2 different kinds of applications:

  1. Run in Docker in k8s
  2. Run as a process

So My question is: Is it a good practice to install uv on production machine (or in docker) and still run the production application like I do in the development or there are other alternatives? What is the best way to run the application with multiple python modules and having many dependencies? For example here is what I do now in docker:

Dockerfile:

FROM python:3.13
RUN pip3 install uv
WORKDIR /app
# I'll optimize the image later
COPY run.sh /app
COPY main.py /app
COPY pyproject.toml /app
COPY uv.lock /app
RUN uv sync --all-groups
ENTRYPOINT ["/bin/bash", "/app/run.sh"]

My /app/run.sh looks like this:

#!/bin/bash
uv run main.py

But I'm not sure this is how the apps should be really deployed especially for the "run-without-docker" type of deployments - should I install uv on the prod server and run the app like this as well?

In java world we used maven to build stuff but we didn't need to install it on production servers and used it solely as a build tool...

Solution

  • You didn't mention your production requirements but there is nothing with using UV in production. In fact, it is recommended to use at least a dependency manager and virtual environments because the days where you maintain a requirements.txt file by hand. I'm sure Java has similar tools used to manage dependencies and upgrade libraries as you need fit.

    "Is it good practice (in production)" really depends on your requirements in production and how they may differ from in development. UV and most python dependency managers allow you split dev dependencies so thought they are only installed in a developers environment.

    It's actually good devops practice to mirror your prod and dev environments so I'd count it as a good thing that your environments are closer.