> ## Documentation Index
> Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> These docs contain multiple Speckle product experiences. For Speckle 2026.9, prefer /next/ pages for the topics and changes they cover. The navigation label Current does not override this version-specific precedence.
> Coverage under /next/ is incremental. Use Current documentation for unchanged topics and when a /next/ page says coverage is unavailable or explicitly refers you to Current. Do not infer a feature was removed from a missing page.
> Read the page-specific documentation status, applicability, affected guidance and replacement links in agent-only content. Impacted, changed and superseded apply only to the stated scope; they do not mean the entire feature is deprecated. Historical connector guides apply only to the legacy connector described.
> Match guidance to the customer's deployment version, model data format and connector. Respect plan, permission and compatibility restrictions. If an unknown version or data format changes the answer, ask a focused clarification; do not infer deployment version from the date alone.

# Choosing a Speckle Deployment

> Choose between Speckle Cloud, Speckle Enterprise Server, and the open-source server based on requirements and operational responsibility.

**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](/workspaces/data-residency) 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](/workspaces/introduction) as the organisational model, [Speckle
Intelligence](/analytics/intelligence-dashboards), and Automate execution. [Managed Services and
Product Surface](#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](/developers/api/graphql), [REST](/developers/api/rest), and
[webhooks](/developers/api/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](/developers/server/deployment/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](/workspaces/introduction) 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](/analytics/intelligence-dashboards) 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](/developers/server/deployment/enterprise-license-intelligence), 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)](/connectors/cloud-integrations/acc) and [Bentley
ProjectWise](/connectors/cloud-integrations/projectwise), and data-platform integrations such as
[Databricks](/connectors/cloud-integrations/databricks),
[Snowflake](/connectors/cloud-integrations/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](/developers/api/guides/file-uploads), 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](/connectors/direct-uploads/introduction) 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 [File imports (conversion runner)](/developers/server/deployment/enterprise-license#file-imports-conversion-runner).

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](/developers/automate/introduction) 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](/developers/server/deployment/enterprise-license-automate), 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](/workspaces/billing) and
[speckle.systems/pricing](https://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.

| Boundary | Speckle Cloud | Speckle Enterprise Server | Open-source self-hosted |
| - | - | - | - |
| **Appropriate use** | You want Speckle to operate and support a known, current environment | You need the Enterprise product and support relationship, but a concrete requirement calls for customer-controlled infrastructure | Operating and extending the open-source core creates value for your organisation |
| **Infrastructure** | Speckle operates the server, databases, object storage, and background processing | Operated by your organisation | Operated by your organisation |
| **Deployment, upgrades, and migrations** | Speckle deploys, upgrades, and migrates the environment; there is no upgrade for you to schedule | Your organisation deploys and upgrades the licensed software | Your organisation deploys and upgrades the public distribution |
| **Monitoring, scaling, availability, and incident response** | Speckle monitors, scales, and responds to incidents in the Cloud environment | Your organisation operates the environment; commercial terms define Speckle support | Your organisation owns the environment; documentation and community support are available |
| **Backups and recovery** | Speckle operates backups and recovery for the Cloud environment | Your organisation | Your organisation |
| **Managed services** | Speckle operates ingestion, processing, integration, and execution services where included in your plan | Deployable components and dependencies vary by license and deployment guide | Not included; you build or integrate and operate additional services |
| **Workspaces** | Included as the organisational model for projects, members, settings, and plan controls | Available with the Enterprise license | Not included |
| **Speckle Intelligence** | Available according to your plan, with no additional infrastructure to operate | Requires the applicable license, deployment, and supporting infrastructure | Not included |
| **Automate execution** | Custom-code Docker runtime and execution engine where included in your plan | Requires an Enterprise license that includes Automate and additional infrastructure | Not included; use webhooks with external compute that you operate |
| **Managed integrations** | Speckle operates the project and data-platform integrations where offered | Availability and deployment boundary vary by license and integration | Not included; APIs and webhooks are available for you to build and operate integrations |
| **Automatic file translation** | IFC and the supported extended format set, without running the source application | Extended formats require the applicable license and supporting infrastructure | IFC only |
| **Product cadence** | Improvements and fixes are delivered continuously, with no customer upgrade cycle | Your organisation coordinates supported versions and upgrades | Your organisation chooses when to adopt open-source releases and perform upgrades |
| **Infrastructure control** | Speckle controls the service infrastructure | Your organisation controls its deployment infrastructure | Your organisation controls its deployment infrastructure and can modify the open-source code |
| **Licensing** | Workspace subscription covering the operated environment | Commercial Enterprise license | No Speckle license fee for the public server; infrastructure and operations remain your cost |

## 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.

## Related Documentation

* [Hosting Your Own Speckle Server](/developers/server/introduction)
* [Self-Hosted Deployment Options](/developers/server/deployment-options)
* [Enterprise License](/developers/server/deployment/enterprise-license)
* [Enterprise Automate Deployment](/developers/server/deployment/enterprise-license-automate)
* [Enterprise Intelligence Deployment](/developers/server/deployment/enterprise-license-intelligence)
* [Cloud Integrations](/connectors/overview#cloud-integrations)
* [Direct Uploads](/connectors/direct-uploads/introduction)
* [Programmatic File Uploads](/developers/api/guides/file-uploads)
* [Billing](/workspaces/billing)
* [Data Residency](/workspaces/data-residency)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.