Run Odoo on your own servers, without giving up a control plane

The gap between hosting and operations

Owning a server is straightforward. Operating Odoo on it over time is the harder part. A production setup needs more than a virtual machine and a successful first install: configuration has to remain understandable, database and filestore backups have to stay together, custom modules need a controlled path to each environment, and routine actions need an audit trail.

The usual alternatives sit at opposite ends. A fully managed platform gives you a workflow but chooses the infrastructure boundary for you. A collection of SSH notes gives you infrastructure ownership but leaves every team member to reconstruct the workflow.

Tnion.SH is built for the space between those two models. You bring the Linux hosts. The control plane gives projects, environments, deploy actions, backups, configuration, logs, and server context a consistent place to live.

What BYOS means in Tnion.SH

BYOS means “bring your own server.” In practical terms, a workspace registers a Linux host with its address, SSH user, port, and encrypted credential. A connection test confirms that the host is reachable and reports basic system information before it is assigned to an Odoo instance.

When an instance is provisioned, Tnion.SH writes its deployment files on that server and runs the Docker Compose workflow there. The generated topology keeps Odoo and PostgreSQL together for that instance, prepares an addons directory, and configures the host-level Nginx route. The resulting containers, configuration, database volume, filestore, and backup directory all remain on infrastructure you control.

This boundary matters when an agency already has an infrastructure provider, a required region, or a server policy that cannot be replaced by a bundled hosting vendor. It also makes the control plane’s responsibility easier to explain: coordinate repeatable operations without claiming ownership of the underlying host.

A repeatable operating model

A Tnion.SH project represents one Odoo codebase and its environment strategy. Production, Staging, and Development instances can be placed on appropriate registered servers. Each stage has an explicit branch mapping for custom modules, so a module deploy resolves the branch from the environment rather than from whoever happens to be running the command.

The same model carries through routine work:

• Server connection details and verification status live at workspace level.
• Instance actions operate against a known project, stage, and host.
• Git deploys record the branch and checked-out commit.
• Odoo, PostgreSQL, and Nginx settings use bounded, validated options.
• Backups include the Odoo database and filestore in one restorable archive.
• Workspace activity records the actor and resource for sensitive changes.

This does not remove the need for infrastructure judgment. It removes avoidable variation in how the judgment is applied.

Where the boundary stays clear

The control plane cannot make an undersized server fast, choose a compliant region for you, or replace your operating-system security policy. You still decide who owns the provider account, how the host is patched, which network paths are open, and how off-host copies fit your recovery plan.

What Tnion.SH can do is keep the Odoo-specific operating workflow coherent. The team sees the same environment names, deployment source, current server, configuration surface, backup history, and action log. That shared context is the difference between “we host it ourselves” and “we operate it deliberately.”