Hosting and maintenance / Nimex Solutions
A reliable operating environment for the ERP your business depends on.
Odoo runs on an application server, a PostgreSQL database, a filestore and a set of background workers, behind a TLS proxy, next to the services it talks to. We design and run that environment on Odoo.sh, on cloud or VPS servers, or on your own hardware, with production, staging and development kept apart, backups that are restore-tested, and monitoring that explains its alerts.
- How we work
- Standard Odoo
- Third-party platform
- Defined per contract
Infrastructure architecture
What an Odoo environment is made of, in plain words and in detail.
Every component below exists in every deployment model; what changes is who operates it. The short description is for the people who sign the contract; the detail is for the people who will be called when something fails.
Application serversWhere Odoo's code runs and answers your users.
Odoo's multi-processing server runs HTTP workers for web requests, cron workers for scheduled jobs and a dedicated live-chat (websocket) worker. The number of workers follows the server's CPUs and the expected number of simultaneous users (Odoo's rule of thumb: (#CPU × 2) + 1; about six concurrent users per worker); memory limits per worker restart runaway requests before they affect everyone.
Standard Odoo Sized per project
PostgreSQLThe database that holds every record.
One PostgreSQL cluster per environment, with connection limits sized for the workers, regular vacuum and index maintenance, and a dump taken nightly together with the filestore. On a managed cloud or on-premise setup we tune memory, checkpoints and slow-query logging; on Odoo.sh the platform operates it.
Standard Odoo
Workers and background jobsScheduled actions and long jobs that run while users keep working.
Scheduled actions (bank synchronisation, e-invoice sending, MRP scheduler, report mailings) run on cron workers, not on the workers serving users. Long batches are split into jobs so that a 1,240-document e-invoice run never blocks a warehouse scan. Queue depth and job duration are monitored.
Standard Odoo How we work
Reverse proxy, DNS and TLSThe front door: your domain, HTTPS, and nothing else exposed.
A reverse proxy terminates TLS, redirects plain HTTP, forwards websocket traffic to the live-chat worker and passes the real client address to Odoo (proxy_mode). Database manager screens are blocked from the internet; failed logins are rate-limited. Certificates renew automatically.
How we work
Storage and attachmentsDocuments, PDFs and images live outside the database.
Attachments are kept in Odoo's filestore on disk, served through Odoo's access-rights checks (optionally with X-Sendfile for speed). The filestore is part of every backup; disk growth is tracked so that it never fills unexpectedly.
Standard Odoo
BackupsDatabase dump plus filestore, kept off the server, tested by restoring.
A backup is a database dump and the filestore together, copied to a location the production server cannot delete. Odoo.sh keeps seven daily, four weekly and three monthly production backups (dump, filestore, logs and sessions); on cloud and on-premise we set a comparable schedule per contract. Every backup plan includes periodic restore tests on staging.
Odoo.sh: Odoo S.A. Schedule per contract
MonitoringAvailability, queues, response times, disk, errors, with alerts that explain themselves.
External availability checks, host metrics (CPU, memory, disk), PostgreSQL connections, job queue depth, p95 response time and application error counts. Alert thresholds are agreed with you and reviewed when they fire; an alert is always linked to the event that caused it.
How we work
IntegrationsThe e-invoice provider, banks, carriers and other systems Odoo talks to.
Outbound connections (e-invoice provider, bank APIs, cargo carriers, payment providers) are allowed explicitly; credentials live in Odoo's configuration, not in code; failures are logged on the record and raised in monitoring when they repeat.
How we work
Deployment models
Odoo.sh, managed cloud or VPS, or on-premise.
Odoo.sh is Odoo S.A.'s platform: we deploy and operate your Odoo on it, we do not own the infrastructure. On a cloud or VPS server we administer the whole stack for you. On-premise, the servers are yours and we agree who does what. The table says what each model gives and what it asks of you.
What we do not claim. No availability percentages and no accreditations are stated here: those belong to the platform or data-centre operator's own terms, and to your contract.
| Odoo.sh Odoo S.A. platform | Managed cloud or VPS Operated by Nimex | On-premise Shared responsibility | |
|---|---|---|---|
| Who operates the infrastructure | Odoo S.A. runs the platform: servers, PostgreSQL, backups, platform updates, the GitHub-connected build pipeline. | A cloud or hosting provider supplies the servers; Nimex installs and administers Odoo, PostgreSQL, proxy, backups and monitoring. | Your IT owns the hardware, network and operating system; Nimex administers the Odoo stack, or trains your team to. |
| What Nimex does | Project setup, branches (production, staging, development), module deployment, tests, upgrades, monitoring of the application, support. | Everything above plus server configuration, patching, backup scheduling and restore tests, capacity and performance tuning. | Architecture, installation, environment management, maintenance routines; responsibilities split in writing. |
| Advantages | Staging builds from production data, backups and platform operations included, Enterprise-oriented; fast to start. | Full control of the stack: any Python dependency, any integration, Community or Enterprise, sizing you choose. | Data stays on your premises; integration with local systems (PLCs, printers, file shares) is direct. |
| Constraints | Enterprise subscription required; platform limits on system packages and resources; dependencies via the platform's rules; staging databases are deleted after a month. | Operations are our responsibility, so maintenance windows and monitoring are part of the contract, not optional. | Hardware, redundancy, internet access and physical security are yours; backup copies must leave the building. |
| Typical use | Enterprise customers who want the platform's workflow and no server administration on their side. | Companies with custom modules and integrations, Community edition, or specific sizing and data-residency needs. | Manufacturers with on-site systems, organisations with strict internal hosting rules. |
| Environments | Production, staging and development branches on the platform. | Production, staging and development on separate servers or containers, as sized. | The same separation, on your servers or virtual machines. |
Environment management
Nothing reaches production that was not tested on a copy of it.
Source code lives in version control; configuration changes are written as data files where possible, so what was tested is what gets deployed. Deployments to production happen in agreed windows and are approved by a named person on your side.
- DevelopmentA fresh database per feature branch, demo data, automated tests; nothing from production.How we work
- StagingA neutralised copy of production: mails intercepted, scheduled actions off; users rehearse and tests run on real data.How we work
- ApprovalThe release note lists what changes; your project lead approves the window.Per contract
- ProductionDeployed in the window, workers restarted, checks watched; the previous build and a fresh backup remain available.How we work
Version-controlled source
Custom modules, configuration data and deployment scripts live in Git; every production build maps to a commit. Studio changes are exported and versioned where they matter.
Backup and restore in the loop
Staging is rebuilt from the latest production backup. That rebuild is also the restore test: if the backup does not restore, we know before we need it.
Testing environments on demand
A separate test database for an upgrade, a data migration rehearsal or a training session, discarded afterwards.
Maintenance
Software maintenance, infrastructure administration, external hosting: three jobs, named separately.
Software maintenance keeps Odoo and the custom modules healthy; infrastructure administration keeps the servers healthy; external hosting is what the platform or data-centre operator provides. Your contract says which of the three we hold.
- Backups and restore testsNightly dump plus filestore copied off the server; restore rehearsed on staging on a schedule.Software and infrastructure
- Dependency updatesPython packages, wkhtmltopdf, Node tooling for custom modules, kept at tested versions.Software maintenance
- Security patchingOperating system and PostgreSQL patches in maintenance windows; Odoo security advisories applied as released.Who patches: per contract
- LogsApplication, proxy and database logs rotated and retained; reviewed after deployments and on incidents.How we work
- MonitoringChecks and thresholds reviewed when they fire; new checks added after every incident that had none.How we work
- Database healthVacuum and bloat, index usage, slow queries, table growth, connection usage.How we work
- PerformanceSlow reports and views measured in logs and tuned; worker and memory settings revisited as users grow.How we work
- RecoveryDocumented restore procedure per environment, rehearsed; who is called, in which order, with which backup.How we work
- CapacityDisk, memory and CPU trends reviewed monthly, with a sizing recommendation before limits are reached.How we work
Monitoring
An alert is only useful when you can see what caused it.
A scheduled e-invoice batch of 1,240 documents fills the job queue; response times rise; the queue alert fires. An engineer acknowledges it, starts an extra job worker, the queue drains, the alert resolves, and the batch is moved to an off-hours window. No availability percentage is shown, because a status with a cause is more honest than a number without one.
- ChecksAvailability, worker queue, background jobs, p95 response time, database connections, disk, backups, errors.How we work
- ThresholdsAgreed with you and written down; a threshold that fires without a cause is reviewed, not silenced.Per contract
- Who is notifiedThe on-duty engineer per the contract's coverage; the ticket is opened automatically.Per contract
- What followsCause, action, resolution and the preventive change are recorded on the same event.How we work
Disaster recovery
A backup is only real once it has been restored.
Recovery planning is written per environment: which backup, restored where, by whom, in which order, and how users are told. Recovery time and data-loss objectives are figures we agree and document with you for your infrastructure; we do not publish generic ones.
Backup verification
Every nightly backup is checked for completeness (dump and filestore) and copied to a location the production server cannot write to.
Restore testing
Scheduled restores on staging prove the backup and time the procedure; the measured duration is what goes into your plan.
Recovery planning
A written runbook per environment: contacts, order of operations, DNS and certificate steps, integration re-activation, user communication.
What this page does not claim
- No availability percentage: such figures are terms of the platform or data-centre operator and of your contract.
- No recovery time or recovery point figures until they are measured on your environment and written into your contract.
- No accreditations: we do not hold or imply data-centre or security accreditations; the operator's own apply.
- Odoo.sh is Odoo S.A.'s platform; we deploy and operate on it, we do not own or run it.