Install Tryton in a Python virtual environment on Ubuntu


With this guide you will get a working base Tryton installation. At the end we will also look at installing modules.

There are a few things to consider, so before you start:

  • We assume that you have a clean installation of your OS.
  • You have commandline knowledge and it does not scare you.
  • You know how apt-get is working.
  • This guide is based on Ubuntu but other (Ubuntu / Debian) flavors should also work. If you are comfortable with Linux, you can easily translate the commands to a RPM based system like RedHat, Fedora, RockyLinux, AlmaLinux etc.
  • This guide is NOT intended for development of Tryton or its modules.
  • This guide gives you just an example how to configure things.
  • Commands are not described in detail. Everything about them can be found on the internet.

Note: In the guide we use:

  • trydbuser as the database user
  • trydbpass as the database password
  • trydb as the database name
  • trypyenv as the name for the virtual environment
  • trysysuser as the name for the system user which will run the Tryton server
  • /srv/tryloc as the place where the venv will be put

You can choose whatever you want and replace the names accordingly.

Install the PostgreSQL Database Server

Tryton needs a database to store the data you enter and that’s done with PostgreSQL.

Note: If you already have a working PostgreSQL server, you can skip to the next section.

Install PostgreSQL

To install PostgreSQL run:

testadmin@docsrv:~$ sudo apt-get install postgresql

This will install PostgreSQL, configure it and start the server. You can check this with:

testadmin@docsrv:~$ sudo systemctl status postgresql

This will give you a lot of output like

● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor pr>
     Active: active (exited) since Mon 2020-11-16 15:29:45 UTC; 1min 15s ago
   Main PID: 4682 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4620)
     Memory: 0B
     CGroup: /

The most important part are the green dot and next to the word “Active:” it should say “active” in green.

Info: If you want to start PostgreSQL automatically on next boot run:

testadmin@docsrv:~$ sudo systemctl enable postgresql

Create the Database User and Database

PostgreSQL is now running so we can add a new user to it. This user is used by Tryton to connect to the database, populate it and store the data.

Create the trydbuser user with:

testadmin@docsrv:~$ sudo -u postgres createuser trydbuser --password

You will be prompted to enter a password, this is the password you want to use for the database. Enter trydbpass here.

Info: It is possible that you first have to enter the sudo password.

Then create a new empty database with the newly created user as the owner of that database:

testadmin@docsrv:~$ sudo -u postgres createdb -O trydbuser trydb

Try to logging in to PostgreSQL as the newly created user and database:

testadmin@docsrv:~$ psql -h localhost -U trydbuser -d trydb

And enter trydbpass as the password. You should see the database prompt like

psql (<version data>)
SSL connection (<SSL information>)
Type "help" for help.


Exit the database by typing \q at the prompt.

We can connect as the user trydbuser to the database trydb, so it’s time to install Tryton.

Install Tryton into a Python Virtual Environment

A Python virtual environment (called venv hereafter) is an environment, isolated from the globally installed Python packages. The main reason to install Tryton in a venv is because some packages conflict with the system packages. And sometimes different packages depends on a different version of another package. But the biggest reason is that you can run multiple Tryton instances next to each other. Just change the port they are running on and you are done.

Also you can freely do things without harming the rest of your Python installation.

The python docs contain more information about venvs.

Install python3-venv

Before creating the venv, ensure the venv package is installed:

testadmin@docsrv:~$ sudo apt-get install python3-venv

You can create the new venv everywhere on your filesystem. But normally you would:

  1. create a venv in your homedirectory so you can mess with it, or do development
  2. create a venv on your filesystem location which can be easily reached by services

As the intention of this guide is to have a working Tryton server we go with point 2. But point 1 can be seen as a smaller set of steps of point 2.

Setup a new system user who will run Tryton server

The Tryton server have to run under a specific user, so let’s create that user

Info: When you create a new venv in your homedirectory, you don’t need this user.

testadmin@docsrv:~$ sudo useradd -m -U -r -d /srv/tryloc -s /bin/bash trysysuser

Create and Activate the Virtual Environment

Because you want to create the venv as the newly created trysysuser, you have to switch to that user. To do so execute

testadmin@docsrv:~$ sudo su - trysysuser

Your commandprompt should change to:


Next cd into the created homedirectory

$ cd /srv/tryloc

Now create a new virtual environment.

trysysuser@docsrv:~$ python3 -m venv --system-site-packages .

Warning: Don’t forget the . at the end of the command. This tells Python to create a virtual environment in the current directory. If you want to install the virtual environment somewhere else, you can replace the . with the path to the place you want to install the environment.

Note: We are using the Python version used by the distribution. Most distributions also have a newer version of Python in their repositories. For example: RockyLinux 9.3 had Python 3.9 as default, but you can also install Python 3.11. In this case you should use python3.11 -m venv --system-site-packages . .

Activate the virtual environment with the following command:

trysysuser@docsrv:~$ source bin/activate

You commandprompt should change to:

(tryloc) trysysuser@docsrv:~$

so you know that you have your venv activated.

Install the Tryton Server

Upgrade pip itself first:

(tryloc) trysysuser@docsrv:~$ pip install --upgrade pip

trytond needs to connect to PostgreSQL and needs the package psycopg2 for that. Installing this package from source also means compiling some source code, so it will be easier to install the precompiled version:

(tryloc) trysysuser@docsrv:~$ pip install psycopg2-binary

Then install the Tryton Server.

(tryloc) trysysuser@docsrv:~$ pip install trytond

This will install the most recent version of Tryton.

Info: You can install another version. pip install trytond==6.0.* will install the latest version of trytond series 6.0. However you can only have one version installed per venv. Create a new venv to install another version. Also be aware that you also have to create a new database!

Create the trytond Configuration File

Create a trytond.conf in the root (/srv/tryloc) of your venv. This will contain the configuration settings used by the trytond service.

(tryloc) trysysuser@docsrv:~$ nano trytond.conf

The most important part of the configuration is the database uri. Add the flowing lines

uri = postgresql://trydbuser:trydbpass@localhost:5432/
language = en

Save and close the editor with <CTRL> + X.

Initialize the Database

Now it’s time to see if Tryton can connect to the created database. Execute:

(tryloc) trysysuser@docsrv:~$ trytond-admin -c trytond.conf -d trydb --all -vv

You should see a lot of messages on the screen, but they should all have “INFO” in the name and are telling you that your Tryton system is being loaded into the database. At the end you will be asked for an admin email and password. Make sure you remember the password you enter because you will need this password when you login to Tryton for the first time.

Info: To see what other arguments you can use do a (tryloc) trysysuser@docsrv:~$ trytond-admin --help.

Start the Tryton Server

To run Tryton use:

(tryloc) trysysuser@docsrv:~$ trytond -c trytond.conf -d trydb

Installing modules

Tryton is loved because of its great flexibility and modularity. It gives you a solid base that you can build upon. But this means that the base is only a base and that you have to add modules to extend that base with new functionality. There are 3 methods to install modules:

  • use pip
  • download the module from any version controlled repository (git, hg, svn, …) and install it
  • same as above, but instead of installing it, link it in to the trytond-modules directory

Note: We don’t cover the last one, as this is something that is often used when doing fast development of modules.

After you have installed several modules you have to update the database so Tryton knows there are new modules available.

(tryloc) trysysuser@docsrv:~$ trytond-admin -c trytond.conf -d trydb -m -vv

Find the Modules You Need

The first thing you should do when searching for modules is visiting Tryton Documentation — Tryton Documentation for information about the set of standard modules.
You can read the documentation what they do and eventually install them. These modules are developed and supported along with the server and clients.

Installing with Pip

Using pip is the most easy thing to do.

You can get the module name from the documentation. The name is a bit hidden in plain sight. Take for example the module dunning_email and look at the description of the module:

Account Dunning Email Module

The account_dunning_email module sends a dunning email to the party email contact after the process of dunnings for those which are at a level with Send Email checked. The template of the email is defined on the level.

As you can see the module name is account_dunning_email. To install this module prefix it with trytond- so you get trytond-account_dunning_email

Also there is a Tryton classifier on PyPI which can be used to get a list of all pip installable modules.

Warning: If you have installed a different Tryton version then the most recent one, also use the ==6.X.* when you install modules.

Now you know the module name you can install it with pip.

Warning: Make sure your venv is activated!

(tryloc) trysysuser@docsrv:~$ pip install trytond-account_dunning_email

This will install the most recent version of the account_dunning_email module including the modules it depends on. Update the database so Tryton knows about it.

From a version controlled repository

To install modules from a version controlled repository you will probably want to clone the repository somewhere inside your venv. Maybe even in a sub directory. Then install it from there:

(tryloc) trysysuser@docsrv:~$ <command to clone the repository, git, hg, or svn. Search the internet for the right command>
(tryloc) trysysuser@docsrv:~$ cd <repo name>
(tryloc) trysysuser@docsrv:~$ python3 install

Update the database so Tryton knows about it.

Uninstall a module

Warning: Uninstalling modules can create trouble because changes they made can’t sometimes be undone like altering a database table with new columns. Also uninstalling is still in development.

Sometimes you have tested a module and want to remove it. First you need to deactivate it in Tryton. After that, you can uninstall the module with:
(tryloc) trysysuser@docsrv:~$ pip uninstall <module_package_name>

Warning: The module_package_name is not necessarily the name of the module. To find the correct module_package_name open the module’s file with your favorite editor and search for the key name = ..... Then use that to uninstall the module.

Update the database so Tryton knows the module is gone.

Install the desktop client

Warning: You should still have the Tryton server running. So it’s better to start a new commandline.

In the previous sections we installed the server side of Tryton. Now it’s time to install the client side.
Because the client will not be ran as trysysuser deactivate the venv and exit back to the ‘normal’ user.

(tryloc) trysysuser@docsrv:~$ deactivate && exit

You commandline will now look like:


Switch back to your homedirectory

testadmin@docsrv:~$ cd

There are two different clients that are commonly used:

  • Desktop client (GTK)
  • Web client (sao)

Note: Installing the webclient is not covered in this guide but will be in a separate guide when deployed in production.

Download the Desktop Client

Note: You can also install the Desktop client through FlatPak Search for 'tryton' | Flathub so you can skip this section entirely. However, keep the versions right! (see table below)

Download the Desktop Client from Tryton - Get Tryton. For GNU/Linux there is now a flatpak version available. But if you want to build the client from source you can download the client from This is the client for Tryton series 6.0. Replace the 6.0 with the series you want to use.

Warning: The series of the client MUST match the series of the server. The third digit of the version is not important, it just shows the bugfix release. So:

| client | server | Will it Work? |
| 5.4.3  | 5.4.11 |      Yes      |
| 5.4.3  | 5.8.3  |      No       |
| 6.0.6  | 6.0.2  |      Yes      |

Install the Desktop Client

Unpack the client into a directory.

testadmin@docsrv:~$ tar -zxvf tryton-last.tar.gz

You now have two possibilities:

  • Run the client from the directory:

testadmin@docsrv:~$ ~/tryton-6.0.<version>/bin/tryton

  • Install the client system wide and then run the client:

testadmin@docsrv:~$ cd ~/tryton-6.0.<version>
testadmin@docsrv:~$ sudo python3 install
testadmin@docsrv:~$ tryton

Warning: In the last case you only can use one version of the client!

When you start tryton you will see a dialog box. Enter the appropriate paramaters and try to connect. Use

host: localhost
database: trydb
user: admin

Info: Sometimes you have to “click” on the “Host / Database information” label to see the extra information.

As password use the password you’ve entered when you initialized the database.

Making Tryton available over the network

Tryton by default listens for connections to the localhost, so when you have Tryton installed on your headless server, you won’t be able to do much.

Update the Tryton Configuration

To make Tryton listen to the rest of the network you have to make some changes to the trytond.conf.

(tryloc) trysysuser@docsrv:~$ nano trytond.conf

And add a new section:

listen =
root = /srv/tryloc/webdata

Save the changes and close the editor. As you can see we have also added a root location. This location will be used by Tryton for static files when you connect with a webbrowser. This location does not exist yet so we have to create it with:

(tryloc) trysysuser@docsrv:~$ mkdir /srv/tryloc/webdata

Restart the Tryton Server

Restart Tryton to reload the configuration settings. Use <CTRL> + C to stop the server and

(tryloc) trysysuser@docsrv:~$ trytond -c trytond.conf -d trydb

to start Tryton again.

Ensure the Firewall Allows Connections

Once Tryton has restarted try to connect to it from another system. As host use the hostname of the server you installed Tryton on or use it’s ip-address

Note: Often connection problems can be caused by a firewall blocking any connection attempts. You have to open port 8000 to make it possible for traffic to reach Tryton.

testadmin@docsrv:~$ sudo ufw allow 8000/tcp


You have now a running Tryton system installed on Ubuntu. Most of the commands are also viable for RedHat and it’s derivatives.


I followed your protocol and was able to install and run a trytond server. I transferred the data from an older installation and am able to connect to the server with the desktopclient on localhost:8000.
Then I followed the ‘Making Tryton available over the network’ process steps by the book.
When I try to connect to the server from another machine I get an error: ERROR: tryton.rpc:[Errno -3] Temporary failure in name resolution.
From the machine on which I start the desktop client I can succesfully ping the server IP.
Does someone know what the error points to?

Did you also use the ip address in the desktop client?

Can you change the line listen = to listen = <your.server.ip.address>:8000 in your trytond.conf, restart Tryton and try to connect again?

changing the listen =… line in the trytond.conf file did the trick. Thanks! I now have a running trytond server accessible through the internet from a tryton desktop client.

Even if it’s nice to have a running system now, please don’t! Not in this configuration because Werkzeug is primarily a development server and security is not it;s thing.
If you want to go ahead this way (keep Werkzeug), add a layer of protection like OpenVPN or WireGuard. Also if possible add geo blocking in the firewall and open only a minimal set of addresses. All to make the attack vector as small as possible.

That said, thanks for ‘testing’ the guide and that it worked for you!

Do you know of any specific attack vectors that affect Tryton? I found a couple vulnerabilities reported for Werkzeug 2.0.2 (a DoS vulnerability and an Action Restriction Bypass vulnerability, which seemed to depend on a malicious application on an adjacent sub-domain), but didn’t see anything for Werkzeug 3.0.1 used in Tryton 6.8.

@edbo Thanks for pointing out the security problems. I read in other posts that the way to use Tryton over the net is through a nginx or apache2 webserver. I do have a apache2 webserver running and would like very much to configure my Tryton server to be used. From what I read in other posts the way to do it could be apache2 reverse proxy setup.
Can anyone help me with that? I am familiar with apache2 and I have already created a ssl certificate with certbot for another website. I do have a registered domain to be used for the Tryton setup. I also am familiar with configuring apache2 virtual hosts.

No, but when I open something to the internet I’m always cautious and try to minimize the attack vector. When you are testing or developing a custom module or something along those lines, I recommend to do it locally.

I’m not familiar with Apache, but searching the internet it seems you can use Apache with Gunicorn. So you can setup the base with Gunicorn and you have to change the NginX configuration into Apache. See it’s for Django, but it also should apply for Tryton. Also search for apache reverse proxy etc. Another one

Thanks for the reply.
Between the lines I read that you are using nginx, am I right? If you think that that is a better approach I would follow your advice.

That’s correct, see and

I thought you read those one as well. They are based on NginX and Gunicorn.

I personally want to use the tools I know and where I’m familiar with. If you are familiar with Apache, go for it. You already have setup a running system which even more plead for keeping Apache. You just have to setup a reverse proxy. You can follow to get Tryton running with Gunicorn. Then you can read the section how to setup NginX but you have to use your knowledge to convert the idea to Apache. Looking at the links I provided and the examples it shouldn’t be that hard to get it running.

I am currently going through the script again with the purpose of creating a production server.
At the point where the virtual environment is generated, command:
python3 -m venv --system-site-packages
I am getting the error ‘venv: error: the following arguments are required: ENV_DIR’
the command python3 -m venv --system-site-packages
creates a virtual environment in the directory ‘directoryname’. Is it possible that in your protocol is missing or is the error mine?

You are missing the . at the end. The command should be:

 python3 -m venv --system-site-packages .

The . means “create the virtual environment here”.

I clearified the command a bit in the start post as well. Thanks for going through it.

In the second run I am at the point to start the desktop client. In contrast to the first run, this time I followed your script ‘by the book’ i.e. I created a new sytem user and created the venv in /srv/tryloc. The first time I was in the home directory and used the home user.
Now, when trying to start the desktop client I get the error:
Authorization required but no authorization protocol specified
(tryton:234774): Gtk-ERROR **: Can’t create a GtkStyleContext without a display connection.
The desktop client is installed in the virtual environment, in case that’s important.

Well that shouldn’t be a problem, I’m using this as well for development and works perfectly.

testadmin@docsrv:~$ mkdir -p ~/Projects/my_tryton_install
testadmin@docsrv:~$ cd ~/Projects/my_tryton_install
testadmin@docsrv:~$ python3 -m venv --system-site-packages .

For the last command you can also use

testadmin@docsrv:~$ python3 -m venv --system-site-packages ~/Projects/my_tryton_install

On which side do you get this error? On the server side or the client side?

Normally I just download the source code, extract it and run it so no virtual environment for the client. You are missing some parts like calendar view but for the first setup it should be ok. You can also install the desktop client through Flatpak Search for 'tryton' | Flathub

I am getting the error on the client side. The client is installed in the same virtual environment as the server. When starting the client from the activated virtual environment with the command ‘tryton’ I get the error.

In the second run I was following your suggestion to create a new user and using the /srv/trydoc location because ultimately I want to create a production environment. Thus a new user in a separate environment are good in terms of security, I guess.

AHHH, you got me! You cannot run the client as that user because it’s a system user not a regular user. So running the client from the environment as that new user won’t work. You should run the client as your regular user.

The new user is added specific for running Tryton indeed. So when you do other things on the server you don’t disrupt the user but also don’t give it rights by accident to execute other programs you have running.

ok, that’s exactly what I want. I guess the next step will be to make the server available on the internet which you descibe in great detail here 6747. I will try to use your protocol and adapt it to apache2.

1 Like

I am using Apache2 for hosted PHP apps, and had planned to follow @edbo’s production server NginX/Gunicorn recipe, but if you post your adventure I will eagerly follow to decide if I should instead my existing Apache stack. I expect an NginX/Gunicorn stack to be more efficient in terms of server CPU cycles and memory, but it will also require more learning and maintenance effort.

You may find the “How we used Tryton to build an insurance ERP” presentation at TUB 2016 of interest because it describes in considerable detail the challenges Coopengo surmounted to achieve their desired level of operations (the presentation refers to 1M invoices per month for 1M insurance contracts, and iiuc the video mentions the number of simultaneous users). The presentation is a few years old, but I think the technology is still relevant (spoiler, they use NginX).

You can also use Gunicorn with Apache. So the difference will then between NginX and Apache as reverse proxy. Personally I don’t think there will be a huge difference between them. NginX got popular because it was very easy to configure as reverse proxy.

I haven’t seen the whole video but generating 1M invoices is all backend work, so basically the webserver is sleeping, but Gunicorn or other WSGI server is hard at work. Also there are now worker queue’s which can do work in parallel but the biggest bottleneck is the invoice number sequence which should not have holes. That’s still a sequential process which slows down the whole operation.

1 Like

Yes, I confirm I’m happy with Apache2.

1 Like