Skip to main content

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.

Use this page as a central governance hub for Speckle workspace operations. It helps technical leads, IT, security, and procurement teams align on controls, ownership, and rollout decisions.

​
Who this is for

  • Workspace admins defining guardrails for delivery teams
  • IT and security teams reviewing enterprise controls
  • Procurement and compliance teams reviewing assurance evidence
  • Project leads setting sharing policies for external collaboration

​
Governance scope at a glance

This page consolidates:
  • Plan-linked governance capability boundaries
  • Identity and access management controls
  • Data location and deployment model choices
  • Secure sharing controls for links and tokens
  • Compliance assurance context, including SOC 2

​
Plan and control boundaries

Speckle governance capabilities vary by plan. Use these summaries to choose a fit before implementation detail.

​
Explore

  • Best for evaluation and lightweight proof-of-concept use
  • Basic workspace controls
  • Not intended for enterprise identity/compliance requirements

​
Team

  • Best for active project delivery with broader collaboration
  • Higher operational limits
  • Suitable when governance requirements are moderate and contractual controls are not required

​
Enterprise

  • Best for regulated and scaled production environments
  • Advanced governance controls such as SSO, SCIM, and data residency
  • Deployment and commercial options that support stronger assurance workflows
For plan details and limits, see Billing and New Plans FAQ.

​
Identity and access governance

Manage identity and authorization at workspace level first, then refine at project level where needed.

​
Data governance and deployment choices

For regulated environments, combine workspace controls with hosting and regional requirements.

​
Secure sharing governance model

Speckle supports tokenized sharing for models, presentations, and dashboards. Treat these links as governed access paths, not one-off convenience URLs. Minimum recommended policy:
  • Apply expiration dates to all external links by default
  • Require passwords for sensitive or externally distributed links
  • Require meaningful labels for issued links (owner, purpose, expiry intent)
  • Revoke links immediately when access purpose ends
  • Review active tokens on a fixed cadence (for example weekly or monthly)
Implementation guides:

​
SOC 2 and compliance context

Speckle supports enterprise governance programs through platform controls and deployment options. Speckle’s SOC 2 attestation is current and covers the current reporting year. SOC 2 documentation is available to Enterprise prospect customers as part of the security and procurement review process. Request access via [email protected].

​
Common operating patterns

​
Pattern 1: Internal delivery workspace

  • Primary focus: project throughput with controlled team access
  • Typical controls: role governance, invitation policy, periodic token review
  • Typical plans: Team or Enterprise

​
Pattern 2: Client-facing collaboration workspace

  • Primary focus: frequent external sharing and presentation
  • Typical controls: mandatory link expiry, password-protected external links, strict token revocation cadence
  • Typical plans: Team or Enterprise

​
Pattern 3: Regulated enterprise workspace

  • Primary focus: identity integration, compliance evidence, data location
  • Typical controls: SSO, SCIM, residency strategy, formal access governance
  • Typical plans: Enterprise

​
Governance rollout checklist

Use this checklist when setting up a new governed workspace:
  1. Confirm required plan and commercial terms.
  2. Configure workspace roles and invitation policy.
  3. Set up SSO and SCIM where required.
  4. Confirm data residency and hosting model requirements.
  5. Define secure sharing rules (expiry, password, revocation cadence).
  6. Assign token review ownership and review frequency.
  7. Record compliance evidence requirements (for example SOC 2 package request).

​
FAQ

​
Commercial model and plans

Both.Speckle core platform is open source, including self-hosted deployment options. Commercial offerings add hosted operations, enterprise controls, and licensed capabilities for organizations that need managed service, stronger contractual assurances, or expanded governance features.
Open-source self-hosting gives you direct infrastructure control and implementation responsibility.Commercial offerings can provide additional governance capabilities and operating models (for example managed hosting, enterprise identity features, and licensing terms) depending on your plan and deployment type.
Yes. This is a common path.Teams often begin with open-source self-hosted or lightweight workspace use, then move to Team or Enterprise plans as governance, procurement, compliance, or scale requirements become stricter.
Choose Team when you need collaborative delivery controls but do not require enterprise identity or compliance-heavy operating constraints.Choose Enterprise when you need controls such as SSO, SCIM, stronger data governance options, and formal security or procurement assurance workflows.
No.Plan limits cover operational capacity (for example users, projects, or usage thresholds), while governance controls cover how identity, access, data location, and external sharing are managed and audited.

​
ACC integration governance

In ACC integration workflows, Speckle reads source files from ACC and creates synced models in Speckle for viewing, coordination, and downstream workflows.The ACC integration is documented as read-only from Speckle to ACC, so Speckle does not write changes back to your ACC source files. See Autodesk Construction Cloud.
No. ACC integration is read-only from Speckle to ACC.Speckle syncs and processes data for Speckle-side use, but does not modify the original ACC files.
ACC syncs run using the account that set up the connection.In practice, access is limited to what that account is already allowed to view in ACC. To reduce risk, use a dedicated least-privilege ACC account for production syncs.

​
Security and compliance controls

Encrypted sharing is supported through secure links and token controls.Public documentation describes HTTPS/TLS transport protection and secure link controls (including expiry, optional password, and revocation).If you need formal attestations for encryption at rest, key management, or control implementation details, request the security package via [email protected].
This depends on deployment model.Speckle Cloud provides managed hosting with plan-based governance controls. If you need stricter boundary control over infrastructure and operations, use Enterprise self-hosted deployment and define those controls in your own environment. See Cloud vs self-hosted Speckle.
Yes, on Enterprise plans.Workspace-level region controls are available, and additional regional or project-level options can be discussed for stricter residency needs. See Data residency.
Speckle’s SOC 2 attestation is current for the reporting year.SOC 2 documentation is available during Enterprise security and procurement review. Request access via [email protected].

​
Sharing, audit, and operational resilience

Yes.Public exposure is controlled through project visibility. Keep projects Private or Workspace if they should not be publicly visible.Anonymous access can be controlled through share tokens. In Project settings -> Tokens, limit token use, set expiry and optional passwords, and revoke tokens when they are no longer needed.Regular project links still follow project visibility and role permissions. Share tokens provide scoped read-only access for specific sharing workflows. See Share your models and Configuration.
Access to shared data is governed by project visibility, collaborator roles, and share token controls.Administrators can review and manage issued tokens in Project settings -> Tokens, including revocation when access is no longer needed.Audit and evidence requirements remain plan and contract scoped. For formal compliance reviews, define required evidence up front and confirm delivery expectations during Enterprise commercial and security review via [email protected].
Backup and disaster recovery responsibility depends on deployment model.For self-hosted deployments, your team owns backup policy, restore testing, and recovery operations. For Speckle-hosted environments, operational reliability is managed by Speckle, with support and SLA commitments defined by plan and commercial agreement.
Speckle Cloud is internet-hosted and is not an air-gapped deployment model.An air-gapped Speckle deployment is possible, but it is typically bespoke and more complex to operate.In practice, this usually aligns with self-hosted, open-source-core style deployments and a reduced set of cloud-dependent integrations. Backup, recovery, and operational controls are then implemented under your internal standards.Speckle has also been deployed in highly security-sensitive environments.
RPO and RTO commitments are not presented as one universal public value across all deployment models and plans.If you need formal recovery targets for procurement or compliance, confirm them in your Enterprise commercial and security review via [email protected].

​
Implementation baseline

At minimum, define and approve:
  1. Backup frequency and retention policy.
  2. Restore testing cadence and acceptance criteria.
  3. Named recovery owners and escalation path.
  4. Target RPO and RTO aligned to business impact.
  5. Evidence artifacts required for audits.
  6. A documented failover and communication runbook.
Start with this baseline:
  1. Confirm plan and contractual governance requirements.
  2. Configure roles, invitation policy, and ownership.
  3. Enable SSO, then SCIM, if centralized identity lifecycle is required.
  4. Confirm data residency and hosting model.
  5. Enforce external sharing controls (expiry, password, token review and revocation cadence).
  6. Record compliance evidence contacts and review cadence.
Last modified on May 5, 2026