Umbraco Cloud vs self-hosted Umbraco

Umbraco Cloud vs self-hosted Umbraco: which model fits your team

Choose Umbraco Cloud if you want Azure hosting, environments and content synchronization managed for you. Choose self-hosted Umbraco if your data, network or infrastructure must sit under your own controls. The deciding factors are less about the CMS itself, which is the same MIT-licensed .NET product in both cases, and more about where the site runs, who operates it and who answers for it during an audit. Umbraco Cloud is a fully managed service on Microsoft Azure with automatic backups, a global CDN, HTTPS, Development, Staging and Live environments, and Umbraco Deploy to move content and structure between them. Self-hosting gives you the choice of database, SQLite or SQL Server, and the choice of hosting, but the operating work moves to your team. The conditions that matter are concrete. Data residency rules, a corporate mandate to run workloads in your own cloud accounts or data centers, and an existing on-premises standard all point toward self-hosting. An existing Azure estate with governance already defined, a small in-house .NET team, or a need for a standard release pipeline point toward Cloud. Ask your team what the Azure subscription, networking, identity and monitoring baselines look like today, and whether those baselines can cover a managed Umbraco tenant. Confirm with Umbraco which regions and data locations apply to Umbraco Cloud before you assume a residency fit.

Licensed add-ons apply in both models. Umbraco Engage needs a valid license to run on a public domain, covering one production domain and up to two development or testing domains. Umbraco Forms runs unrestricted locally but needs a license on a public domain, sold per domain and per installation. Before you compare totals, confirm with Umbraco how those licenses are handled on a managed Cloud project versus a self-hosted installation, because domain counts, environment setup and who holds the license record can differ. Budget for the license cost in both scenarios, and treat the environment count as a planning input, not an assumption. Before committing, plan the upgrade path, because it is the most time-sensitive difference. Umbraco 17 is an LTS release with end of life on November 27, 2028, and end of service on Umbraco Cloud on November 27, 2031. Umbraco 13 reaches end of life on December 14, 2026, with Umbraco Cloud service ending December 14, 2029. On Cloud, hosting continues for the duration of Extended Long-Term Support, up to 24 months, and then for 12 months on dedicated resources. Self-hosted sites follow the same product lifecycle, but you own the .NET hosting upgrades, the patching and the decommissioning. Read the Umbraco end-of-service policy and ask your implementation partner to write the upgrade effort into the scope.

Umbraco Cloud vs self-hosted Umbraco on control, features and cost structure

This table compares who runs the hosting, environments, database and add-ons under Umbraco Cloud and under a self-hosted Umbraco install on .NET. Read each row against your own hosting constraints, team skills and the quotes you collect, since the cost structure depends on contracts you have not yet signed.

Factor	Umbraco Cloud	Self-hosted Umbraco
Source license	Umbraco describes itself as free and open source, and the Umbraco-CMS repository is MIT licensed. Cloud hosting is a separate commercial service.	The Umbraco-CMS repository is MIT licensed, so the core CMS is free to run on your own infrastructure.
Hosting model	Fully managed service for building and hosting Umbraco sites on Microsoft Azure.	You choose and operate the hosting, such as your own cloud account, data center or on-premises servers.
Environments	Development, Staging and Live environments are provided, with Umbraco Deploy to synchronize content and structure between them.	You design and build your own environment pipeline and promotion process, including any deployment tooling you adopt.
Backups, CDN and HTTPS	Automatic backups, a global CDN and HTTPS are included in the service. Confirm retention and recovery terms in the contract.	You provision backups, CDN, certificates and disaster recovery. Ask your team or DeployOpen to document these as part of scope.
Runtime and database	Current documentation requires .NET 10.0 or higher. Confirm which database options the managed service supports for your project.	Current documentation requires .NET 10.0 or higher and supports SQLite or SQL Server. You select and maintain the database.
Content Delivery API and add-ons	The Content Delivery API is opt-in and must be enabled in configuration. Umbraco Engage and Umbraco Forms need valid licenses on public domains, which apply in either model.	The same Content Delivery API and add-on licensing rules apply, and you configure access, API keys and member authentication yourself.
Who is paid for what	Umbraco is paid for the managed hosting and platform service. Add-on licenses are bought separately. Development partners are paid for build and support work.	Your infrastructure provider is paid for servers, storage, network and backups. Add-on licenses are bought separately. Partners are paid for build, hardening and operations.
Recurring versus one-time cost	Hosting and service fees recur. Build and integration work is typically one-time, with retainers for ongoing support. Confirm the billing model with Umbraco.	Infrastructure, monitoring, patching and staff time recur. Setup, hardening and documentation are usually one-time, with retainers for ongoing work.
What to ask for in a quote	Hosting tier, environment count, backup and CDN terms, Umbraco Deploy scope, add-on license counts, and renewal terms.	Infrastructure sizing, licensing for SQL Server if used, monitoring and backup tooling, patch cadence, and the effort to maintain the .NET upgrade path.

Where Umbraco data sits and who controls access in each model

Umbraco Cloud places hosting on Microsoft Azure under Umbraco's management, while a self-hosted site keeps data wherever your own infrastructure sits. The cards below cover location, administrative control, API access rules and the evidence your compliance team must still produce in either model.

Azure region choice on Umbraco Cloud

Umbraco Cloud is a managed service on Microsoft Azure, so your site's hosting location is set by what the platform offers, not by your own cloud account. Before committing, ask Umbraco which Azure regions are available for your project, whether the Development, Staging and Live environments can sit in different regions, and where automatic backups and the global CDN store or cache content. Those answers decide whether your data residency position can be stated accurately.

Self-hosted location and data residency

A self-hosted Umbraco site runs in your cloud account, data center or private network, and the content database, media files and logs live where you put them. This gives you direct control over residency and network boundaries, but it also makes you responsible for backup locations, replication and disaster recovery sites. Document each location, including any SQL Server or SQLite file that holds content, so a reviewer can trace every copy of personal data.

Administrative and deployment access

On Umbraco Cloud, Umbraco operates the hosting platform, and your team's access is governed by the project and environment roles you assign in the Cloud portal. Self-hosting moves the hosting, patching and deployment pipeline access to your staff or your implementation partner. Ask who can promote content and code to Live, who holds production database credentials, and how administrative sessions are logged in each model.

Preview access with API keys

The Content Delivery API is opt-in and must be enabled in configuration. Unpublished content is returned only for preview, and only when the request carries an API key, so the key becomes a sensitive credential. Confirm how the key is issued, stored, rotated and restricted to front-end builds in both models, because a leaked preview key exposes draft content that was never meant for publication.

Protected content with member authentication

The Content Delivery API serves protected content only when member authentication is enabled, so access to gated pages depends on that setting being turned on and tested. Check that the member store, password policy and session handling meet your identity requirements in both models, and test that protected content cannot be read without a valid member session. Treat this as a configuration control that needs evidence, not as a default you can assume.

Evidence compliance teams still need

Moving to Umbraco Cloud does not transfer your compliance obligations. Your team still needs to show access reviews, change records, backup restore tests and the data flow map for each model. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Ask the auditor which evidence they expect before choosing a model.

Which Umbraco features each hosting model gives you

Umbraco Cloud is a fully managed service for building and hosting Umbraco websites on Microsoft Azure. The platform handles much of the hosting work that a self-hosted team would otherwise own, and it is built around a fixed set of environments and a synchronization tool that moves content and structure between them.

Environments: Development, Staging and Live environments are provided as part of the service, so changes can be built and reviewed before they reach production.
Umbraco Deploy: Synchronizes content and structure between environments. Confirm how it applies to your own content workflow before you depend on it.
Automatic backups: The service takes backups automatically. Ask the vendor for the retention period and restore procedure in writing.
Global CDN and HTTPS: A global CDN and HTTPS are included, which removes two components a self-hosted team would configure and maintain.
Azure dependency: Hosting is tied to Microsoft Azure, so confirm that your cloud, data residency and procurement rules allow it.

Before you commit, confirm which Umbraco version your site will run and its end-of-service date on Umbraco Cloud, because the cloud timeline differs from the self-hosted timeline.

How Umbraco Cloud and self-hosted end-of-service dates differ

The end-of-service dates for Umbraco Cloud and self-hosted Umbraco are not the same clock, so plan from the Cloud dates only if you intend to stay on Cloud. Umbraco 17 is an LTS release published on November 27, 2025, with end of life on November 27, 2028, end of Extended Long-Term Support (XLTS) on November 27, 2030 and end of service on Umbraco Cloud on November 27, 2031. Umbraco 13, the previous LTS release from December 14, 2023, reaches end of life on December 14, 2026, with XLTS ending December 14, 2028 and Umbraco Cloud service ending December 14, 2029. If you run Umbraco 13 today, the first date that affects your roadmap is the end of life on December 14, 2026.

Umbraco's end-of-service policy keeps hosting on Umbraco Cloud for the duration of XLTS, a phase of up to 24 months. After XLTS ends, a project can still run on dedicated resources for 12 months. The Cloud dates therefore describe when Umbraco stops providing the managed service, not when a self-hosted installation stops working. A self-hosted site on .NET with SQL Server or SQLite is not bound to the Cloud service end date in the same way, but its patching and upgrade obligations do not disappear. Ask your partner which Umbraco version you will run after end of life, who applies security fixes to the .NET runtime and Umbraco packages, and how a move to Umbraco 17 would be tested, scheduled and signed off. Confirm these answers with Umbraco directly in the end-of-service policy and your own change process.

What running self-hosted Umbraco adds for your team

This table lists the recurring tasks each model places on your team, and marks which ones Umbraco Cloud takes over and which stay with you in both models. Read the Umbraco Cloud column for what the managed service covers, then check the self-hosted column for what your staff must own. The main takeaway is that the platform choice moves hosting and environment work, but upgrade planning, add-on licensing and on-call coverage stay with you either way.

Recurring task	Umbraco Cloud	Self-hosted Umbraco
.NET runtime and host patching	Taken over by Umbraco Cloud on Microsoft Azure, confirm patch timing in the service terms	Your team patches the .NET 10 runtime, host OS and web server on your schedule
SQL Server or SQLite administration	Hosted database managed as part of the service, confirm the database options offered	Your team installs, patches, tunes and secures SQL Server or runs SQLite, and owns capacity planning
Backups and restore testing	Automatic backups are provided, but you should still test restores and confirm retention	Your team designs backup scope, schedules and off-platform copies, and must run restore tests
CDN and HTTPS management	Global CDN and HTTPS are included in the service	Your team selects, configures and renews CDN and TLS certificates and manages cache rules
Environment setup	Development, Staging and Live environments are provided, with Umbraco Deploy syncing content and structure	Your team builds and maintains each environment and the promotion process between them
Umbraco version upgrades	Upgrades are tied to the Umbraco Cloud end-of-service dates, your team still tests your own code and add-ons	Your team plans every upgrade against LTS windows, such as Umbraco 17 end of life on November 27, 2028
Add-on license tracking	Your team still tracks Umbraco Engage and Umbraco Forms domain licenses	Your team tracks Umbraco Engage and Umbraco Forms licenses per production and test domain
On-call coverage	Platform incidents are handled by the service, your team still covers content and code issues	Your team covers infrastructure, database, runtime and application incidents, including out-of-hours

How to move a site between Umbraco Cloud and self-hosting

This sequence covers the work in either direction, from Umbraco Cloud to a self-hosted .NET installation or back again. Each step ends with a check you can confirm before the next one starts, and the total effort depends on the site's size, integrations and customizations.

Inventory content, structure, add-ons and domains
Before anything moves, list every document type, content type, media folder, member group and API consumer. Add each installed add-on and every public domain and subdomain. On Umbraco Cloud, use the Development environment as the reference point and compare it with Staging and Live. For a self-hosted site, build the same list from the existing database and source repository. Mark which add-ons are Umbraco Engage or Umbraco Forms, because their licenses are tied to domains. The step is done when the site owner approves one inventory that matches what runs in production.
Confirm the Umbraco version and .NET 10 target
Record the Umbraco version the site runs today and the version the target needs. Current Umbraco CMS documentation requires .NET 10.0 or higher and supports SQLite or SQL Server, so confirm which database the target will use. Check the end-of-service policy for the current version, since Umbraco 13 reaches end of life on December 14, 2026 and Umbraco 17 is the current LTS release. Ask Umbraco whether an upgrade must happen before the move. The step is done when the version pair and database choice are written down and agreed with Umbraco.
Export or redeploy through Umbraco Deploy where it applies
Umbraco Cloud uses Umbraco Deploy to synchronize content and structure between Development, Staging and Live. Before you rely on it for a move, confirm with Umbraco whether Deploy supports your path, including a self-hosted target, and under which license. If it does not apply, plan a manual export of content, media and document types, with a separate process for database data. When moving back to Cloud, push the project through Development and Staging before Live. The step is done when a test environment shows the same structure and content counts as the inventory from the first step.
Rebuild hosting, backups and the CDN
Umbraco Cloud provides managed Microsoft Azure hosting, automatic backups, a global CDN and HTTPS. A self-hosted site needs equivalents that your team builds, operates and tests. Decide where the application and database run, how backups are scheduled and restored, how the CDN or edge cache is configured, and how TLS certificates are issued and renewed. When moving to Cloud, confirm which of these the platform covers so nothing is left unmanaged. Run a restore from backup into a non-production environment before cutover. The step is done when a restore has been proven and the CDN and HTTPS settings are documented.
Reissue Engage and Forms licenses for new domains
Umbraco Forms requires a valid license on a public domain. Licenses are sold per domain, cover subdomains and include two development or testing domains, with one license per installation. Umbraco Engage requires a license covering one production domain and up to two development or testing domains. A change of hosting or domain name can change which licenses apply, so list every domain the site will use after the move. Then ask Umbraco how each license is reissued or transferred. The step is done when every public domain has a confirmed license and each non-production domain is covered.
Verify the Content Delivery API and integrations
If front ends, mobile apps or partners read the site through the Content Delivery API, test each consumer on the target. The API is opt-in and must be enabled in configuration. Unpublished content is returned for preview only with an API key, and protected content is served only when member authentication is enabled. Confirm these settings match the source site. Then check base URLs, form posts, identity provider callbacks and third-party webhooks. Record every consumer that needed a change. The step is done when each consumer reads published content from the target and protected content still requires login.
Plan cutover and rollback before the switch
Set the cutover order: freeze content edits on the source, run a final sync, switch the domain binding or DNS record, then confirm HTTPS and the CDN on the new address. Write the rollback path before you start. Name the record or binding that reverts, state how the source stays read-only, and decide how content edited during the window is reconciled. Keep the source available until the new site has been checked in production. The step is done when the site owner signs the rollback plan and a named person is able to execute it.

What drives cost in each hosting model and what to ask for in a quote

Umbraco Cloud and self-hosted Umbraco shift cost between a vendor subscription and your own infrastructure, staff and partner time. The cards below separate who is paid for what, which costs are one-time and which recur, and what to put in a written scope so that two quotes can be compared on the same basis.

Umbraco Cloud subscription terms

Umbraco Cloud is a managed service on Microsoft Azure with Development, Staging and Live environments, backups, a global CDN and HTTPS. Your recurring Cloud charge covers that hosting and platform service, so ask Umbraco for the subscription terms in writing, including what each environment costs, how many environments your plan includes, what counts as a Live site, and how overages are billed. Confirm these with Umbraco directly, since this page does not state them.

Azure and infrastructure in self-hosting

When you run Umbraco yourself on .NET with SQL Server or SQLite, you pay the cloud or data center provider for compute, storage, networking, backups, CDN and monitoring, and you own the sizing decisions. Ask the partner to state which hosting components are in scope, who holds the cloud accounts, and which costs are billed directly to you rather than passed through the implementation fee.

Add-on licenses per domain

Umbraco Engage and Umbraco Forms are licensed per domain. Engage requires a valid license for one production domain plus up to two development or testing domains, and Forms licenses also cover subdomains and include two development or testing domains, with one license per installation. Count every public domain, subdomain and environment in the quote, and confirm with the vendor whether these licenses are sold and renewed the same way under each hosting model.

Internal staff time and patching

Self-hosting moves patching, dependency updates, database maintenance, backup testing and upgrade work onto your team or your partner. Umbraco Cloud reduces some of that operational load but does not remove application upgrades. Ask who owns each recurring task, how often upgrades are planned, and how much internal review time the team must budget for each release cycle.

One-time implementation scope

Setup, migration from an existing site, hardening, documentation and handover are one-time costs in either model. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the list of content types and integrations in scope, the migration method, the environments to be configured, the hardening baseline, and the documentation and training delivered at handover.

Ongoing support retainers

Support, upgrades and continuous testing can be bought as a retainer after go-live. A retainer is a recurring cost that sits on top of hosting and licenses, so compare it against what your own team would otherwise absorb. Ask for the response scope, the upgrade work included, how Umbraco version changes are handled, and what happens when an LTS release reaches end of service, since end-of-service dates differ between Cloud and self-hosting.

What buyers ask before choosing self-hosted Umbraco or Umbraco Cloud

What does self-hosting Umbraco cost compared with Umbraco Cloud?

The CMS itself is free and MIT licensed, so the difference lies in who pays for hosting, operations and add-ons. Umbraco Cloud is a managed service on Microsoft Azure with automatic backups, a global CDN, HTTPS and Development, Staging and Live environments, and you pay Umbraco for that service under its own terms. Self-hosting moves those costs to your side: cloud or data center infrastructure, SQL Server licensing where it applies, monitoring, backups, patching and the staff time to run them. Licensed add-ons apply in both models. Umbraco Forms needs a valid license on a public domain, and Umbraco Engage needs a license covering one production domain and up to two development or testing domains. Ask any quote to separate one-time build work from recurring hosting, support and upgrade effort, and to state which environments and domains are included.

How long does a move between Umbraco Cloud and self-hosting take?

It depends on scope, and no duration is supplied here, so treat any timeline as unconfirmed until you have a written plan. The main variables are the number of content types, custom packages and integrations, the volume of media, how many environments must be rebuilt, and how much of the Cloud workflow built around Umbraco Deploy you rely on. Moving off Cloud means rebuilding hosting, database, identity and deployment pipelines on your side and validating content after migration. Moving onto Cloud means fitting the site to its environment model and promotion workflow. Both directions need a test run against a copy of production, a cutover plan and a rollback path. Ask for a scope document that lists these items and the testing approach before you accept a schedule.

Can a .NET team run self-hosted Umbraco without outside help?

Often yes, if the team already ships ASP.NET applications, but the platform requirements set the baseline. Current Umbraco CMS documentation requires .NET 10.0 or higher and supports SQLite or SQL Server. Because the source is MIT licensed, you can build, extend and host it without a vendor agreement. The real question is capacity and continuity: can your staff own the upgrade path across LTS releases, security patching, backup and restore testing, infrastructure and incident response? Check whether you have people who understand the Umbraco back office and its packages, not only general .NET skills. A team with that depth can run it alone. A team that will be stretched across other products usually needs written runbooks, a named on-call rota and an outside partner for peak work or upgrades.

What work must your own staff do when self-hosting Umbraco?

Self-hosting makes your staff responsible for every layer that Umbraco Cloud otherwise manages. In practice that covers:

Hosting: provisioning and patching servers or Azure resources, the CDN, TLS certificates and DNS.
Data: backup design, regular restore tests and database maintenance on SQL Server or SQLite.
Release management: promoting content and code between your development, staging and production environments. Cloud handles this through its Development, Staging and Live setup and Umbraco Deploy, so you need an equivalent process of your own.
Upgrades: moving between LTS lines before end-of-life dates, with licensed add-ons updated alongside.
Security and monitoring: logging, intrusion response and access control for the back office and any member-protected content.

Ask who is on call, how often restores are tested and where the runbooks live. Those answers show whether this is a part-time task or a dedicated role.

Does the Content Delivery API change the Umbraco hosting decision?

It can influence the decision, but it does not settle hosting on its own. The Content Delivery API returns content as JSON for headless front ends. It is opt-in and must be enabled in configuration. Unpublished content is returned only for preview and only with an API key, and protected content is served only when member authentication is enabled. Those controls apply whichever host you choose. A headless setup often places a CDN or separate front end in front of the API. Cloud includes a global CDN, so a self-hosted team must design and operate that layer itself. If you run a separate front end, confirm where the API sits, how keys are rotated and how preview access is restricted. Check the current API documentation during design, because its access rules govern exposure wherever the site runs.

How do the Umbraco 13 and 17 end-of-life dates affect planning?

Umbraco 13 has the nearer deadlines. It reaches end of life on December 14, 2026, with Extended Long-Term Support ending December 14, 2028 and Umbraco Cloud service ending December 14, 2029. Umbraco 17, an LTS release published November 27, 2025, reaches end of life on November 27, 2028, with XLTS ending November 27, 2030 and Cloud service ending November 27, 2031. Umbraco's policy says hosting continues on Umbraco Cloud for the duration of XLTS, a phase of up to 24 months, and that projects can then run on dedicated resources for 12 months after XLTS ends. The dates therefore differ by model. Plan the upgrade path, budget window and test cycle against the earliest date that applies to your hosting model, and confirm the current policy before you commit.

When should a team bring in an implementation partner like DeployOpen?

Bring in a partner when the work has a defined scope your team cannot absorb, such as a move between hosting models, a first self-hosted build with security hardening, or an upgrade across an LTS boundary. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. It does not issue audit reports or certifications. Confirm in writing whether a proposed scope covers Umbraco specifically, and ask for named deliverables, a handover plan and a clear view of who holds the runbooks after launch.

How DeployOpen scopes, delivers and supports self-hosted Umbraco

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Umbraco, that means working out which hosting model fits your governance, runtime and end-of-service timeline before any build starts.

How we scope

Start with a written scope covering hosting target, database choice (SQL Server or SQLite) and the Umbraco version you plan to run.
Document which licensed add-ons, such as Umbraco Forms or Umbraco Engage, apply to your production and test domains.
Agree deliverables and timelines in writing before work starts, since most engagements are fixed-scope.

How we build

Set up the .NET runtime, environments, deployment pipeline and backup routines in your infrastructure, as the scope defines.
Configure the Content Delivery API only where headless delivery is in scope, with preview and member authentication settings reviewed.
Test content workflows, upgrade paths and restore procedures before any site goes live, and record the results.

How we hand over

Deliver architecture notes, runbooks and an upgrade calendar that tracks each Umbraco release's end-of-service dates.
Provide evidence for compliance assessments, such as configuration records and access logs. Independent auditors issue any formal assessment or certification.
Walk your platform, operations and content teams through the handover so they can run routine tasks without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Plan major version moves well ahead of each end-of-service date, including the move between Umbraco Cloud and dedicated hosting.
Ask any provider, including us, to confirm current license terms, hosting commitments and support windows in writing.