docker-django-example

Another one is how much time it takes to maintain vs how much interest it has. This is different than burnout. I created and maintain example Docker Compose starter projects for Flask[0], Rails[1], Django[2] and Node[3]. I've had these going for 6-7 years and I maintain them at least once a week to keep everything up to date. I used to also support Phoenix but I stopped after ~5 years because it was the least popular project but also took up more time to upgrade than all of the other example projects combined because Live View has changed in drastic ways so many times. Plus it became no longer enjoyable to work on it since I stopped using Phoenix in my day to day as well. That combined with it being the least popular example app between the 5 projects made it easy to decide to sunset it. I put together a 6 month plan to archive the repo i

Congrats to the Django team! If anyone is curious, I've been maintaining a Docker Compose based Django + Celery + Postgres + Redis + esbuild + Tailwind starter app for years and just updated it for Django 6.0 at https://github.com/nickjj/docker-django-example. The only thing I haven't done is pre-configure the new CSP settings because I want to let that marinate a bit before putting it in as a default.

uv works great in a container, you can tell it to skip creating a venv and use the system's version of Python (in this case, let's say Python 3.14 from the official Python image on the Docker Hub). The biggest wins are speed and a dependable lock file. Dependencies get installed ~10x faster than with pip, at least on my machine. Both of my Docker Compose starter app examples for https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example use uv. I also wrote about making the switch here: https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dock...

> Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though? I'm not sure I understand what you mean? 1. I posted the article last week on my site 2. I noticed it was on HN today (yay) 3. I looked at the parent's comment 4. The parent's description isn't what happens with the original code 5. I made the comment you're replying to on HN to address their concerns and included a refactored version of the original condition for clarity then said I pushed the updates 6. I pushed the updates to both git and my site so both match up There's nothing to pretend about and there's no bug because both versions of the code do the same thing, the 2nd version is just easier to read and requires less `uv` knowledge to know what happens when `uv lock` runs wi

If anyone is looking for examples on using uv with Docker, I have Flask and Django example apps at https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example. It prevents uv from making a virtual environment and does some optimizations like compiling byte code once when your dependencies get installed. It was well worth the switch. I noticed a ~10x improvement for speed compared to pip (30s to 3s to install all dependencies). Proper lock file support is nice too. Funny enough I wrote about and made a video about switching to uv about a week ago here https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dock....

Yeah, containers don't fully solve this problem. We still need a generated lock file with every top level dependency and sub-dependencies locked down to their most precise version commit to version control so that when you build your image today or in 6 months you end up with the same result. Using pip to freeze your dependencies and writing a tiny shell script to generate a lock file at build time is better than nothing to solve this problem with nothing more than pip. It's what I do in https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example. It's not perfect but it solves 80% with minimal complexity.

Congrats on the release to the Django community! If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.

I usually end up with project specific "run" scripts which are just shell scripts so I can do things like `./run shell` to drop into the shell of a container, or `./run rails db:migrate` to run a command in a container. Here's a few project specific examples. They all have similar run scripts: - https://github.com/nickjj/docker-flask-example - https://github.com/nickjj/docker-rails-example - https://github.com/nickjj/docker-django-example - https://github.com/nickjj/docker-node-example - https://github.com/nickjj/docker-phoenix-example

There's a lot of "tool" selections in that repo. If anyone is looking for ready to go web app examples aimed at both development and production with Docker Compose, I maintain: - https://github.com/nickjj/docker-flask-example - https://github.com/nickjj/docker-rails-example - https://github.com/nickjj/docker-django-example - https://github.com/nickjj/docker-node-example - https://github.com/nickjj/docker-phoenix-example About once a week or so I update them to their latest versions for everything. The examples use a combination of services for each tech stack such as web + worker + postgres + redis + esbuild + tailwind. The Rails example is set up for Hotwire and runs Action Cable as a dedicated service along with Sidekiq where as the Flask and Django examples use Celery as a worker. You can easily swap things out sin

If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.

Gunicorn is one of my favorite app servers. I've been using Gunicorn in production on a bunch of projects (any Flask / Django project I happen to work with) for around 8 years now. It's rock solid and extremely predictable. I also use Gunicorn in development too, it supports code reloading and also lets you enable Flask's debug middleware so you can use the interactive debugger. This is all configured in my Build a SAAS App with Flask course, a code example is here: https://github.com/nickjj/build-a-saas-app-with-flask. A Django example is here: https://github.com/nickjj/docker-django-example

If anyone is interested I updated my example Docker Django app to use Django 4.0 at: https://github.com/nickjj/docker-django-example It pulls together Django, Docker Compose, Postgres, Redis, Celery, Webpack and TailwindCSS. It's all set up for both development and production. It's also been updated to use Django 4's new built in Redis cache back-end instead of the django-redis package.

Here's an example on why a lock file is still very important when using Docker: Let's say it's June 19th and your project exists on GitHub and you have a requirements.txt file with only `Flask==2.0.1` in it. Now let's fast forward to October 19th and you clone the project and run a docker-compose build. You'll get Flask 2.0.1 but you might get a drastically newer version of Werkzeug, Jinja2, itsdangerous and Click because all of those dependencies are defined by Flask with the >= operator. Suddenly you have a Docker image that's much different than what it was in June and the only thing that changed is time. This becomes a problem because now it could potentially mean running different versions in dev, CI and production. This has bitten me in the past a few times with Werkzeug and also the Vine library with Celery where it pulled in newer

Honestly in practice everything tends to work fine without any hacks or extra scripts. I run all of my containers as a non-root user and create the user in the image with its default values of 1000:1000 for the uid:gid. I haven't bothered to expose the uid:gid as build arguments because it's pretty much never an issue in development or production. With a uid:gid of 1000:1000 built into the image any bind mounted files end up being correctly owned by the Docker host's user under the following conditions: - Docker Desktop on macOS - Docker Desktop on Windows using WSL 1 - Docker Desktop on Windows using WSL 2 and native Linux (as long as your dev box's user is set to 1000:1000) IMO it's really rare that your dev box's user wouldn't be 1000:1000 on native Linux or WSL 2. In production you also have full control over the uid:gid of your deplo