Putting Odoo on your own domain looks like a five-minute DNS job, and the DNS part usually is. The trouble shows up weeks later: a customer clicks "View online" on an invoice and lands on an address that no longer works, or the browser shows a certificate warning on a busy morning. Those failures come from the layers around the DNS record, and they are worth planning before you switch.
Three layers, not one
A custom domain for Odoo has three parts that fail independently:
- DNS, which points the name at the server.
- The TLS certificate, which lets browsers trust the connection.
- Odoo's base URL, the address Odoo believes it lives at and uses to build every link it sends out.
The first two fail loudly. The third fails quietly, which is why it causes most of the damage.
The DNS record: subdomain or root domain
For an internal ERP, a subdomain such as erp.yourcompany.com is almost always the right choice. You point it at your host with a CNAME record, and if the host later moves your instance to a different server, the record keeps working without you touching it.
The root domain (yourcompany.com) is different. DNS rules do not allow a CNAME at the root, so you need either an A record pointing at a fixed IP address, which breaks if that address changes, or a DNS provider that supports ALIAS records or CNAME flattening. If the Odoo Website app is your public site, pick one canonical form, with or without www, and redirect the other to it permanently.
One habit saves a lot of stress: lower the record's TTL a day before the switch. If something is wrong, you can point the name back in minutes instead of waiting hours for caches to expire.
The certificate: renewal is what fails
A certificate covers specific hostnames. One issued for erp.yourcompany.com does not cover www.yourcompany.com, so every name you add has to be included. Certificates today are short-lived, and most hosted setups renew them automatically. That is good, but it means the risky moment is not the first issue. It is the renewal that fails silently because a DNS record changed, a CAA record does not allow the certificate authority, or a redirect blocks the validation request.
Ask your host three things: who renews the certificate, who gets alerted when a renewal fails, and what happens when you add a second hostname.
The base URL: Odoo's own address
Odoo builds outgoing links from a system parameter called web.base.url. Portal links in quotations and invoices, password reset emails, user invitations, online payment links, and the return addresses many payment integrations rely on all come from it.
Here is the catch most teams learn the hard way. When a user with administrator (Settings) rights logs in, Odoo updates web.base.url to whatever address they used. An administrator who logs in once through a temporary address, a raw IP, or an old domain can quietly rewrite the links in every email that follows. Nothing errors. Customers simply receive working emails full of links they cannot open.
The fix takes two minutes. Once the final domain is live, set web.base.url to the full https address, then add a system parameter named web.base.url.freeze with the value True. From then on, changing the address is a deliberate act rather than a side effect of logging in.
If you use the Website app, each website record also has its own domain field. Fill it with the full https address. On a multi-website setup, that field decides which site a visitor sees.
Behind the proxy: https all the way through
Hosted Odoo normally sits behind a reverse proxy that handles the certificate. Odoo has to be told it is behind one, through its proxy mode setting, or it can build http links and redirects even though visitors arrived over https. The symptoms are mixed-content warnings, login loops, and pages that bounce between addresses. Website pages with hard-coded http image links cause the same warnings. On managed hosting, the proxy configuration belongs to the host. When you run Odoo yourself, it belongs to you.
Changing the domain later
Renames happen: a rebrand, a merger, or a move from a host's default address to your own. A short checklist covers most of the risk:
- Keep the old domain redirecting to the new one for months, not days. Emails already sent still carry the old links.
- Update web.base.url and the website domain, then freeze the base URL again.
- Update every integration that stores a redirect or callback address: Google or Microsoft sign-in, payment provider webhooks, shipping and messaging connectors.
- Warn users that they will be logged out. Their sessions belong to the old domain.
- Remember that the domain used for incoming email aliases is configured separately. Changing the web address does not change where replies land.
Rehearse the change on a staging copy first. Log in, send a test quotation to yourself, and click every link in it. That ten-minute test catches what a checklist misses.
What your host owns, and what you own
The split is worth stating plainly. DNS guidance, certificate issuance and renewal, and proxy configuration are infrastructure, and a managed host should own them. The base URL, the website domain, and the redirect addresses registered with your integrations live inside your database and your third-party accounts, so they stay part of your configuration whoever hosts you. When you evaluate any Odoo host, ask exactly which side of that line each item sits on.
If you would rather hand the in-database part to a team that handles it routinely, our managed support and SLA service is the place to start. If you want hosting where staging environments, monitoring, automated backups, and point-in-time recovery are part of the base setup, Plemo provides managed Odoo hosting built for that.