Should you self-host Dolibarr or run it on DoliCloud?
Choose DoliCloud when you want a managed SaaS with published plans and do not need to control where the data lives or when upgrades land. DoliCloud, which describes itself as the official Dolibarr preferred partner, hosts Dolibarr for you, and its Basic plan is listed at 14 euros per user per month with a Premium plan from 45 euros per month, each with a 30-day free trial, according to the DoliCloud website. That model suits a small or mid-sized team with a modest module footprint, no in-house PHP and database operations, and no requirement to install custom code that the hosted service may not accept. Both options run the same GPL-3.0 codebase, so the difference is who operates the stack, not which product you get.
Choose self-hosting when location, add-ons and upgrade timing are decisions you need to own. Dolibarr runs on MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer, on any PHP-capable web server, and it can run on premises, on dedicated machines, with Docker, or through a cloud provider, according to the Dolibarr prerequisites page and website. Self-hosting also lets you decide which DoliStore add-ons and Module Builder extensions to install and when to move to a new major line, such as 24.0.0, released on August 20, 2026. Before you commit, confirm with the DoliCloud team which DoliStore modules and custom code they support, which backup and restore options they offer, and where data is stored. Then cost the work you would take on: patching PHP and the database, testing upgrades, and running backups, which recur for as long as you operate the stack.
How DoliCloud and self-hosted Dolibarr compare on the factors that matter
This table compares DoliCloud's hosted Dolibarr with running Dolibarr yourself across licensing, databases, modules, extensions, upgrades, backups, published pricing and staff time. Read each row against your team size and your own control requirements, because the cost of self-hosting depends on your infrastructure and labor rather than on a vendor fee.
| Factor | DoliCloud (hosted SaaS) | Self-hosted Dolibarr |
|---|---|---|
| License | Dolibarr core is GPL-3.0, and the hosted service is sold as a subscription on top of it | GPL-3.0 with no license fee from the Dolibarr Association; you carry the hosting and operating costs |
| Supported databases | Provider-managed; confirm the database engine and version with DoliCloud before signing | MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer, per the Dolibarr prerequisites page |
| Module availability | Modules offered by the hosted plan; confirm which modules and add-ons are included in each plan | Enable only the modules you need, including CRM, invoicing, stock, MRP, point of sale and projects |
| DoliStore and Module Builder | Confirm whether DoliStore add-ons and the Module Builder can be installed on your plan | Install DoliStore add-ons and build custom modules with the Module Builder, but test each one yourself |
| Upgrade control | The provider schedules upgrades; ask about notice, timing and whether you can defer a release | You choose when to move between lines such as 23.0 and 24.0.1, and you own the regression testing |
| Backups and restore | Ask for backup frequency, retention, restore testing and whether you can export a full copy of your data | You design, schedule and test backups of the database and uploaded documents |
| Published pricing | Basic plan at 14 euros per user per month; Premium from 45 euros per month; 30-day free trial, per the DoliCloud website | No vendor fee is published; costs come from servers, storage, backups, licenses for your own tooling and staff time |
| Staff time to operate | Lower internal effort for patching, hosting and backups, but you still manage users, configuration and data quality | Ongoing effort for PHP and database maintenance, security patches, upgrades, monitoring and recovery testing |
| Control and data location | Data sits with the provider; confirm hosting region, sub-processors and exit terms in writing | Data stays in your own cloud account, data center or private network under your own controls |
Where your data lives and who controls access
Hosting model decides where Dolibarr data sits, who can reach the servers and who holds the backups. Each card below covers one of those decisions, and the same questions apply whether you choose DoliCloud or run Dolibarr yourself.
Data location and residency
DoliCloud is a vendor-hosted SaaS, so your Dolibarr database and uploaded documents sit in the provider's facilities. Self-hosting keeps them in your cloud account, data center or air-gapped network. Ask DoliCloud which data center regions it uses, whether a specific region can be contracted, and whether backups stay in the same region. Confirm these with the vendor in writing rather than assuming them from the hosting label.
Administrative access to the platform
On SaaS, the vendor's operators manage the underlying servers, while your administrators manage Dolibarr users and modules. Self-hosting gives your own team root access to the PHP, web server and database layers. Write down who can open a shell on the database host, who holds the database credentials and how those credentials are rotated. Ask DoliCloud for its staff access policy, including how vendor engineers reach customer data for support.
Backup custody and restore rights
Backups are where many data exposures start. Under DoliCloud, the vendor schedules and holds backups, so you need to confirm retention, encryption, restore process and whether you can take a full export yourself. When you self-host, you own the database dump, the document directory and the restore test. Dolibarr needs both the MySQL, MariaDB or PostgreSQL data and the uploaded files to be restorable together, so test a full restore on a separate machine.
Audit logs and evidence
Compliance assessors ask for evidence of who changed what and when. Confirm with DoliCloud which access logs, change logs and administrator activity records it keeps, how long they are retained and whether you can export them. On a self-hosted install, your team must enable and forward Dolibarr event logs, web server logs and database logs to storage that your administrators cannot quietly alter.
Certifications and contract terms
Hosting location does not make a platform compliant. Compliance outcomes depend on the controls you run and on what an independent auditor or certification body verifies. Ask DoliCloud for its current certifications, audit reports and data processing terms, and confirm they cover the service you will buy. Self-hosting shifts that evidence work to your team, and DeployOpen can prepare the controls and evidence for an assessment, but it does not issue audit reports or attestations.
Shared responsibility lines
Map each layer before you sign: the physical facility, the operating system, the web server and PHP runtime, Dolibarr itself, its modules and DoliStore add-ons, and the database. On DoliCloud the vendor usually owns the lower layers while you own users, data entry and configuration. Self-hosting makes you own every layer, including patching add-ons from third-party authors. Write the split into a responsibility matrix and agree it before go-live.
What a Dolibarr deployment actually needs from your team
Running Dolibarr yourself means owning a PHP application on a web server, backed by a relational database. The supported combinations are PHP on Apache, Nginx, Lighttpd or IIS, with MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer. Microsoft SQL Server support is listed as experimental, so it should not be your production choice without testing. Your team must choose the web server and database, keep their versions patched, configure PHP, and decide how the application is placed behind your network controls. Confirm the exact PHP version against the Dolibarr prerequisites page for the release line you plan to run, since that requirement is not restated here.
Dolibarr is modular, so the first design decision is which modules to enable. The product covers CRM and sales, HR, invoicing, stock, manufacturing, point of sale and projects, and each enabled module adds code, permissions and data to maintain. Keep the enabled set small at go-live and document why each module is on. Add-ons from DoliStore and custom work built with the Module Builder also become code your team or a partner must upgrade and test with every new release.
The prerequisites page estimates about 150 MB for program files and 35 MB for an initial database, plus space for uploaded and generated documents, and recommends at least a 1 GHz CPU for 30 or more users. Those figures are a floor for planning, not a sizing exercise. Document growth, attachment volume and backup retention will drive storage, and concurrency, reporting and add-on load will drive CPU and memory. When a vendor runs this stack, the hardware, patching, database maintenance and backup schedule move to the provider, while your team still owns data classification, user access and the contract terms that define restore expectations. Ask any hosting provider for their backup retention, restore test cadence and where data is stored.
What your team runs in each hosting model
This table splits day-to-day operating tasks between DoliCloud and a self-hosted Dolibarr install. Read each row as a question to put to the vendor or to your own team, and treat anything marked as a confirmation item as open until it appears in the DoliCloud terms or your own runbook.
| Task | DoliCloud (vendor hosted) | Self-hosted Dolibarr (your team) |
|---|---|---|
| Dolibarr version upgrades (for example 24.0.0 on August 20, 2026 and 24.0.1 on September 7, 2026) | Vendor schedules and applies upgrades; confirm timing, notice and whether you can defer a version | Your team tests, plans and applies each release, including the 24.0.x patch line |
| PHP runtime patching | Vendor-managed; confirm supported PHP versions and change notice | Your team picks the PHP version and patches it for the web server stack |
| Database engine (MySQL, MariaDB or PostgreSQL) | Vendor-managed; confirm which engine and version you receive | Your team selects the engine and version, applies patches and capacity changes |
| Web server (Apache, Nginx, Lighttpd or IIS) | Vendor-managed; confirm TLS configuration and hardening baseline | Your team installs, configures and hardens the server and its modules |
| TLS certificates and configuration | Confirm who issues, renews and configures certificates, and which protocols are enforced | Your team owns certificate issuance, renewal, cipher policy and expiry alerts |
| Backups and retention | Confirm backup frequency, retention period, location and whether you can export a full copy | Your team designs backup scope (database, documents, configuration), schedule and off-site copies |
| Restore testing | Confirm whether the vendor runs restore tests and whether you can request a test restore into a separate environment | Your team schedules and records restore tests and measures how long recovery takes |
| Monitoring and alerting | Confirm uptime, resource and log visibility you receive and how incidents are reported | Your team selects monitoring, sets alert thresholds and handles on-call response |
| DoliStore add-on and custom module compatibility | Confirm whether vendor upgrades are tested against your installed add-ons and who fixes breakage | Your team tests each add-on and custom Module Builder code against every core upgrade |
Which modules and add-ons each model supports
Dolibarr is a modular PHP application, and both models can enable the same core modules. The Dolibarr website lists modules for CRM and sales (proposals, orders, contracts, help desk), HR (employees, expense reports, leave, timesheets, recruitment), invoicing, stock, manufacturing (MRP), point of sale and projects. On DoliCloud, these are the modules you work with inside a hosted instance, so your job is to confirm that every module your teams need is enabled on the plan you choose. Self-hosting gives you the same module set with full control over which ones are switched on and when.
- CRM and sales: Proposals, orders, contracts and help desk are standard modules in both models.
- HR and projects: Employees, expense reports, leave, timesheets, recruitment and projects cover most people-management needs without add-ons.
- Invoicing, stock and MRP: Core financial and inventory modules are part of the base platform, while manufacturing (MRP) suits teams that build products in-house.
- Point of sale: Enable this only if you run retail or counter sales, since it adds a workflow your back office must support.
- Module selection: Turn on only the modules in use, which keeps the interface and the attack surface smaller.
Before committing, list the modules your processes need and confirm each one is available on the DoliCloud plan you are considering.
The DoliStore add-on marketplace extends Dolibarr beyond its standard modules. Add-ons are third-party code, so their license terms, maintenance history and compatibility with each Dolibarr release vary and must be checked one by one. On a self-hosted instance, you install and test add-ons on your own server, which means you control the timing of updates and the review of code. On DoliCloud, the provider decides which add-ons run on its platform, so availability depends on that provider's policy rather than on your choice alone.
- Compatibility: Confirm that each add-on supports the Dolibarr version you run or plan to run.
- Licensing: Review each add-on license and any per-user or subscription fees attached to it.
- Maintenance: Check the publisher's update frequency and whether the add-on has been updated for recent releases.
- Installation control: Self-hosting lets you test add-ons in a staging copy before they reach production.
- Hosted restrictions: On DoliCloud, ask in writing which add-ons are permitted and how installation requests are handled.
Ask DoliCloud for its written list of permitted add-ons before you rely on any of them in your process.
Dolibarr offers a low-code Module Builder for creating custom modules, and it is also possible to write modules in PHP directly. Self-hosting gives your developers access to the file system, database and configuration needed to build, test and deploy these modules. Custom code also becomes your responsibility: you must maintain it through each Dolibarr release, review it for security and document it for future staff. On DoliCloud, the ability to install custom modules depends on the provider's terms, so custom development should not begin until that question is answered.
- Module Builder: A low-code route for generating standard module structures, useful for internal screens and workflows.
- Custom PHP code: Full control over logic and data handling, with the trade-off of ongoing maintenance per release.
- Testing: Self-hosted environments let you run staging copies and regression tests before each upgrade.
- Deployment access: Self-hosting provides direct control over file deployment and database changes.
- Ownership: Your team or an implementation partner carries the upgrade work for custom modules.
Confirm with DoliCloud whether custom modules can be installed and who performs the testing and upgrades for them.
Module and add-on fit is easy to assume and expensive to discover late. The questions below help you test a hosted plan against your actual process before you sign. They also show where self-hosting shifts responsibility to your team. Ask for answers in writing so they can be compared with the terms you receive at signature.
- Module list: Ask which standard modules are enabled on each plan and whether any require an upgrade.
- Add-on policy: Ask which DoliStore add-ons are permitted and whether new requests are reviewed.
- Custom module policy: Ask whether custom or Module Builder modules can be installed and under what conditions.
- Upgrade impact: Ask how add-ons and custom modules are handled when Dolibarr releases a new version.
- Support boundaries: Ask who supports a failing add-on or custom module, the provider or your own team.
If a module or add-on is central to your process, run a trial on a copy of your real data before committing to either model.
How to move Dolibarr between self-hosted and DoliCloud
This sequence produces a verified inventory of data, documents, modules and custom code, a tested restore on the target, and a cutover plan with a rollback path before any live users move.
Confirm the move scope with the vendor
Before any export, ask DoliCloud, or your own Dolibarr administrator in a self-hosted to cloud move, what the target environment supports: the Dolibarr version it runs, the database engine and version, which DoliStore add-ons and custom modules it accepts, whether custom PHP code can be deployed, and how document storage and backups are handled. Record the answers in writing, separately for each direction, because the moves are not symmetrical. The output is a signed-off scope note that names the source version, target version and every constraint.
Export data and inventory the database
A Dolibarr administrator takes a full database dump from the source and confirms the schema version matches the application version. Record row counts for core tables such as third parties, invoices, products and stock movements, so the restore can be checked against them. Export the configuration parameters and the list of enabled modules from the admin screens. The output is a dump file, a row-count report and a configuration list stored with a checksum.
Transfer documents and attachments
Dolibarr stores uploaded and generated documents on the file system, not in the database, so they must move as a separate transfer. Copy the documents directory with its folder structure and permissions intact, then compare file counts and total size against the source. Confirm with the target provider how documents are stored, whether there are size or retention limits, and how links from database records to files will resolve after the move. The output is a matched file inventory and a note on any files that did not transfer.
Inventory modules, add-ons and custom code
List every enabled core module, every DoliStore add-on and every module built with the Module Builder or hand-written. For each item, record the version, the license terms and whether the target accepts it. Custom code, including triggers, hooks, templates and PDF layouts, needs a line-by-line review, because code that depends on server paths, PHP extensions or file writes may not run on a managed platform. The output is a compatibility register that marks each item as carried over, replaced or retired.
Run a test restore on the target
Restore the database dump and the document set into a non-production instance of the target environment, then run the upgrade or migration steps required for the destination version. Check login, company settings, invoice numbering, stock valuations, PDF generation and email sending, and compare the row counts against the export report. Log every error and every module that fails to load. The output is a test report with a pass or fail result for each check and a list of fixes that must be made before cutover.
Plan cutover and a rollback path
Agree a cutover window with the business owners and the vendor, freeze data entry on the source, take a final incremental export, and repeat the restore and checks on the target. Keep the source instance intact and read-only until the target has been accepted, because rollback depends on it. Confirm in writing who performs the rollback, how DNS or the access URL will be switched back, and how any transactions entered on the target during the window would be reconciled. The output is a runbook with named owners and a documented rollback decision point.
Accept the target and retire the source
After users have worked on the target for a period agreed in the runbook, verify the key business processes with finance, sales and operations, then confirm backup jobs run on the new environment and that a restore from those backups has been tested. Only then decommission the source, and keep a sealed final backup under your retention policy. The output is a signed acceptance record, a verified backup on the target and an archived copy of the source.
How total cost changes with team size
DoliCloud costs scale with headcount, while self-hosting costs mostly do not. The DoliCloud Basic plan is listed at 14 euros per user per month, and the Premium plan starts from 45 euros per month, according to the DoliCloud website. Multiplying the Basic rate by your user count gives a recurring bill that rises in a straight line as you add people. Self-hosting has no per-seat software fee because Dolibarr is GPL-3.0 licensed, so its recurring costs are the server or cloud resources, backups, storage for uploaded documents, and the staff time to patch and monitor the stack. Those costs grow in steps, not per user. Confirm whether your plan tier and user count changes trigger a different billing structure before you model a growth scenario.
The break-even point depends on who does the operating work. Build a comparison for two or three illustrative team sizes, such as a 10-person and a 50-person team, and list every line item on both sides: subscription fees, infrastructure, backup storage, administrator hours for upgrades and PHP and database maintenance, and any paid DoliStore add-ons, which carry their own licensing terms. The Dolibarr prerequisites page recommends at least a 1 GHz CPU for 30 or more users, so check whether your sizing for a larger team changes the hardware line. Ask your internal finance team to price staff time at a loaded rate, because that figure often decides the comparison for small teams.
Implementation is a one-time cost on the self-hosted side and a smaller one on the SaaS side. Self-hosting requires initial setup, module selection, data migration, backup testing and hardening, and these are typically one-time costs that recur only when you upgrade. For a quote on a DeployOpen engagement, request a fixed-scope statement listing the modules in scope, migration volume, backup and restore testing, upgrade procedures, and documentation, along with the deliverables and timeline agreed in writing. Ask whether ongoing support is a separate retainer so that recurring and one-time costs stay distinct. DeployOpen does not publish prices, so the quote is the only reliable figure for your environment.
Questions buyers ask before choosing a Dolibarr hosting model
What does self-hosting Dolibarr cost in effort?
Self-hosting costs you the time to install, configure, patch and back up the stack, and that effort recurs for as long as you run it. Dolibarr is free under GPL-3.0, so the license adds nothing to the bill. The main cost components are your server and database hosting, the staff hours to keep PHP, the database and the web server current, and any consultant time for setup or custom work. The Dolibarr prerequisites page estimates about 150 MB for program files and 35 MB for an initial database, plus space for uploaded and generated documents, and recommends at least a 1 GHz CPU for 30 or more users. Those are starting points, not a sizing study. Ask any implementation partner for a written breakdown of one-time setup against recurring upkeep, and ask who carries the on-call duty.
How long does a Dolibarr migration take and what drives it?
The duration depends on data volume, the number of modules in use, custom fields and integrations, and how clean your current records are. No researched figure for migration duration is available for this comparison, so confirm the timeline against a written scope before you plan around it. Key drivers include the number of legacy systems feeding data in, the amount of history you need to carry over, whether you move to a new database engine, and how many users must be trained and tested. Ask for a scope that lists each data source, the cutover approach and the rollback plan, since those items set the timeline far more than the software does.
What does running Dolibarr need from my internal team?
You need people who can administer a PHP application and its database, and who can own the web server, scheduled jobs and file storage for uploaded documents. Dolibarr is modular, so someone also has to decide which modules to enable and who approves changes to them. The team should be able to read logs, restore from backup and test upgrades before they reach production. If that skill set is thin, budget for an outside partner for the setup and for ongoing support. Confirm with any provider which tasks they own and which remain with your staff.
Can my team run Dolibarr without outside help?
Yes, many teams run Dolibarr with in-house staff, since it is GPL-3.0 software with a published prerequisite list and runs on MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer. The real question is whether you can keep it patched, backed up and tested on a schedule. Dolibarr 24.0.0 was released on August 20, 2026, and 24.0.1 followed on September 7, 2026, so planning for regular upgrades matters. If you lack that capacity, consider a managed option or a fixed-scope engagement for setup and handover. Test your own skills against a realistic checklist before you decide.
Does DoliCloud allow custom Dolibarr modules?
Confirm this with DoliCloud before you commit, because the researched facts do not describe what the SaaS plans permit for custom code. Dolibarr itself is extended through the DoliStore add-on marketplace and a low-code Module Builder, so ask whether those extensions are available on each plan and whether you can install third-party modules. Ask also how custom fields, scheduled jobs and external integrations are supported, and what happens to them at upgrade time. A self-hosted deployment gives you direct control over the code, but it also makes you responsible for testing it after every release.
How do Dolibarr upgrades differ between DoliCloud and self-hosting?
On DoliCloud, the provider controls the timing and execution of platform updates, while on a self-hosted instance your team plans and runs each upgrade. The researched facts confirm that older lines, including 23.0 and 22.0, still received maintenance releases in 2026, which gives you time to plan, but the exact upgrade process on each hosting model should be confirmed in writing. For self-hosting, expect to test modules, custom code and integrations against each new version in a staging copy. Ask DoliCloud how it notifies customers, how far in advance it schedules upgrades and whether you can delay them.
How are Dolibarr backups and restores handled?
Backups are the part of the hosting model that most often gets missed, so define them before go-live. Self-hosted, your team must back up the database and the document directory, test restores, and store copies off the server. Those files are separate, so a database backup alone does not restore uploaded invoices or attachments. On DoliCloud, ask what is backed up, how often, where copies are stored, how long they are retained and how a restore is requested and timed. Confirm the restore time objective and recovery point you need, and get the answers in writing before you sign.
How DeployOpen scopes and supports self-hosted Dolibarr
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Dolibarr, that means working out which modules, DoliStore add-ons and database engine your team needs, then building and handing over a deployment you can run, audit and upgrade yourselves.
How we scope
- Map the modules, users, integrations and data flows your team actually needs before choosing a hosting path.
- Confirm the target stack, including PHP version, MySQL, MariaDB or PostgreSQL, web server and storage for documents.
- Agree scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Install and configure Dolibarr in your cloud account, data center or air-gapped network, not on a vendor-hosted tenant.
- Enable only the agreed modules and document any Module Builder or DoliStore add-on changes as custom code you own.
- Test upgrades, backups and restores in a staging copy before anything touches production data.
How we hand over
- Provide written runbooks covering installation, configuration, backup schedules, restore steps and upgrade procedures.
- Document the module list, add-on versions, database settings and access roles so your staff can maintain the system.
- Walk your administrators through the handover so routine tasks stay with your internal team after the engagement ends.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build.
- Plan Dolibarr version upgrades against the maintenance window of your chosen release line before each change.
- Ask any provider, including DoliCloud, to confirm in writing which backups, upgrades and data exports are included.
