Odoo Online vs Odoo.sh in Jordan: JoFotara, Upgrades and Who Does What

Picture two companies. A 12-user import company in Amman has no IT staff. A QIZ garment exporter near Irbid has an in-house developer and production logic that no standard app covers. Both can use the same Odoo apps and the same Jordanian localization on any of three hosts: Odoo Online, Odoo's own SaaS; Odoo.sh, Odoo's platform for databases with custom code; or on-premise, Odoo Enterprise on a server you choose. What changes is who does the work:

• Security patches: Odoo applies them on Online and Odoo.sh. On-premise, your team does, using the advisories Odoo sends at least two weeks before they go public.
• Backups: Odoo takes them daily on Online and Odoo.sh, where your team can also restore production from the Backups tab. On-premise, you set them up, keep copies off the server and test restores.
• Custom modules: not possible on Online. On Odoo.sh and on-premise, your developer or partner writes and maintains them.
• Major upgrades: Odoo sets the deadlines on Online and Odoo.sh; you test, and on Odoo.sh you also port custom code. On-premise, you plan and run them.
• JoFotara credentials: yours on every option, generated through the national e-invoicing system.

The importer wants as little of this list as possible; the exporter already has someone to own part of it. Start from who will do this work, not from the feature list.

Compliance rarely decides hosting in Jordan. The Jordanian localization (l10n_jo) sets up the chart of accounts, the 16% general sales tax, exempt and 0% export taxes and the tax report, and the JoFotara connector (l10n_jo_edi) sends invoices for validation using API credentials you generate through JoFotara. Both are standard modules, so they run on Odoo Online, even on the Standard plan.

The plan matters more than the host. The Standard plan includes all apps but runs only on Odoo Online. The Custom plan adds Odoo Studio and agentic AI, multi-company and the external API, and runs on Online, Odoo.sh or on-premise. Prices depend on your country and plan, so check Odoo's pricing page.

Three Jordanian cases show where the lines fall:

• A Studio field on export invoices for the certificate-of-origin number: Custom plan, still on Odoo Online. Installing Studio on a Standard database automatically triggers an upsell to the Custom plan.
• An Amman company and a sister company in the Aqaba Special Economic Zone, which has its own tax rules, in one database: enabling multi-company also triggers the upsell to Custom, and it still works on Odoo Online. Confirm the zone's current rates before you set up its taxes.
• A Python module written for you, such as costing logic that changes how Odoo values cut-make-trim orders on a QIZ line, or an Apps Store module your process depends on: this takes you off Odoo Online. Piece-rate pay on its own can often be set up with Payroll salary rules, without a module.

Odoo.sh suits the Irbid exporter: it can run the costing module without anyone at the factory running servers. It needs an Enterprise subscription that includes Odoo.sh, which means the Custom plan, and hosting is billed on top: the Odoo.sh pricing page states that the hosting price does not include the Enterprise licence. Hosting is priced by workers, storage and staging environments, and current figures are on that page.

The developer keeps the module in a GitHub repository linked to the project. Each push to a development branch is built and tested on a fresh database, a staging branch runs on a neutralized copy of production, and only code merged into the production branch reaches the live database. Neutralization also replaces the JoFotara Client ID and Secret Key with dummy values, so a staging copy cannot submit invoices to ISTD unless someone re-enters the real credentials. Don't: every invoice sent from that copy would then be a real submission.

Budget for the module beyond its first version. Before each major upgrade it must be ported to the new version, because a database with custom modules cannot be upgraded until they are. Odoo's upgrade service covers standard apps, and Studio customizations while Studio stays installed, but not third-party modules, including those from Odoo partners, unless a maintenance contract covers them. The exporter's real cost is the hosting bill plus the developer time to keep that module current.

Every major version gets three years of standard support. On Odoo Online the clock is short and fixed: a major version must be upgraded every two years, a SaaS version a few weeks after the next one ships, and Odoo upgrades overdue databases itself. On Odoo.sh and on-premise, the version you run decides how long you have:

• 20.0 (released September 2026): standard support planned until September 2029. The version to start on today.
• 19.0 (September 2025): support planned until September 2028. Odoo.sh removes it on 31 October 2031.
• 18.0 (October 2024): support planned until September 2027. Odoo.sh removes it on 31 October 2030.
• 17.0 (November 2023): standard support ended in September 2026. Odoo.sh still runs it, but once a version is three and a half years old (around May 2027 for 17.0) a 25% surcharge is added to the subscription, and on 31 October 2029 the version is phased out and databases still on it are permanently blocked. On-premise you may stay on it, but fixes now come only with paid extended support.

So a company that went live on 17.0 in 2024 is already outside standard support. It does not have to step through every version: Odoo upgrades from any version to any major version still under standard support, so 20.0 is a direct target. Plan that move before the surcharge starts, and before the module work described above piles up across several versions.

Sizing matters only on Odoo.sh or your own server. Odoo's on-premise rule of thumb counts concurrent users: one worker serves about six, the ceiling is (CPUs x 2) + 1 workers, and RAM per worker assumes 80% light requests at about 150 MB and 20% heavy ones at about 1 GB. With about 20 people logged in at shift change, the Irbid factory needs 4 workers plus 1 for scheduled jobs. That fits a 2-CPU server ((2 x 2) + 1 = 5) with about 1.6 GB of RAM for Odoo. On Odoo.sh, use it as a first estimate and adjust to real use.

Then find your case:

• Amman importer, no IT staff, standard apps and JoFotara: Odoo Online, Standard plan.
• The same importer adding an Aqaba company or a Studio field: Odoo Online, Custom plan.
• Irbid exporter with a developer and a costing module: Odoo.sh, Custom plan.
• Amman NGO holding beneficiary data: legal review first; on-premise in Jordan is the only way to keep every copy in-country.
• No appetite for a major upgrade every two years: Odoo.sh or on-premise, budgeting for the extra fees on older versions described above.
• Starting on Odoo Online but expecting custom code: create the database through odoo.com/start-lts so it stays on a major version.

METCH is a certified Odoo partner serving Jordan. We can map your users, branches and integrations to the right hosting and plan, and we quote our services in Jordanian dinars. Book a free consultation to work through this checklist with us.