Tnion.SH
Get Started

Connect a VPS and prepare it for an Odoo environment

What Tnion.SH checks over SSH, what stays on your host, and how to prepare a Linux server before the first provision.

Tnion.SH Team6 min read

Before you connect

Start with a Linux VPS you control and an account that can perform the installation work required by the environment. Tnion.SH currently connects with an SSH username and password. The address can be an IP or a valid hostname, and the SSH port is recorded separately.

Before adding the host, confirm the same credentials outside the control plane:

Code
ssh -p 22 deploy@203.0.113.10
uname -snrm

The first command should reach the expected server. The second gives you a simple identity check after login. If a firewall limits SSH, allow the network path used by the Tnion.SH API before continuing.

Add and verify the server

In the workspace, add the server name, host or IP, SSH user, port, and password. The password is encrypted before it is stored. Public server responses do not return it.

Run the connection test before assigning an instance. The test opens a read-only probe, checks the login, reads the hostname and operating-system summary, and surfaces the SSH host-key fingerprint returned by the server. Tnion.SH records the successful verification time and summary so the workspace can distinguish a configured host from one that has actually been reached.

Compare the reported hostname and fingerprint with values obtained through a trusted path. A successful password login proves that the credential worked; your infrastructure process should still confirm that the destination is the host you intended to register.

What provisioning does

After a server is linked to an instance, provisioning performs the mutating work over a dedicated SSH session. The current provisioner checks for Docker Compose and can install Docker when it is missing. It writes the instance’s Compose and Odoo configuration, brings up PostgreSQL, initializes the Odoo database, starts the application, and configures an Nginx site for the assigned hostname.

You can check the host before that first run:

Code
df -h /
free -h
command -v docker && docker compose version
command -v nginx && nginx -v

Existing Docker or Nginx installations are detected rather than blindly duplicated. Tnion.SH also tests an updated Nginx configuration before reloading it, which keeps a malformed site change from becoming an uncontrolled reload.

A small preflight checklist

Use this short review for every new VPS:

  1. Confirm the provider, region, server size, and ownership outside Tnion.SH.
  2. Patch the operating system and configure the host firewall.
  3. Create the deployment account and verify its intended privileges.
  4. Confirm DNS for the environment hostname points to the VPS.
  5. Test SSH yourself, then run the Tnion.SH connection test.
  6. Review the reported hostname, system summary, and fingerprint.
  7. Assign only the intended environment, then provision and watch its deployment log.

Connection is a boundary check, not a substitute for host administration. Keeping that distinction explicit makes later troubleshooting much faster.