Odoo Online vs Odoo.sh in Syria: Power Cuts, Remote Access and GitHub

For a company in Damascus or Aleppo, the hosting question starts with another one: is your bigger risk a power cut or an internet outage? And if the owner lives in Berlin or Dubai, can they still reach the books when the office is dark? Power cuts are still common, and many businesses rely on generators and solar.

Odoo is the same software on all three options: Odoo Online, where Odoo runs everything; Odoo.sh, Odoo's cloud platform for companies with their own code; and on-premise, a server you run yourself. Test each against three bad days:

• The office loses power for six hours. On Online or Odoo.sh the database keeps running, so the owner abroad and staff at home carry on. With an office server, everyone stops once the UPS and generator give out.
• The internet line drops. With an office server, local staff keep working while the power holds, but remote staff and the owner abroad are cut off. On a cloud host the office loses access instead, though an open Point of Sale session keeps selling, and during a brief outage Odoo 20's offline mode lets staff edit records they opened earlier and create new ones.
• The server disk fails. On Online and Odoo.sh the hardware is Odoo's responsibility, and production is backed up daily. On your own server, recovery comes only from the copy you kept off site.

A server rented abroad also counts as self-hosting under Odoo's licence: it avoids the office power problem, but its upkeep and backups are still yours.

Odoo has no official Syrian localization module, so on any host the chart of accounts and taxes are set up by hand. That works on Odoo Online: you import your own chart, configure taxes and currencies, and keep USD and SYP side by side. Odoo's documentation says Online databases can be used for long-term production, including customizations that do not require custom code.

Studio can cover requests like these without code:

• A field on the invoice for the USD/SYP rate agreed with the customer, printed on the PDF.
• An approval rule so that cash payments above a set amount wait for a manager.
• Automation rules and webhooks, for example an email to the owner abroad when a large order is confirmed.

Among the paid plans, Studio, multi-company and the external API come with Custom; Standard covers all apps, on Odoo Online only. Take a cross-border pair: a trading company registered abroad that supplies a Damascus distributor, run as two companies in one database with inter-company transactions. That needs the Custom plan, yet it still runs on Odoo Online.

What Online cannot run is code: no custom Python modules and no Odoo Apps Store modules. If a partner delivers Syrian accounting rules as a Python module, or you need a local SMS gateway Odoo does not offer, you need Odoo.sh or your own server. Before picking a plan, confirm how the subscription will be invoiced and paid: directly with Odoo, through a partner or through a company abroad.

Odoo.sh suits a Syrian company whose code is written by developers in Damascus while the owner signs off from abroad. A developer pushes a change to GitHub, Odoo.sh builds it, the owner tries it on a staging copy of the real data the same afternoon, and only then does it reach production. Every project is tied to a GitHub repository; the GitHub question below covers access from Syria.

The branches do the work:

• Production: one per project, backed up daily (7 daily, 4 weekly and 3 monthly copies).
• Staging: a neutralized copy of production. Outgoing email is captured by a mail catcher, scheduled actions are disabled, and payment and shipping connectors are put into test mode. Staging databases are deleted after a month.
• Development: fresh databases with demo data that run your unit tests and last about three days.

Production backups can also be downloaded from the project's Backups tab, so you can keep a copy of your own outside Odoo's platform. Each backup holds the database dump and the filestore, so on a slow connection the download takes time; plan it for a quiet period.

Odoo.sh does not replace the subscription. It needs a Custom-plan subscription that includes Odoo.sh, and hosting is billed separately by workers, storage and staging environments, with rates on odoo.sh/pricing. Know the limits too: no system packages, no long-running background processes, and port 25 closed to outgoing mail.

Odoo Online sets the calendar for you: a database on a SaaS version such as 19.4 must move a few weeks after the next release and one on a major version every two years, and Odoo upgrades it automatically at the due date if you have not. On Odoo.sh, each major version gets three years of standard support; a 25% surcharge applies once the version is three and a half years old, and the version is phased out on 31 October of the year it turns six. Odoo 16, released in October 2022, is already past the surcharge mark and leaves Odoo.sh on 31 October 2028.

On your own server nothing forces a move, but standard support still ends three years after release. Odoo 17's ended in September 2026, so a self-hosted database on 17.0 or older now needs paid extended support for fixes. When you do upgrade, plan for Syrian conditions:

• The upgrade goes through Odoo's upgrade platform: you upload a copy of the database without the filestore and download the upgraded one, so allow for the transfer both ways.
• Pick a window with stable power and connection, and keep users out of production while it runs, because changes made after the upload are not carried over.
• Test the upgraded copy first, with the owner abroad checking key reports remotely.
• If a partner delivered your Syrian accounting rules as a custom module, it must be ported to each new version first; Odoo's upgrade service covers that only under a maintenance-of-customizations subscription.

Odoo's deployment guide sizes a server by concurrent users: about six per worker, with at most (CPU cores × 2) + 1 workers. For a Damascus office with ten concurrent users, that gives two workers plus one for scheduled jobs and, by its memory formula, roughly 1 GB of RAM for Odoo before PostgreSQL and the operating system: well within a modest two-core machine. Odoo 20 from source needs Python 3.12 or later and PostgreSQL 16 or later, and the server must reach services.odoo.com for the weekly subscription check.

Continuity matters more than size:

• Size the UPS to last until the generator or solar takes over, and set it to shut down Odoo and PostgreSQL cleanly before the battery runs out.
• Copy the database and filestore off site every night, to another city or abroad, and test a restore regularly.

Then answer honestly:

• Will anyone write custom Python, such as a Syrian accounting module? Then Odoo.sh or on-premise.
• Can your team test an upgrade every few months, or every two years on a major version?
• Who needs access from abroad, and what happens in a power cut?
• Does anyone on the team manage GitHub, servers and backups?
• Do you need several companies in one database, Studio or the API? Then budget for the Custom plan.

METCH, an official Odoo partner with a team in Damascus, offers a free consultation on your power backup, off-site copies, remote access from abroad and subscription payment, ending in a hosting recommendation. Book it before you sign anything.