Tryton ERP 8.0 LTS on AWS User Guide

Overview

This guide covers launching and using the Tryton ERP 8.0 LTS on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg ERP and CRM listing on AWS Marketplace; you choose it as the software version when you subscribe and launch.

Tryton is a free, modular business suite. The Tryton server (trytond) keeps its data in PostgreSQL, and the sao web client is the browser interface. This image activates the core ERP modules: parties and companies, products, accounting and invoicing, stock, sales, purchasing, production, projects and timesheets, with their price-list, payment, statement, asset, analytic, supply and routing companions.

The cloudimg image is a hardened, ready-to-use Tryton server:

• HTTPS from the first boot, with a certificate generated on your instance (an end-entity certificate, not a certificate authority), TLS 1.2 and 1.3 only. Port 80 only redirects to HTTPS. Requests for a host name the instance does not serve are dropped.
• nginx in front, Tryton behind it. nginx is the only public web listener. It serves the sao web client as static files and passes the JSON-RPC calls to the Tryton server, which runs under gunicorn on 127.0.0.1:8000 only. nginx sets the client address from the real connection (a forged X-Forwarded-For or X-Real-IP is overwritten), refuses a call whose Origin is another site, limits requests per IPv4 address or IPv6 /64, and adds HSTS, a strict Content Security Policy, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: same-origin and a Permissions-Policy that turns off the camera, microphone and location.
• No default account. The image ships with no database. First boot creates the tryton database and its admin user with a password generated on your instance, and writes it to a root-only file. No known password exists at any time.
• Database manager closed. The sign-in dialog does not list databases (common.db.list answers 403), and Tryton 8.0 has no remote call that creates, drops, dumps or restores a database. Nobody can create a database or replace yours from the network.
• PostgreSQL on its local socket only. PostgreSQL 16 listens on no TCP port. The Tryton server connects over the Unix socket as the role tryton, with a database password generated on your instance.
• Mail off, and an outbound block. No mail relay is configured, and no update check or telemetry exists. The Tryton server and its scheduler are refused, by nftables and by systemd, every connection to the EC2 metadata service, to link-local and reserved ranges, to this instance's own VPC ranges, to the loopback address and to IPv6. A mail server, webhook or report URL typed into Tryton cannot reach the metadata service or a private address in your VPC. You open a relay in your VPC with one line (Step 10).
• An unprivileged service. The Tryton server runs as the tryton account, which has no shell, no password and no sudo rights, under systemd with NoNewPrivileges. The program and the web client's files are owned by root and the Tryton server cannot change them. Attachments are stored in /var/lib/tryton/filestore, which nginx never serves.
• Built from pinned releases. trytond, its modules and every Python package are installed from SHA-256-pinned releases, and the sao web client is the pinned upstream release (already built upstream: no Node.js or npm is on the image). nginx, PostgreSQL and Python come from the Ubuntu 24.04 main archive and are patched by Ubuntu's security updates.

What is on the image: Tryton 8.0 LTS (trytond 8.0.14 with 30 modules and the sao 8.0.14 web client), gunicorn 27.0.0, PostgreSQL 16 and nginx 1.24 from Ubuntu 24.04, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
• A security group that allows TCP 22 (SSH), TCP 443 (the web client) and TCP 80 (redirects to HTTPS) from the networks your users are on. Do not open 8000 or 5432: the Tryton server listens on the loopback address only and PostgreSQL on no TCP port.
• IMDSv2 enabled (the default for this AMI). First boot reads the instance's name from the metadata service, and the outbound block reads the VPC ranges at every boot (Step 11).
• For production, a DNS name you control (for example erp.example.com) and, ideally, a certificate from a certificate authority. Until then the instance uses its EC2 public DNS name with its own self-signed certificate.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Tryton ERP 8.0 LTS on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large (or larger for many concurrent users), your key pair, and a security group as above.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=tryton}]'

First boot takes a few minutes after the instance is running: it creates the database role and the tryton database, activates the ERP modules, imports the ISO currencies and countries (from data on the image, with no network access), generates the administrator password and the certificate, then starts the Tryton server and nginx. nginx does not answer until first boot has finished. The instance is named by its EC2 public DNS name (or its public IP address, or its private name or address when it has no public one), and its addresses redirect to that name.

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows where the address and the password are:

  Tryton ERP 8.0 on Ubuntu 24.04 (cloudimg)
  URL and admin password:  sudo cat /root/tryton-credentials.txt
  Services: systemctl status nginx postgresql tryton tryton-cron tryton-egress-guard
  User guide:  https://www.cloudimg.co.uk/guides/tryton-erp-8-0-on-ubuntu-24-04-aws/

Step 3: Check the services

systemctl is-active postgresql@16-main nginx tryton tryton-cron tryton-egress-guard

active
active
active
active
active

The listeners: SSH, HTTP and HTTPS for everyone, and the Tryton server on the loopback address. PostgreSQL has no TCP listener:

sudo ss -Htln | awk '{print $4}' | sort -u

0.0.0.0:22
0.0.0.0:443
0.0.0.0:80
127.0.0.1:8000
127.0.0.53%lo:53
127.0.0.54:53
[::]:22
[::]:443
[::]:80

(127.0.0.53 and 127.0.0.54 are Ubuntu's local DNS resolver.) A quick check from the instance itself, without a password:

curl -sk https://127.0.0.1/healthz

ok

Step 4: Read the address, the password and the certificate fingerprint

Everything first boot generated is in /root/tryton-credentials.txt (root only). The web address, the database, the users and the certificate's SHA-256 fingerprint:

sudo grep -E '^TRYTON_(URL|DATABASE|ADMIN_USER|DB_USER|TLS_SHA256)=' /root/tryton-credentials.txt

TRYTON_URL=https://ec2-203-0-113-10.compute-1.amazonaws.com/
TRYTON_DATABASE=tryton
TRYTON_ADMIN_USER=admin
TRYTON_DB_USER=tryton
TRYTON_TLS_SHA256=35:C1:DC:F8:49:5D:59:06:7E:2E:BE:06:9A:92:D7:5D:E1:BE:5C:2B:AA:8F:4B:FB:D4:6D:1B:7E:1D:88:47:30

The same file holds TRYTON_ADMIN_PASSWORD and TRYTON_DB_PASSWORD (the PostgreSQL password of the tryton role, which /etc/tryton/trytond.conf also holds). Read them with sudo cat /root/tryton-credentials.txt when you need them, and keep them out of tickets and chat. The certificate is self-signed for this instance: when a browser asks you to trust it, compare its SHA-256 fingerprint with TRYTON_TLS_SHA256.

Step 5: Sign in to the web client

Open TRYTON_URL in a browser and accept this instance's certificate after comparing its fingerprint. The sign-in dialog asks for:

• Database: tryton. Type it: the dialog does not list databases on this image.
• User name: admin, then Login, and the password TRYTON_ADMIN_PASSWORD when it is asked for.

On the first sign-in Tryton opens the Module Configuration wizard. Choose OK to go through the setup wizards (your company, its currency and its chart of accounts) or Cancel to do it later from Administration > Modules > Config Wizard Items. The menu on the left holds every activated module.

A wrong password, an unknown user or a call without a session is refused. Tryton allows 5 failed sign-ins for a user name and 300 for a client network before it answers "Too many requests", with a growing delay. nginx also limits, per IPv4 address or IPv6 /64, the cookie sign-in route to 10 a minute, every POST to 600 a minute and every request to 1800 a minute.

Step 6: Parties, sales and the rest of the ERP

Every customer, supplier and contact is a party. Open Parties > Parties to see the list, and the New button to create one; the tabs of the form (Supplier, Accounting, Stock, Sale) come from the activated modules. The image ships with an empty database, so the lists start empty.

Sales > Sales holds quotations and orders by state (Draft, Quotation, Confirmed, Processing, Exception); Purchases, Inventory & Stock, Financial, Productions, Projects and Timesheet work the same way. Set up your company and its fiscal year first (the Module Configuration wizard, or Financial > Configuration), because invoices, stock moves and sales belong to a company.

More Tryton 8.0 modules ship on the image but are not activated, for example sale_price_list, stock_supply, account_asset, account_payment, account_statement, analytic_account, production_routing and project_revenue. Activate one under Administration > Modules > Modules, or from SSH:

sudo tryton-admin -d tryton -u sale_price_list --activate-dependencies
sudo systemctl restart tryton tryton-cron

tryton-admin runs Tryton's own trytond-admin as the tryton account with this instance's configuration and the same outbound block as the service.

The rich-text (HTML) editor page. Text fields in the web client use sao's own rich-text widget, which works on this image. Tryton's separate HTML editor page (/<database>/ir/html/..., opened by the Tryton desktop client) loads the TinyMCE editor from cdn.tiny.cloud. The Content Security Policy on this image allows scripts from this instance only, so that page is unavailable; the web client is not affected.

Step 7: Users and access rights

Create a user for each person under Administration > Users and give each the groups they need (for example Sales, Purchase, Account or Stock). Use your own users for daily work and keep admin for administration.

Step 8: Change the administrator password

sudo tryton-set-password

tryton-set-password: password updated for admin; every session signed out (see /root/tryton-credentials.txt)

This gives admin a new random password and stores it in /root/tryton-credentials.txt as TRYTON_ADMIN_PASSWORD; it is never printed and never on a command line. To choose the password yourself (20 to 72 letters and digits), pipe it in with sudo tryton-set-password --stdin. You can also change it in the web client under the user's Preferences.

Step 9: Use your own domain and certificate

Point a DNS name at the instance, then make it the instance's name. The command generates a new self-signed certificate for the name, makes it the only name nginx serves (the instance's addresses redirect to it, other names are dropped), writes it as Tryton's [web] hostname (used in the links of Tryton's mails), restarts the Tryton server and reloads nginx:

sudo tryton-set-hostname erp.example.com

The name is kept in /etc/cloudimg/tryton-hostname. If the instance's public DNS name changes after a stop and start (no Elastic IP), run tryton-set-hostname again with the new name.

To use a certificate from a certificate authority, run tryton-set-hostname first, then replace /etc/nginx/ssl/tryton.crt (the full chain) and /etc/nginx/ssl/tryton.key (root only, mode 0600) and reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Running tryton-set-hostname again replaces the certificate with a new self-signed one, so copy your certificate back afterwards. You can also put an Application Load Balancer with an ACM certificate in front of the instance.

Step 10: Send email (a relay)

Outbound mail is off: no relay is configured, and Tryton's default (smtp://localhost:25) is refused by the outbound block. To send mail, add the relay to /etc/tryton/trytond.conf (root and the tryton group only; it also holds the database password), for example with sudoedit /etc/tryton/trytond.conf:

[email]
uri = smtp+tls://<user>:<password>@email-smtp.us-east-1.amazonaws.com:587
from = erp@example.com

Use smtp+tls:// for STARTTLS on port 587 or smtps:// for TLS on port 465, so the relay password never crosses the network in clear text. Then restart the Tryton server and its scheduler:

sudo systemctl restart tryton tryton-cron

A relay on a public address needs nothing else. A relay on a private address in this VPC (or a VPC interface endpoint) is refused by the outbound block until you list it, one IPv4 address or CIDR per line:

echo '10.0.5.25' | sudo tee -a /etc/cloudimg/tryton-egress-allow.conf
sudo systemctl restart tryton-egress-guard

The EC2 metadata service, link-local and reserved ranges, the loopback address and IPv6 can never be opened.

Step 11: The outbound block and the VPC ranges

The outbound block (tryton-egress-guard, nftables) is loaded at every boot before the Tryton server, which does not start without it. It reads this VPC's IPv4 ranges from the metadata service each time:

sudo journalctl -b -u tryton-egress-guard -o cat | grep OK

tryton-egress-guard: OK: uid 997 egress backstop loaded (VPC blocks refused: 172.31.0.0/16; allow-list: none)

If the VPC ranges cannot be read (for example because the metadata service was switched off), the block fails closed: it refuses all of 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 instead and leaves a note in /run/cloudimg/tryton-egress-fallback. Turn IMDSv2 back on (aws ec2 modify-instance-metadata-options --instance-id <id> --http-endpoint enabled --http-tokens required), then sudo systemctl restart tryton-egress-guard. The ruleset in force is in /run/cloudimg/tryton-egress.nft.

Step 12: Check the whole instance

The self-test proves, end to end over HTTPS, the redirect from HTTP, the health check, the web client and its scripts, that a foreign Origin and the database list are refused, that no database-management call exists, that admin signs in with this instance's password (preferences, the ERP modules active, a party created, read and deleted) and that a wrong or default password is refused:

sudo tryton-cred-roundtrip

TRYTON_ROUNDTRIP_OK https 301 + healthz + web client and scripts + foreign Origin 403 + database list 403 + no database-management RPC + admin sign-in (JSON-RPC: preferences, ERP modules active, party create/read/delete) + wrong and default passwords refused

Step 13: Backups

Everything is in the tryton PostgreSQL database and the file store. A database dump (as PostgreSQL's own account, over the local socket) and an archive of the file store:

sudo -u postgres pg_dump -Fc -f /var/tmp/tryton-$(date +%F).dump tryton
sudo tar -C /var/lib/tryton -czf /var/tmp/tryton-filestore-$(date +%F).tar.gz filestore

Copy both off the instance, or take EBS snapshots or use AWS Backup, and treat the backups as business data. To grow the disk, modify the EBS volume, then sudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1.

Step 14: Versions, licences and source

cat /usr/share/doc/tryton/SOURCE.txt

Tryton is free software under the GNU General Public License version 3 or later. SOURCE.txt says where every component came from (the sao release with its SHA-256, the 59 SHA-256-pinned Python wheels and the web client's JavaScript packages) and where the source code is; the web client's licence and copyright notices are next to it in /usr/share/doc/tryton/. cloudimg changes no Tryton source file. It removes three directories that nothing on the image uses, listed in SOURCE.txt: the two sounds of sao's barcode-scanner dialog (no view on this image opens it, so the web client plays no sound), the icons of Werkzeug's interactive debugger (Tryton never starts it) and lxml's ISO Schematron support (nothing imports it).

Why 8.0 LTS. Tryton publishes a new series every six months and supports it for one year; a series ending in 0 is a long-term-support (LTS) series, maintained for at least five years. Tryton 8.0 is the current LTS series (8.0.0 was released on 20 April 2026, so it is maintained until at least April 2031). Tryton 8.2 is newer but is a one-year series. This image stays on 8.0 LTS, and the cloudimg listing adds a new version for each 8.0 patch release.

The Content Security Policy allows 'unsafe-eval' for scripts because the sao web client evaluates Tryton's domain expressions in the browser; it allows no inline script other than the one block of sao's own start page, by its hash, and no script, style, font or connection from any other site.

Ubuntu's unattended upgrades keep the operating system, PostgreSQL and nginx patched. Tryton does not update automatically. To keep your work across a move to a new instance, restore the database dump and the file store of Step 13.

Tryton is developed by the Tryton project and its community. cloudimg packages and configures it and is not affiliated with or endorsed by the Tryton project.

Support

cloudimg provides support for this image by email at support@cloudimg.co.uk, 24 hours a day, 7 days a week. Tell us the AMI ID and Region, and include the output of sudo tryton-cred-roundtrip and systemctl status tryton tryton-cron nginx postgresql@16-main tryton-egress-guard. For questions about Tryton itself, see the Tryton documentation and the Tryton discussion forum.