Deploy and Host Odoo on Railway

Odoo is the open-source business suite — CRM, sales, invoicing, accounting, inventory, manufacturing, purchasing, projects, HR, e-commerce and a website builder, all sharing one database. This template runs Odoo 19.0 with Postgres, a volume for the filestore, an administrator password generated per deploy, and the database manager closed before the public URL is ever reachable.

About Hosting Odoo

Odoo has no environment-variable configuration layer. Every setting that decides whether a public deploy is safe lives in odoo.conf or on the command line, which is why a one-click Odoo needs more than a container image and a database:

The administrator account. A freshly initialised Odoo database has the login admin with the password admin, and no upstream option changes it. On a public URL, the first stranger who tries the documented default owns the ERP.
The database manager. admin_passwd defaults to admin and list_db defaults to True, so /web/database/manager will create, duplicate, restore, drop — and download a full backup of — the database to anyone who supplies that default. The backup ZIP contains dump.sql and the filestore, i.e. every record and every attachment.
The filestore needs a volume. Attachments, product images, uploaded documents and generated PDFs live on disk under /var/lib/odoo, not in Postgres.
Reverse-proxy awareness. Railway terminates TLS. Without proxy_mode and a fixed web.base.url, Odoo builds password-reset links, portal invitations and every emailed URL from whatever host the container saw.

This template settles all four. The master password comes from a generated secret and the database manager is disabled outright; the administrator password is generated per deploy and applied before anything binds a port; the filestore is on a volume, owned by the service user rather than by root; and proxy_mode is on with the base URL pinned to the Railway domain and frozen.

Sign in with the login admin and the generated ODOO_ADMIN_PASSWORD. The seed runs on every boot, so setting a new value and redeploying is also a supported password reset — and the master password is never accepted anywhere, because database management stays off.

Why Deploy Odoo on Railway?

Odoo needs exactly three things — a container, a PostgreSQL database and a persistent volume — and Railway supplies all three with TLS, a public domain and private networking already wired. There is no VPS to patch, no reverse proxy to write and no odoo.conf to hand-edit over SSH. Usage billing suits an ERP: it is a small always-on process between working hours and scales up for month-end.

Common Use Cases

Running a small business end to end: quotations, invoices, payments and accounting in one place
Inventory, purchasing and light manufacturing (MRP) against real stock levels
CRM and sales pipelines without per-user SaaS seats
A self-hosted back office for an existing storefront, extended through Odoo's addons

Dependencies for Odoo

A PostgreSQL database (included in this template)
A persistent volume for the Odoo filestore

Deployment Dependencies

Odoo: https://www.odoo.com
Source: https://github.com/odoo/odoo
Railway wrapper image: https://github.com/bon5co/odoo-railway

Implementation Details

Two services: Odoo on a volume mounted at /var/lib/odoo, and Postgres on a volume at /var/lib/postgresql. The image is pinned by digest, because Odoo major versions migrate one way. The stock entrypoint is bypassed deliberately: it reads $PORT as the Postgres port, and Railway injects PORT into every service. workers stays at Odoo's threaded default, because in prefork mode Odoo serves the websocket bus from a second port and Railway routes one port per service. The healthcheck is Odoo's own /web/health.