Skip to content

Small-scale deployment with Docker#

This guide describes the installation of a small-scale installation of i-ticket using docker. By small-scale, we mean that everything is being run on one host and you don't expect thousands of participants trying to get a ticket within a few minutes. In this setup, as many parts of i-ticket as possible are hidden away in one single docker container. This has some trade-offs in terms of performance and isolation but allows a rather easy installation.

Warning

Even though we try to make it straightforward to run i-ticket, it still requires some Linux experience to get it right. If you're not feeling comfortable managing a Linux server, check out our hosting and service offers at i-ticket.app/control.

We tested this guide on the Linux distribution Debian 12 but it should work very similar on other modern distributions, especially on all systemd-based ones.

Requirements#

Please set up the following systems beforehand, we'll not explain them here (but see these links for external installation guides):

  • Docker
  • A SMTP server to send out mails, e.g. Postfix on your machine or some third-party server you have credentials for
  • A HTTP reverse proxy, e.g. nginx or Apache to allow HTTPS connections
  • A PostgreSQL 14+ database server
  • A redis server

We also recommend that you use a firewall, although this is not a i-ticket-specific recommendation. If you're new to Linux and firewalls, we recommend that you start with ufw.

Note

Please, do not run i-ticket without HTTPS encryption. You'll handle user data and thanks to Let's Encrypt SSL certificates can be obtained for free these days. We also do not provide support for HTTP-only installations except for evaluation purposes.

Warning

By default, using ufw in conjunction with docker will not have any effect. Please make sure to either bind the exposed ports of your docker container explicitly to 127.0.0.1 or configure docker to respect any set up firewall rules.

On this guide#

All code lines prepended with a symbol are commands that you need to execute on your server as user; all lines prepended with a symbol can also be run by an unprivileged user.

Data files#

First of all, you need to create a directory on your server that pretix can use to store data files and make that directory writable to the user that runs pretix inside the docker container:

The directory must also be readable for your webserver. Depending on your security requirements, you can set chmod on the folder or use an ACL for more fine-grained control.

Database#

Next, we need a database and a database user. We can create these with any kind of database managing tool or directly on our database's shell. Please make sure that UTF8 is used as encoding for the best compatibility. You can check this with the following command:

For PostgreSQL database creation, we would do:

Make sure that your database listens on the network. If PostgreSQL on the same same host as docker, but not inside a docker container, we recommend that you just listen on the Docker interface by changing the following line in :

You also need to add a new line to to allow network connections to this user and database:

Restart PostgreSQL after you changed these files:

If you have a firewall running, you should also make sure that port 5432 is reachable from the subnet.

Redis#

For caching and messaging in small-scale setups, pretix recommends using redis. In this small-scale setup we assume a redis instance to be running on the same host. To avoid the hassle with network configurations and firewalls, we recommend connecting to redis via a unix socket. To enable redis on unix sockets, add the following to your :

Now restart redis-server:

In this setup, systemd will delete on every redis restart, which will cause issues with pretix. To prevent this, you can execute:

And insert the following:

Warning

Setting the socket permissions to 777 is a possible security problem. If you have untrusted users on your system or have high security requirements, please don't do this and let redis listen to a TCP socket instead. We recommend the socket approach because the TCP socket in combination with docker's networking can easily become an even worse security hole when configured slightly wrong. Read more about security on the redis website.

Another possible solution is to run redis in docker and link the containers using docker's networking features.

Config file#

We now create a config directory and config file for pretix:

Fill the configuration file with the following content (adjusted to your environment):

See Email settings to learn more about configuring mail features.

Docker image and service#

First of all, download the latest stable i-ticket image by running:

We recommend starting the docker container using systemd to make sure it runs correctly after a reboot. Create a file named with the following content:

You can now run the following commands to enable and start the service:

Cronjob#

You need to set up a cronjob that runs the management command . The exact interval is not important but should be something between every minute and every hour. You could for example configure cron like this:

The cronjob may run as any user that can use the docker daemon.

SSL#

The following snippet is an example on how to configure a nginx proxy for i-ticket:

We recommend reading about setting strong encryption settings for your web server.

Next steps#

Yay, you are done! You should now be able to reach pretix at https://pretix.yourdomain.com/control/ and log in as admin@localhost with a password of admin. Don't forget to change that password! Create an organizer first, then create an event and start selling tickets!

You should probably read Backups and monitoring next.

Updates#

Warning

While we try hard not to break things, please perform a backup before every upgrade.

Updates are fairly simple, but require at least a short downtime:

Restarting the service can take a few seconds, especially if the update requires changes to the database. Replace above with a specific version number like or with for the development version, if you want to.

Make sure to also read Update notes and the release notes of the version you are updating to. Pay special attention to the "Runtime and server environment" section of all release notes between your current and new version.

Install a plugin#

To install a plugin, you need to build your own docker image. To do so, create a new directory and place a file named in it. The Dockerfile could look like this (replace with the plugins of your choice):

Then, go to that directory and build the image:

You can now use that image instead of in your service file (see above). Be sure to re-build your custom image after you pulled if you want to perform an update.

Scaling up#

If you need to scale to multiple machines, please first read our scaling guide.

If you run the official docker container on multiple machines, it is recommended to set the environment variable on all containers and run on one machine after each upgrade manually, otherwise multiple containers might try to upgrade the database schema at the same time.

To run only the component of pretix as well as a nginx server serving static files, you can invoke the container with (instead of ). You can adjust the number of processes with the environment variable (defaults to two times the number of CPUs detected).

To run only , you can run . You can also pass arguments to limit the worker to specific queues or to change the number of concurrent task workers, e.g. .