Radicale can be configured with a configuration file or with
command line arguments.
An example configuration file looks like:
# Bind all addresses
hosts = 0.0.0.0:5232
type = htpasswd
htpasswd_filename = /path/to/users
htpasswd_encryption = bcrypt
filesystem_folder = ~/.var/lib/radicale/collections
Radicale tries to load configuration files from
~/.config/radicale/config and the
RADICALE_CONFIG environment variable.
This behaviour can be overwritten by specifying a path with the
--config /path/to/config command line argument.
The same example configuration via command line arguments looks like:
python3 -m radicale --config "" --server-hosts 0.0.0.0:5232 --auth-type htpasswd --htpasswd-filename /path/to/htpasswd --htpasswd-encryption bcrypt
--config "" argument is required to stop Radicale from trying
to load configuration files. Run
python3 -m radicale --help for more information.
In the following, all configuration categories and options are described.
Most configuration options in this category are only relevant in standalone
mode. All options beside
realm are ignored,
when Radicale runs via WSGI.
A comma separated list of addresses that the server will bind to.
Daemonize the Radicale process. It does not reset the umask.
If daemon mode is enabled, Radicale will write its PID to this file.
The maximum number of parallel connections. Set to
0 to disable the limit.
The maximum size of the request body. (bytes)
Socket timeout. (seconds)
Enable transport layer encryption.
Path of the SSL certifcate.
Path to the private key for SSL. Only effective if
ssl is enabled.
Path to the CA certificate for validating client certificates. This can be used
to secure TCP traffic between Radicale and a reverse proxy. If you want to
authenticate users with client-side certificates, you also have to write an
authentication plugin that extracts the user name from the certifcate.
SSL protocol used. See python’s ssl module for available values.
Available ciphers for SSL. See python’s ssl module for available ciphers.
Reverse DNS to resolve client address in logs.
Message displayed in the client when a password is needed.
Radicale - Password Required
Encoding for responding requests.
Encoding for storing local collections
The method to verify usernames and passwords.
- Just allows all usernames and passwords. It also disables rights checking.
- Use an Apache htpasswd file to store
usernames and passwords.
- Takes the user name from the
REMOTE_USER environment variable and disables
HTTP authentication. This can be used to provide the user name from a WSGI
- Takes the user name from the
X-Remote-User HTTP header and disables HTTP
authentication. This can be used to provide the user name from a reverse
Path to the htpasswd file.
The encryption method that is used in the htpasswd file. Use the
or similar to generate this files.
- Passwords are stored in plaintext. This is obviously not secure!
The htpasswd file for this can be created by hand and looks like:
- This uses a modified version of the Blowfish stream cipher. It’s very secure.
The passlib python module is required for this. Additionally you may need
one of the following python modules: bcrypt, py-bcrypt or bcryptor.
- This uses an iterated md5 digest of the password with a salt.
The passlib python module is required for this.
- Passwords are stored as SHA1 hashes. It’s insecure!
- Passwords are stored as salted SHA1 hashes. It’s insecure!
- This uses UNIX
Average delay after failed login attempts in seconds.
The backend that is used to check the access rights of collections.
The recommended backend is
owner_only. If access to calendars
and address books outside of the home directory of users (that’s
is granted, clients won’t detect these collections and will not show them to
the user. Choosing any other method is only useful if you access calendars and
address books directly via URL.
- Everyone can read and write everything.
- Authenticated users can read and write everything.
- Authenticated users can read and write their own collections under the path
- Authenticated users can read everything and write their own collections under
the path /USERNAME/.
- Load the rules from a file.
File for the rights backend
from_file. See the
The backend that is used to store data.
- Stores the data in the filesystem.
Folder for storing local collections, created if not present.
Lock the storage. This must be disabled if locking is not supported by the
underlying file system. Never start multiple instances of Radicale or edit the
storage externally while Radicale is running if disabled.
Delete sync-token that are older than the specified time. (seconds)
Sync all changes to disk during requests. (This can impair performance.)
Disabling it increases the risk of data loss, when the system crashes or
Command that is run after changes to storage. Take a look at the
Versioning page for an example.
The backend that provides the web interface of Radicale.
- Just shows the message “Radicale works!”.
- Allows creation and management of address books and calendars.
Set the default logging level to debug.
Log all environment variables (including those set in the shell).
Don’t include passwords in logs.
Logging configuration file. See the Logging page.
In this section additional HTTP headers that are sent to clients can be
An example to relax the same-origin policy:
Access-Control-Allow-Origin = *