Open Dental Cloud vs Self-Hosted: 2026 Guide

Open Dental Cloud is the hosted version managed by Open Dental Software. The company describes it as looking and feeling like the local version while moving server and database upkeep into the hosted service. Open Dental also handles routine cloud backups and installs updates automatically as part of the service.

As of August 2026, Open Dental says the service is available only to U.S. customers and remains in limited release. That matters because a practice should not plan a migration timeline around the assumption that every office can enroll immediately. Availability and fit should be confirmed directly with Open Dental before hardware, lease, or construction decisions depend on it.

Open Dental also publishes workstation and connectivity requirements for the cloud service. The current requirements call for Windows workstations, at least 20 Mbps download and 10 Mbps upload, and the vendor's fit guidance favors latency below 30 milliseconds to an Open Dental data center. Offices with unstable connectivity or high latency need to solve that problem before treating cloud hosting as a reliability upgrade.

For most dental practices, self-hosted means the Open Dental database and related files are hosted on infrastructure the practice controls or contracts its IT provider to manage. In a traditional single-office deployment, the database server is usually on the local network and workstations connect to it directly or through supported connection methods.

The practice retains responsibility for the server operating environment, database service, storage, backups, patching, endpoint security, networking, power protection, hardware lifecycle, and recovery planning. That responsibility can be handled by an internal IT team or outsourced to a dental-focused managed service provider, but it does not disappear simply because the practice owns the hardware.

Open Dental also documents a separate self-directed cloud-hosting model in which the practice's IT company manages a cloud server and uses supported architecture such as Middle Tier. That is different from Open Dental Cloud. The software may still be hosted away from the office, but infrastructure design, certificates, VPNs, server security, storage, and operational support remain the practice's or IT provider's responsibility.

Open Dental Cloud removes much of the database-server administration from the dental office. Open Dental states that the cloud service is intended for practices that do not have the resources or desire to manage a local server. Database and OpenDentImages backups are handled within the service, and the software is routinely updated by Open Dental.

That does not eliminate local IT. Open Dental specifically notes that the computers accessing Open Dental Cloud are still managed by the practice or its IT provider. Workstations, Windows updates, endpoint security, printers, scanners, imaging devices, local networks, Wi-Fi, internet circuits, user accounts, and other office systems still need support.

A self-hosted office has more infrastructure to maintain but also more direct control. IT can schedule server maintenance, coordinate application updates with other vendors, choose backup platforms, monitor hardware health, and design recovery around the practice's broader technology stack. The tradeoff is that those controls only create value when someone is consistently responsible for them.

A hosted practice-management system makes the internet connection part of the clinical workflow. If the office cannot reach the hosted environment, staff may lose access to functions they normally use for scheduling, charting, billing, or treatment coordination until connectivity returns or an alternate connection is available.

A local server can allow workstations on the same functioning network to continue reaching the database during an internet outage, although cloud-dependent services such as eligibility, eClaims, online forms, payment tools, patient messaging, and remote services may still be affected. Local hosting therefore does not make a practice independent from the internet; it changes which workflows can continue when the WAN connection fails.

For a practice considering Open Dental Cloud, measure real latency, packet loss, and uptime during clinical hours rather than relying only on the advertised ISP speed. Offices that cannot tolerate a single-circuit outage should evaluate redundant internet and automatic failover before migration. The business question is not simply whether the office has broadband; it is whether connectivity is dependable enough to become part of the practice-management availability plan.

This is one of the most important screening questions. Open Dental states that some features behave differently in its hosted service and that there are limitations on interoperability with third-party solutions. Practices that depend on imaging bridges, payment devices, scanners, specialty applications, lab workflows, or custom integrations should validate every critical connection before choosing a hosting model.

Open Dental Cloud uses a local ODCloudClient on Windows workstations to bridge to supported third-party software. The vendor also publishes a Cloud Differences page that lists features that may be unavailable or behave differently. For example, the cloud service does not simply host every separate imaging application the practice may already use.

A self-hosted environment usually gives IT and software vendors more freedom to work with local applications, shared folders, imaging servers, device drivers, and approved integration methods. More flexibility also means more responsibility: integrations should be documented, vendor-supported, secured, and tested after upgrades rather than depending on undocumented database access or one technician's memory.

Open Dental Cloud includes automatic backups of the database and OpenDentImages folder. Open Dental publishes a schedule that includes daily, weekly, monthly, and yearly backup retention, with off-site copies in the routine. The vendor also states that backups are encrypted and tested for integrity, and customers can request copies through support.

In a self-hosted environment, the practice owns the backup design. Open Dental's documentation identifies the database and OpenDentImages folder as critical data and recommends encrypted backups plus regular restore testing. A responsible dental IT plan should also separate backup credentials, retain off-site or otherwise isolated recovery copies, monitor failures, and document how long restoration of the actual practice-management environment will take.

Do not compare the options using the word 'backup' alone. Ask who monitors failures, how often copies are created, how long they are retained, where they are stored, how restorations are tested, how quickly a usable environment can be rebuilt, and who has authority to start a recovery. Recovery ownership matters as much as backup frequency.

Open Dental supports several multi-location architectures rather than one universal design. Its documentation covers separate databases, VPN-connected offices, CEMT, Middle Tier, terminal-server designs, replication, and Open Dental Cloud. The correct choice depends on whether locations share patients, whether one database is required, how centralized billing works, and how dependable connectivity is between offices.

Open Dental lists its cloud service as a good fit for organizations using Clinics, practices where patients routinely move between locations, and groups that want a shared database without local server upkeep. That can simplify expansion when the integration set is compatible and every office has reliable connectivity.

Self-hosted architectures can also support multiple locations, but they require deliberate design. Open Dental warns against exposing the database service directly to the public internet and documents VPN, Middle Tier, RDP, CEMT, and other supported patterns. A second location should not be connected by simply forwarding the database port through a firewall.

Cloud hosting changes the division of responsibility; it does not make security automatic. In Open Dental Cloud, Open Dental manages the hosted server environment while the practice still manages local workstations, users, office networking, endpoint protection, third-party tools, staff behavior, and many surrounding systems that can access or expose patient information.

With self-hosting, the practice and its IT provider also own the database-server security layer. Open Dental's MySQL security guidance explicitly warns not to expose the MySQL service to the internet and recommends protecting the network and server rather than treating a database password as the only safeguard.

In either model, inventory administrator accounts, vendor access, remote-support tools, backup access, and shared workstations. Use named accounts where supported, strong authentication for privileged systems, least privilege, endpoint protection, logging, tested backups, and documented offboarding. The hosting choice should fit inside the practice's overall security program rather than substitute for one.

Open Dental Cloud is worth serious consideration when the office has dependable low-latency internet, uses Windows workstations, can operate within the published third-party integration limits, wants automatic Open Dental updates and backups, and prefers not to own the database-server lifecycle.

It can also be attractive for growing practices that want a shared database across locations without building and maintaining their own central server architecture. The operational benefit is less infrastructure inside the office and a clearer vendor boundary for the hosted database environment.

The practice should still complete a pre-migration workflow audit. Confirm imaging, payment, scanner, eServices, reporting, export, printing, signature, and specialty workflows. Test the actual connection from every location. Document what happens if the internet fails and which local systems still require the IT provider after the server moves out of the office.

Self-hosting can be the better choice when the practice has capable IT support, requires integrations or imaging workflows that do not fit the hosted service, wants more control over update timing, needs local performance that is less dependent on internet latency, or already has a well-managed server and recovery environment.

It may also fit organizations with specialized multi-location architecture, custom reporting, local storage requirements, advanced virtualization, or integration dependencies that need direct coordination between the database, imaging, and other systems. Flexibility is the main advantage, but only when the environment is documented and maintained.

A self-hosted decision should include a hardware lifecycle, UPS and power planning, server monitoring, database maintenance, network security, patching, encrypted backups, restore testing, replacement planning, and a documented owner for each task. Keeping a server in the office is not a strategy by itself.

Start by listing every workflow that touches Open Dental: operatories, front desk, imaging, scanners, payment terminals, eClaims, patient communication, reporting, labs, specialty software, remote access, and multi-location use. Mark which systems are business-critical and which vendor owns each integration.

Next, measure connectivity and compare responsibilities. Record internet uptime, latency, backup internet options, workstation count, locations, database size, image storage, update preferences, backup requirements, and current server age. Then identify whether the practice or its IT provider has the capacity to own server operations for the next three to five years.

Finally, validate the proposed design with Open Dental and every critical integration vendor before committing. A hosting decision is successful when the practice knows exactly who owns the database, server, backups, workstations, network, integrations, security, and recovery process — and when that ownership matches the way the dental team actually works.