Skip to main content
Speckle Cloud is Speckle’s preferred and recommended deployment for most organisations. The primary deployment question is operational: who should operate Speckle? Speckle Cloud lets Speckle operate, maintain, and support a known, current product environment. A customer-operated deployment gives your organisation control over the infrastructure and when it changes, while transferring that operational responsibility to your team. Both are valid technical models; the right boundary depends on whether operating Speckle infrastructure creates value for your organisation.

Who Should Operate Speckle?

Choose the responsibility boundary before choosing infrastructure:
  • Speckle Cloud: choose Cloud when you want Speckle to operate Speckle. This is the recommended model for most organisations.
  • Speckle Enterprise Server: choose this when you need the commercial Enterprise product and support relationship, but a concrete requirement calls for deployment in customer-controlled infrastructure.
  • Public open-source server: choose this when owning and operating the open-source platform is itself an intentional part of your architecture.
Determine the required product and operational owner first. Then establish whether regulatory, contractual, territorial, security, or infrastructure constraints affect which deployment can satisfy that choice. Data residency is a requirement to satisfy within the deployment decision, not necessarily the deployment decision itself. Speckle Cloud provides data residency controls on the Enterprise plan; a preference or requirement for a particular geography does not automatically require customer-controlled infrastructure.

Speckle Cloud: Speckle Operates Speckle

Speckle Cloud is the deployment Speckle operates directly and is delivered through hosted workspace plans. It gives Speckle the greatest leverage to keep the environment current and provide effective, up-to-date support because Speckle controls and understands the deployed product environment. In Speckle Cloud, Speckle can take responsibility for:
  • The deployed product version and supporting infrastructure
  • Upgrades and migrations
  • Managed services included with your plan
  • Monitoring, observability, and scaling
  • Backups and recovery
  • Availability and incident response for the operated environment
  • Compatibility with Speckle-operated integrations
  • Deploying fixes and continuous product improvements
  • Diagnosing support cases against a known, current environment
Speckle Cloud also includes the parts of the product Speckle operates rather than distributes. Depending on your plan, these can include automatic translation of supported files without running the source application, Speckle-operated project and data-platform integrations, Workspaces as the organisational model, Speckle Intelligence, and Automate execution. Managed Services and Product Surface describes each of these boundaries and how they differ in a customer-operated deployment. Your organisation can use and extend Speckle without also taking responsibility for running the server, databases, object storage, background processing, and deployment tooling. Speckle Cloud remains extensible through GraphQL, REST, and webhooks, so choosing an operated platform does not prevent you from building applications, dashboards, and integrations on top of it. This is the operational basis for the Cloud recommendation: if running Speckle infrastructure does not create value for your organisation, transferring that work to Speckle leaves your team free to concentrate on using and extending the product. Support and uptime commitments still depend on your plan and contract; the responsibility boundary described here does not create an additional SLA.

When Speckle Enterprise Server Is Appropriate

Choose Speckle Enterprise Server when your organisation needs the commercial Enterprise product and support relationship, but a concrete requirement prevents the normal use of Speckle Cloud. Examples can include regulatory or contractual constraints, mandated security architecture, territorial requirements, infrastructure ownership, or organisational deployment policy. These requirements are reasons to evaluate an alternative, not automatic reasons to operate the public open-source server. Where a supported customer-infrastructure deployment meets the requirement, Speckle Enterprise Server provides commercially licensed Enterprise software for deployment on your infrastructure. See Enterprise License for the current prerequisites, deployable components, and configuration. Speckle Enterprise Server is not simply Speckle Cloud moved onto your Kubernetes cluster. Your organisation operates the infrastructure and data plane, controls the deployed versions, and coordinates upgrades and deployment-specific operations. Speckle provides the licensed software and support described by your commercial agreement. The resulting responsibility boundary depends on that agreement and the deployment guide. Some capabilities can retain external or Speckle-operated dependencies even when Enterprise software is deployed in customer infrastructure; do not assume that every managed service is included or moves into your environment.

When Open-Source Self-Hosting Is Appropriate

Open-source self-hosting is not an evaluation edition of Speckle, nor is it intrinsically unsuitable for production. It is a rational choice when owning and operating the infrastructure is itself valuable to your organisation and you are prepared to own that operational boundary. Speckle is open source, and the core platform remains available to run, study, extend, and contribute to. Self-hosting provides meaningful control over:
  • The infrastructure and data plane
  • When and how versions, upgrades, and migrations are adopted
  • Deployment-specific security and network architecture
  • Changes and extensions to the open-source platform
Public open-source self-hosting is an intentional operating model, not simply “Speckle for free.” There is no Speckle licensing fee for the public server, but the organisation running it owns the infrastructure cost and operational work. It is also useful for development, experimentation, contributing to Speckle, and specialised deployments. If operating Speckle infrastructure does not create value for your organisation, we recommend Speckle Cloud.

Shared Open-Source Foundation

All Speckle deployments build on the same open-source core platform:
  • Projects, models, and versioning
  • GraphQL and REST APIs and the data transport used by connectors
  • The web application and 3D viewer
Commercial offerings add operated or licensed layers to this core; they do not change the underlying model and version graph into a different product. The open-source server is the distributed form of the core, while Speckle Cloud combines that core with a workspace model and managed services. Feature parity is not the goal. Hosted and Enterprise offerings can have product capabilities and operated services beyond the public distribution. The open-source server remains the stable, distributable foundation on which the ecosystem and hosted product build.

Operational Responsibility and Support

Running a production Speckle server means owning its operating lifecycle. For an open-source self-hosted deployment, your organisation is responsible for:
  • Infrastructure provisioning and deployment
  • Upgrades and migrations
  • Monitoring, scaling, and availability
  • Backups and recovery
  • Security patching
  • Database and object storage operation
  • Background processing and throughput
  • Incident response and deployment-specific diagnosis
Documentation, GitHub issues, and the community remain valuable sources of help for open-source users. However, a self-hosted environment also introduces infrastructure, configuration, and version variables outside Speckle’s control. Speckle Cloud gives Speckle the greatest ability to maintain, observe, diagnose, and support the complete environment because Speckle operates it. For Speckle Enterprise Server, operational responsibilities remain with the organisation running the infrastructure, while commercial support and any commitments are defined by contract. This page does not add to those commitments.

Managed Services and Product Surface

Differences in the interface and product surface reflect the managed layer and workspace experience, not a separate lightweight or viewer-only core. Speckle Cloud includes Speckle-operated services where offered by the selected plan, such as hosted ingestion and processing, integrations, and execution environments. The public open-source distribution does not include this managed service layer. You can use its APIs, SDKs, and webhooks to build equivalent workflows, but your organisation implements and operates the execution, orchestration, and integration infrastructure.

Workspaces and Speckle Intelligence

Workspaces provide the organisational model in which Speckle Cloud manages projects, members, settings, plan controls, and workspace-level product capabilities. They belong to the hosted and licensed product layer: a licensed Speckle Enterprise Server deployment can also enable Workspaces, while deploying the public open-source server alone does not provide them. Speckle Intelligence is available on Speckle Cloud according to the workspace plan, with no additional infrastructure for your organisation to operate. An Enterprise agreement that includes Intelligence can provide access to the separate Enterprise Intelligence deployment, which requires additional customer-operated infrastructure and documented dependencies. Intelligence is outside the public open-source distribution.

Managed Cloud and Data-Platform Integrations

Speckle operates project integrations such as Autodesk Forma Data Management (ACC) and Bentley ProjectWise, and data-platform integrations such as Databricks, Snowflake, and Microsoft Fabric. Availability in Speckle Cloud or a licensed Enterprise deployment depends on the plan, agreement, and supported deployment boundary. These are Speckle-operated services rather than parts of the public open-source distribution. The open-source server provides the APIs and webhooks needed to build integrations, but your organisation implements and operates them.

Automatic File Translation

On Speckle Cloud, supported files can be submitted by drag and drop or through the programmatic file-upload workflow, then parsed and translated into a Speckle model without running the source application. The extended formats cover files from applications and formats such as Revit, Rhino, Civil 3D, Plant 3D, DWG, Tekla, SolidWorks, and others, depending on the source file and currently supported format list. See Direct Uploads for the current formats and limitations. The public open-source server includes the file-ingestion workflow and an IFC importer. It does not include Speckle’s extended automatic file translators. Extended file translation can also be available with Speckle Enterprise Server, but it requires licensed components and supporting infrastructure. It is not included by deploying the public open-source server alone. See Supporting additional file types in Direct Uploads. Capabilities beyond the public distribution are not necessarily Cloud-only. Some are available for Speckle Enterprise Server under a commercial license. For example, Speckle Automate is not part of the public open-source server. Its custom-code Docker runtime and execution engine are separate licensed components and are not included with the open-source server distribution. An OSS deployment can use webhooks to trigger code on external compute that your organisation operates, but that does not add the Automate runtime or execution engine to the server. An Enterprise agreement that includes Automate can provide access to the separate Enterprise Automate deployment, which requires additional customer-operated infrastructure. Other components can have external dependencies or different deployment boundaries. Check the current Enterprise deployment guides and your agreement rather than assuming that every managed capability has the same boundary.

Licensing and Cost

Speckle Cloud plans are subscriptions at the workspace level. Limits and commercial terms depend on the plan; see Billing and speckle.systems/pricing. Speckle Enterprise Server requires a commercial license for the Enterprise software and package registry access. Entitlements and support are defined by the commercial agreement. The public open-source server has no Speckle licensing fee. Its total cost still includes the infrastructure and engineering time required to deploy, upgrade, monitor, secure, scale, back up, recover, and support the environment. In return, your organisation controls when and how the deployment changes. That control is a real benefit when you want it; it is also the responsibility Speckle can no longer exercise automatically on your behalf.

Comparison by Responsibility Boundary

This comparison describes ownership rather than attempting to list every feature.

Our Approach

Speckle’s core stays open so people and organisations can inspect it, build on it, contribute to it, and run it themselves. We intend to preserve that choice. For most organisations, the recommended choice is Speckle Cloud because using Speckle should not require becoming the operator of Speckle server infrastructure. Enterprise Server provides a supported path where concrete requirements make customer-controlled infrastructure necessary. Open-source self-hosting remains a legitimate choice when owning that infrastructure and operating responsibility is itself the objective.
Last modified on August 16, 2026