VCloud vs. Cloudron: Which One Fits Your Team?

If you're evaluating managed self-hosting, you've almost certainly looked at Cloudron. It's mature, well-documented, and has a genuinely good community behind it. We'd rather tell you honestly where it beats us than have you find out later.

The short version: Cloudron is software you install on a server you rent and operate. VCloud is a managed service where nobody on your side touches a server. That single difference explains almost every other difference below.

At a glance#

Both include unlimited seats with no per-user fee, automatic TLS, and one-click installs. Now the detail behind each row.

Operational ownership#

Cloudron gives you root on your own box. For a lot of teams that's exactly right - you can install anything, inspect anything, and nobody can take that away from you.

The cost is that everything that happens on that box is yours. Disk capacity, the resize, the reboot window, and the alert at 3am all land on someone specific on your team. Cloudron automates a lot of it - more than a raw server would, including routine OS security updates - but the responsibility doesn't move.

VCloud manages everything, and no tenant gets access to the underlying infrastructure. That's the design rather than a missing feature - it's precisely what makes an SLA underwritable. A provider can't commit to an availability number on a machine that customers can log into and change. If you want root, Cloudron is the better product and we won't try to talk you out of it.

Scaling and availability#

This is the sharpest technical difference, and it isn't our characterization - it's Cloudron's own.

Cloudron runs on a single server. Their founder has stated directly that "horizontal scaling of single apps is outside the scope of Cloudron and we will probably never implement this" (June 2024). Their packaging documentation advises, under "Memory limit", that you "design your app runtime for concurrent use by hundreds of users" and states that "the platform does not support concurrent access by thousands of users."

Multi-node management has been a standing request on their forum for years. A long-running thread on scaling and high availability describes the everyday consequence - "when I need to resize my server (for increasing CPU, disk space or RAM) or reboot for security updates there is downtime" - and as recently as July 2026 someone was still asking for a way to see every node from one dashboard and choose where an app deploys. The reply, from another community member rather than from Cloudron, was that the API exists and third-party dashboards have been built on it. So the building blocks are there; a first-party multi-node feature is not.

One piece of context cuts against the sharpest version of that. Horizontal scaling of a single app is the part Cloudron has ruled out. Managing several servers from one place was deferred rather than rejected: in the same June 2024 thread, Girish said new features would be picked up only after the Cloudron 8 and 9 releases, and both have since shipped. Treat it as absent today, not as permanently off the table.

None of that is a knock on Cloudron's engineering. It's the honest shape of a single-server product, and for most small teams a single server is genuinely enough.

It also explains something that isn't a fair criticism of Cloudron: they don't offer an uptime SLA, and they can't. When the software runs on a machine you rent and administer, the provider has no way to commit to its availability - that's structural to the self-hosted model, not a gap in their product. Uptime is simply your outcome to own.

VCloud can commit to a number precisely because the trade runs the other way. Your storage is kept as redundant copies on separate hardware, so a single hardware failure doesn't take your app down, and capacity moves without a maintenance window. That, plus the fact that nobody outside our team can change the host, is what stands behind 99.9% on Starter and Business and 99.95% on Scale.

What gets deployed#

Most platforms in this category treat one-click deployment as the finish line: you click install, the container starts, the job is done. That's most of the value, and it's why the category exists.

But it means whatever gaps exist upstream ship straight through to you. If the app has no login system, you have none. If configuring it means editing a file over SSH, that's still how you configure it. If the software breaks when you skip a major version, remembering that is your job.

We treat closing those gaps as the actual work. It takes a different shape for every app:

• VS Code Server ships with no authentication at all. Putting an editor with an integrated terminal on the open internet is a real security problem, and nothing in the upstream software stops you from doing it. We put it behind VCloud Auth with enforced TLS, and handle the WebSocket-capable routing it needs or sessions drop constantly.
• Nextcloud's upgrade path can't skip major versions - one of the most common ways self-managed instances break. We sequence upgrades in order and take a backup first. We also snapshot file data and database together, because backing them up separately is how you get a restore full of orphaned files.
• OpenClaw normally needs shell access to generate a request ID or validate a connection token. Since nobody gets a shell, every one of those operations is a button in the app's menu instead.

Three apps, three different gaps, one consistent answer. The apps aren't the point - the pattern is.

To be fair about where Cloudron already does this: single sign-on is included on every Cloudron plan, so catalog apps that support it get an identity integration without per-app work. The directory server, along with user groups and roles, is a Max-tier feature.

Backup and restore#

Most self-hosted backup failures are not missing backups. They're backups that exist and can't be restored: a database snapshot taken separately from its file storage, an archive missing the key that decrypts it, or a retention window shorter than the time it took to notice the problem. We wrote about the five ways this goes wrong in more detail.

Cloudron backs up well and has got better at it recently. Since 9.0 it can write to multiple destinations, each with its own storage provider and schedule, and 9.1 added a backup verification UI so you can check archive integrity on demand. Multiple backup sites are a Max-tier feature. The tradeoff that remains is that the destination, the schedule, and whether a restore actually works are all yours to own and verify.

On VCloud, cadence is part of the plan rather than a decision: Daily · 7d on Starter, Daily · 14d on Business, Hourly · 30d on Scale. Backups are encrypted, stored in geographically redundant locations, and taken as a consistent set so that a restore produces a working app rather than a pile of mismatched parts. Restore is a core part of the service specifically so you're never trapped - you can pull a point-in-time copy at any time during your subscription.

Monitoring and security#

Cloudron ships monitoring, and any comparison written before February 2026 will tell you otherwise. Cloudron 9.0 rebuilt the dashboard and added "real-time and historical graphs for CPU, memory, disk I/O, and network I/O with selectable timeframes," plus email notifications for a required server reboot, update failures, and low disk space triggered at 90% capacity.

So the difference isn't presence or absence. It's where the metrics point and who they're for. Cloudron's graphs describe the server, for the person operating it. VCloud gives every tenant a live view of CPU, memory, and storage usage alongside uptime for each app, with retained history running from 7 days on Starter to 30 days + alerts on Scale - which is a different question ("is my wiki healthy?" rather than "is the box healthy?") answered for people who don't operate servers.

Security splits less sharply than you might expect, and it's worth being accurate about it. Cloudron updates itself and the apps it manages, and its documentation is explicit that the operating system's automatic security updates are enabled and that "the system is automatic and requires no manual intervention." Routine OS patching is not a chore hanging over you.

What stays yours is the reboot. Cloudron will email you when one is required, and on a single server a reboot is downtime you have to pick a time for - which is the same constraint that shows up in the scaling section above, arriving from a different direction. On VCloud, encryption, backups, and security patching run in the background, so nothing depends on someone remembering to do it, and capacity changes don't need a window. Production access is restricted to authorized engineers behind hardware MFA, all administrative access is logged, and customer data isn't touched without an open, customer-initiated ticket except where strictly necessary to resolve a critical incident.

Domains#

Both platforms let you run apps on a domain you own rather than a vendor subdomain - table stakes, and both clear it.

Worth being specific about what that means on VCloud: you bring your own base domain, and your apps live on subdomains of it, with certificates issued and renewed automatically. It's included on every plan, starting at Starter. There's no separate charge and no tier where your apps are stuck on our hostname.

Catalog#

Cloudron wins on breadth, straightforwardly. Their official store carries far more applications than ours, and there's an active community app gallery on top of it. If the app you need is in their catalog and not ours, that's a real reason to choose them, and it's the reason we hear most often.

Our catalog is smaller because every app is extended before it ships - authentication, operational controls, monitoring, and upgrade handling all built and tested per app. That work takes time, which caps how fast the catalog can grow. It's growing steadily, with new applications shipping regularly, but deliberately: we'd rather add an app properly than list it.

Support and data terms#

Cloudron's forum is one of its genuine strengths - active, technical, and frequently faster than a commercial support queue. But it's a community, and its answer to "my instance is down at 2am" is whoever happens to be awake.

VCloud publishes a response commitment instead: Email · 24h on Starter, Chat · 8h on Business, 24/7 chat · 4h on Scale. Neither model is strictly better. One is a community you participate in; the other is a number someone owes you.

On data: your server means your data terms with Cloudron, full stop. On VCloud, you own your content, we act as data processor under your instruction, and we don't scan file contents or use them for analytics or model training.

What you pay#

Cloudron is free for two apps. Beyond that, Pro and Max run roughly €15-30 and €25-50 per month respectively depending on billing period, both with unlimited apps - plus whatever your server costs. Worth knowing before you compare tiers: user groups and roles, the directory server, multiple backup sites, and VPN-only app access are all Max-tier features, so if you need role-based access control, the relevant comparison is Max rather than Pro.

VCloud Starter is $49 per month, with the first month free on a full Starter environment. Compare app limits honestly while you're here: Starter covers 2 apps and Business 5, and Scale is Unlimited, so a team running a dozen applications is comparing Cloudron's unlimited tiers against VCloud Scale rather than against Starter.

On a spreadsheet, Cloudron wins. We're not going to pretend otherwise.

What the spreadsheet omits is the person. Whoever resizes the server, restores the backup after a failure, tunes PHP and opcache so Nextcloud isn't slow, or SSHs in to edit a config file is doing real work, and it costs something even when no invoice arrives. If your team already has that person and the marginal cost of their time is genuinely near zero, Cloudron is cheaper and better for you. If you'd be hiring, distracting, or becoming that person, the comparison changes.

Choose Cloudron if#

• You want root on the host. We don't offer it to anyone, deliberately, so this is a clean reason rather than a gap we intend to close.
• You already run servers competently and operational time costs you close to nothing.
• You want the cheapest possible infrastructure and are happy trading your own hours for it.
• You need an app in their catalog that isn't in ours.
• You want to choose where backups land, or keep several destinations under your own control.

Choose VCloud if#

• Nobody on your team wants to own server uptime, OS patching, or disk capacity.
• You want single sign-on across every app without configuring an identity integration app by app.
• You want an uptime commitment from a provider rather than owning that outcome yourself.
• You want one bill instead of a license plus separate infrastructure costs.
• You want per-app metrics your whole team can read, not host graphs for whoever administers the box.
• You want apps that arrive finished, not just installed.

Cloudron is a mature, well-built platform, and for the right team it's the right call. We're built on a different premise: that neither the server nor the rough edges of the software running on it should be your problem to solve.

For a shorter, side-by-side version of this, see the VCloud vs Cloudron comparison.

Sources#

All Cloudron details below were checked on 14 September 2026. Cloudron ships frequently - 9.0 in February 2026, 9.2 in May - so these are a record of what was true when we looked rather than a permanent statement.

• Cloudron Forum, "Request for Multi-Hosting Feature Update". Source for the founder's statement that horizontal scaling of single apps is out of scope, posted 3 June 2024, and for new features being deferred until after the Cloudron 8 and 9 releases.
• Cloudron Docs, "Packaging Cheat Sheet", section "Memory limit". Source for the hundreds-not-thousands concurrency guidance. Note this is guidance addressed to app packagers, alongside the 256MB default memory limit.
• Cloudron Forum, "Scaling / High Availability Cloudron Setup". Source for downtime on resize and reboot, and for the multi-node request. The most recent exchange is a request and a reply posted the same day, 2 July 2026, both from community members rather than Cloudron staff.
• Cloudron Blog, "Cloudron 9", 2 February 2026. Source for the built-in CPU, memory, disk I/O and network I/O graphs, the 90% low-disk notification, and multiple backup destinations.
• Cloudron Blog, "Cloudron 9.1". Source for the backup verification UI.
• Cloudron Blog, "Cloudron 9.2", 19 May 2026. Source for the release cadence noted above.
• Cloudron Docs, "Security". Source for automatic operating-system security updates being enabled by default.
• Cloudron pricing page, cloudron.io/pricing.html, linked here. Source for the free two-app tier, the Pro and Max price ranges, and the Max-tier gating of user groups and roles, the directory server, multiple backup sites, and VPN-only app access. Prices are quoted as a range because they vary by billing period; check the page for the current figure that applies to you.
• Cloudron app store and the community app gallery. Neither publishes a headline count, so we describe the catalog as larger than ours rather than quoting a number.