Ahmed S.

I run self-hosted Odoo in production, including one instance that bills around 4,300 consumers end to end. None of it is ever touched over SSH, including by me, because every change goes through a pipeline that rolls the database and the code back together when a deploy fails its own check. Running Odoo on your own servers and something needs to move, break less, or get upgraded? Send me your version, your module list and how you deploy today. I'll send back a short recorded review of what I'd fix first and what's already fine. Free, inside 48 hours, no obligation, and no pitch at the end of it. Most Odoo developers can build modules but can't run the infrastructure underneath them. Most DevOps engineers have never opened an Odoo manifest. The work I do sits in the middle, which is where self-hosted Odoo projects usually break. I'm CTO at ONPOINT XS, an Odoo Partner, and it's the same work there as here. WHAT I RUN IN PRODUCTION A corporate ERP on Odoo 19 Enterprise covering HR, payroll, finance, procurement, attendance and document management. Live since July 2026. Its document store sits on S3-compatible object storage. Production is operated entirely through GitHub Actions on a self-hosted runner. Nobody SSHes into that server, including me. A utility billing system on Odoo 18 Community for a housing authority, billing roughly 4,300 consumers end to end. Metering, tariff engine, formula-driven bill calculation, net metering with credit carry-forward, collections, QWeb bill templates, and a REST API feeding an Android field app for meter readings. Across both systems the issue register stands at 261 closed of 308. SELF-HOSTED AI, THE SAME DISCIPLINE More of this work now means running models on your own hardware instead of sending your data to somebody's API. GPU provisioning, Ollama and inference servers in Docker, retrieval plumbing, and the parts nobody plans for: VRAM headroom once requests arrive concurrently, a driver or CUDA version drifting out of step with the container, and what happens when the box reboots mid-inference. Same Linux, same Docker, same backups, same rollback discipline as the ERP work. To be clear about the boundary: I have fine-tuned an open-weight language model and adapted a speech model for domain audio on a production project, and I can do that again. What I don't do is model research or novel architectures. If you need somebody to invent the approach, that's a data scientist. If you need it fine-tuned, served and kept running on hardware you control, that's me. HOW I DEPLOY - Docker Compose, with staging and production kept properly separate - Every pull request gated on lint and the full Odoo test suite. It blocks the merge. - Images pinned by digest, so an upstream tag change can't quietly alter your build - Dependency-ordered module upgrades with a post-deploy assertion that checks the version actually moved. If it didn't, the pipeline rolls back the database and the code instead of reporting success. - Restic backups every six hours, restore-drilled, with the encryption key held by the customer WHAT I WORK ON - Odoo version upgrades with full data migration - Self-hosted deployment on AWS, Hetzner, or your own hardware - Migrating off Odoo.sh or Odoo Online onto infrastructure you control - Multi-tenant and multi-database setups - Odoo REST APIs and third-party integrations - CI/CD pipelines for Odoo - PostgreSQL and performance tuning - Self-hosted LLM and GPU infrastructure - Rescuing self-hosted instances nobody can safely upgrade any more HOW I WORK I start with your current version, module list, and what's actually customised, because that determines whether an upgrade is a weekend or a month. Most quotes get this wrong. Then you get a written plan with the risks named up front. I write documentation and runbooks so your team can operate the system after I'm gone. Based in Lahore, Pakistan (UTC+5). Overlap with EU mornings and US East Coast mornings.