Enhanced Docker image for Radicale, the CalDAV/CardDAV server.
🔐Secured: run as a normal user, not root ✨Enhanced: add Git for versioning, Bcrypt for authentication and InfCloud as an alternative UI 🏗Multi-architecture: run on amd64, arm (RaspberryPI...) and others
Version, Tags and Multi-architecture
Version number = Architecture + '.' + Radicale version + '.' + increment number
Example: those tags were created for Radicale 2.1.10:
The last number is ours, incremented on changes. For example, 126.96.36.199 made the /config readonly (this is specific to this image).
Additionally, Docker Hub automatically build and publish this image as
tomsquest/docker-radicale (which by default is
docker run -d --name radicale \ -p 5232:5232 \ tomsquest/docker-radicale
docker run -d --name radicale \ -p 127.0.0.1:5232:5232 \ --read-only \ --init \ --pids-limit 50 \ --security-opt="no-new-privileges:true" \ --health-cmd="curl --fail http://localhost:5232 || exit 1" \ --health-interval=30s \ --health-retries=3 \ -v ~/radicale/data:/data \ -v ~/radicale/config:/config:ro \ tomsquest/docker-radicale
Custom User/Group ID for the data volume
You will certainly mount a volume to keep Radicale data between restart/upgrade of the container.
But sharing files from the host and the container can be problematic.
The reason is that
radicale user in the container does not match the user running the container on the host.
To solve this, this image offers four options (see below for details):
- Option 0. Do nothing, permission will be fixed by the container itself
- Option 1. Create a user/group with id
2999on the host
- Option 2. Specify a custom user/group id on
- Option 3. Build the image with a custom user/group
Option 0. Do nothing, the container will fix the permission itself
When running the container with a /data volume (eg.
-v /mydata/radicale:/data), the container entrypoint will automatically fix the permissions on
This option is OK but not optimal:
- Ok for the container, as inside it the radicale user can read and write its data
- But on the host, the data directory will then be owned by the user/group 2999:2999
Option 1. User/Group 2999 on the host
The image creates a user and a group with Id
You can create an user/group on your host matching this Id.
sudo addgroup --gid 2999 radicale sudo adduser --gid 2999 --uid 2999 --shell /bin/false --disabled-password --no-create-home radicale
Option 2. Custom User/Group at run
The user and group Ids used in the image can be overridden when the container is run.
This is done with the
GID env variables, eg.
docker run -e UID=123 -e GID=456 ....
But beware, the
--read-only run flag cannot be used in this case. Using custom UID/GID tries to modify the filesystem at runtime but this is made impossible by the
Option 3. Custom User/Group at build
You can build the image with custom user and group Ids and still use the
But, you will have to clone this repo, do a local build and keep up with changes of this image.
docker build --build-arg=UID=5000 --build-arg=GID=5001 ...
To customize Radicale configuration, either:
- Recommended: use this repository preconfigured config file,
- Use the original config file and:
hosts = 0.0.0.0:5232
filesystem_folder = /data/collections
Then mount your custom config volume when running the container:
To run the tests (your user will need to be a member of the
pip install pipenv
pipenv install -d
Create a Git tag, eg. 188.8.131.52, push it and Travis will build the images and publish them on Docker hub.