Odoo 19 documentation describes a cloud storage integration that sends chatter and email attachments to Google Cloud Storage or Microsoft Azure instead of the database server. For a Belgian or French company with a fast-growing filestore, this can reduce file traffic through the Odoo server and distribute capacity more effectively.
The scope is deliberately narrow. Odoo-generated files such as quotations, and files managed by the Documents and Sign apps, remain on the database server. This option therefore moves neither the whole filestore nor the complete document-management estate: it creates a hybrid architecture that must be operated accordingly.
What standard Odoo 19 actually does
The administrator installs the provider module, selects Google Cloud Storage or Azure, and defines a minimum file size. New eligible attachments above that threshold are then directed to external storage.
For Google, Odoo uses a service account, bucket and JSON key. For Azure, configuration uses an application, tenant, client secret, storage account and container. The documentation also specifies CORS rules for browser read and write operations.
This should be understood as a placement rule for new files, not as an automatic migration tool for historical attachments. Before enabling it, the project team should inventory existing volumes and decide separately whether a migration workstream is required.
Document the functional boundary
Users should not need to know where each file resides, but IT, support and compliance owners do. At minimum, map chatter attachments, inbound and outbound email, generated PDFs, Documents, Sign, exports, and custom developments that manipulate attachments directly.
This boundary also matters for backup and recovery. Restoring only the database and its filestore is no longer enough when some objects are held by an external provider. The recovery plan must coordinate restore points, preserve the metadata linking Odoo to objects, and test access after recovery.
Security: reduce privileges before opening the flow
For Azure, Odoo recommends a custom role without deletion permission so that compromised storage credentials cannot erase objects. The same principle should guide both providers: the technical identity should receive only the required actions on the intended bucket or container, not a wider cloud estate.
Keys and secrets need an owner, expiry date, rotation procedure, and separation between test and production. The Azure instructions recommend a client-secret lifetime of 180 days or less and remind administrators to update Odoo before expiry. Without an operating calendar, the first reminder may be a failed download.
Belgium and France: location, contracts and data
External storage does not automatically change Odoo access rights: an attachment remains exposed through the rules governing its record and business flow. Teams must nevertheless review the selected region, subprocessors, contractual commitments, retention, encryption, and the process for handling personal-data requests.
For a group operating in Belgium and France, one policy can define document classes while each entity specifies its retention constraints and accountability. The technical integration is not, by itself, a legal archive or records-management system.
Underside analysis: decide by risk, not volume alone
We recommend not starting with an arbitrary megabyte threshold. First classify uses: large low-sensitivity files, routine commercial exchanges, contracts, HR data, accounting records and signature evidence. Volume drives cost and performance; document class drives access, retention and evidential requirements.
A useful pilot enables external storage on a non-production copy and rehearses upload, preview, download, email, deletion, recovery and secret expiry. It should also test custom modules and connectors that assume a binary is stored locally. An Odoo migration must include these checks because custom code may bypass standard abstractions.
Rollout roadmap
- Measure filestore growth and identify the dominant attachment types.
- Map what can move externally and what will remain in Odoo.
- Select the provider region, retention policy and cost model.
- Create a dedicated technical identity with least privilege.
- Separate buckets or containers and secrets between test and production.
- Set the threshold from measurements, then test critical business journeys.
- Design and test coordinated recovery of Odoo and external storage.
- Monitor errors, capacity, cost, secret expiry and denied access.
This work complements document governance in Odoo, security and access rights, and Odoo migration planning. Depending on the requirements, standard functionality may be sufficient for attachment placement; historical migration, archival policy or advanced controls require a complementary project.
Official source
Underside helps companies architect, migrate and secure Odoo. For cloud storage, the goal is to validate scope, recovery and operations before production activation.