Every Odoo deployment eventually hits the attachment problem. By default ir.attachment writes binary payloads to the local filestore under the database data directory (or, worse, inline into the bytea column when the filestore is misconfigured), which means your PDFs, product images, QWeb report snapshots, chatter files, and email bodies all pile up on the same disk that runs the database. Backups balloon, pg_dump slows to a crawl, filestore sync between production and staging becomes fragile, and horizontal scaling is effectively blocked because every worker node needs a consistent copy of the same growing directory. Odoo core gives you no supported way to point that storage at durable, elastic object storage — it runs out of road exactly when your data volume starts to matter.

ECOSIRE builds a made-to-order module that overrides the storage layer of ir.attachment so that attachment binaries are written to and read from an S3 bucket instead of the local filestore. Technically, we extend models.Model on ir.attachment, intercepting _file_write, _file_read, _file_delete, and the store_fname/db_datas resolution path so the checksum-addressed key scheme Odoo already uses (XX/<sha1>) is preserved as an S3 object key under a configurable prefix. Credentials, bucket, region, endpoint URL, and prefix are held as ir.config_parameter values (or system parameters surfaced in Settings via an inherited res.config.settings view), never hard-coded — so the same build works against Amazon S3, MinIO, Wasabi, Backblaze B2, DigitalOcean Spaces, or any S3-compatible endpoint by changing the endpoint URL. We wire the boto3 client with connection reuse, optional server-side encryption (SSE-S3 or SSE-KMS), and configurable multipart thresholds so large report exports and video attachments upload reliably. A garbage-collection-safe delete path and an optional migration action (batched, resumable) move your existing filestore objects up to the bucket without downtime.

Because this is an override of a core storage path, it is built defensively: reads fall back to the local filestore for any object not yet migrated, failed uploads raise cleanly instead of silently dropping data, and access to attachments continues to obey Odoo's existing ir.model.access.csv grants and record rules — moving the bytes to S3 changes where they live, not who is allowed to read them. Presigned-URL delivery (time-limited GET links) is available for public website assets and large-file download flows so binaries stream from the bucket rather than through the Odoo workers. The module ships with its own __manifest__.py, a settings view, sensible defaults, and log instrumentation, and is compatible with the XML-RPC/JSON-RPC API paths that read and write attachments so external integrations keep working unchanged. Community and Enterprise editions are both supported; the delivery targets your exact Odoo series (17.0, 18.0, or 19.0).

Delivery is build-to-order. After a short scoping call we confirm your Odoo version and edition, your target bucket and region (or the S3-compatible endpoint you run), your encryption and access requirements, and whether you need existing attachments migrated. You approve a fixed quote and scope, we build against a staging copy of your database, run UAT with you, and then install on production with a rollback plan. Typical delivery is 2 to 4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); data migration volume, multi-company or multi-database setups, custom encryption/KMS policy, and presigned-URL website delivery increase the quoted scope.