Installation and deployment

A production deployment separates Tryton, PostgreSQL, web client, TLS proxy, persistent storage, and external backups.

Learning objectives

• Pin a compatible server and module series. When finished, verify the result with a test record and document ownership.
• Never embed passwords in the image. When finished, verify the result with a test record and document ownership.
• Use PostgreSQL and persistent volumes. When finished, verify the result with a test record and document ownership.
• Test restores, not only backup creation. When finished, verify the result with a test record and document ownership.
• Upgrade modules after a backup and in a controlled window. When finished, verify the result with a test record and document ownership.

Concepts to master

• Pin a compatible server and module series.
• Never embed passwords in the image.
• Use PostgreSQL and persistent volumes.
• Test restores, not only backup creation.
• Upgrade modules after a backup and in a controlled window.

Guided practice

1. Activity 1. Pin a compatible server and module series. Perform it in staging first, record preconditions, and compare expected and actual results.

2. Activity 2. Never embed passwords in the image. Perform it in staging first, record preconditions, and compare expected and actual results.

3. Activity 3. Use PostgreSQL and persistent volumes. Perform it in staging first, record preconditions, and compare expected and actual results.

4. Activity 4. Test restores, not only backup creation. Perform it in staging first, record preconditions, and compare expected and actual results.

5. Activity 5. Upgrade modules after a backup and in a controlled window. Perform it in staging first, record preconditions, and compare expected and actual results.

How to verify the result

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.

Common mistakes

• Confusing save with confirm, post, pay, or close.
• Testing only as administrator and assuming access rights work.
• Changing states or totals with SQL to bypass validation.
• Upgrading without inventory, restorable backup, and post-upgrade reconciliation.
• Documenting only the happy path while omitting cancellation, correction, and exceptions.

Developer perspective

Identify the models, fields, buttons, domains, and access rules involved. Before extending the process, locate the module that owns the rule, review its tests, and preserve invariants through super(). A correct customization must work across companies, languages, permissions, and states.

Production checklist

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.