Skip to main content
This guide is for IT administrators and workspace admins managing connectors across an organization. If you are a regular user, see Installing Connectors — your connector prompts you when an update is available.
The hosted Speckle platform is continuously deployed — the server updates most days. Connectors release roughly monthly and are built and tested against it. Keeping them current is routine maintenance rather than a series of upgrade decisions. Backwards compatibility is maintained and API deprecations are announced in advance, so an older connector does not stop working overnight. But the further your estate sits from the current release, the more you depend on those commitments rather than on a tested pairing — and occasionally a platform change does require a connector from the same period. For installation mechanics, see the IT Setup Guide and Manual Connector Installation.

​
Our recommendation

Stay on the current release

The current release is the supported position, and the one the rest of this documentation describes. Treat connector updates as routine maintenance, not as a project.
Three rules make that workable in a managed estate:
  1. Let updates flow by default. Approve connector releases as a standing item rather than assessing each one. Most releases are fixes and host application support, and they reach you sooner and in smaller pieces this way.
  2. Hold one version at a time across the estate. Roll forward together. Per-team drift is what makes support slow and upgrades risky.
  3. Reserve real validation for the rare structural change. Most releases do not need a fresh test cycle. The baselines below mark the handful that changed how data is published or configured — those are worth a pilot.
If your change process cannot approve releases as they ship, quarterly is the minimum cadence we recommend. Beyond a quarter, you accumulate capability your workspace plan covers but your connectors cannot deliver, and each upgrade becomes a larger single change instead of a routine one.
If you need a trigger to get current, there is one now. Autodesk is migrating Revit 2025 and 2026 to the .NET 10 runtime, which many organizations are already validating add-ins against. See Runtime alignment.

​
Requested changes arrive with the connector

Much of what Speckle ships is a response to what users report. Where that change is server-side — the web app, viewer, dashboards — it reaches your teams automatically. Where it is in the connector, it reaches them only when you deploy a new connector version. That creates a gap which is easy to miss from an IT perspective. Someone in your organization reports a problem or asks for a capability, the change is released and announced, and the person who raised it never receives it. From where they sit, the request went unanswered. The gap is widest for the requests that matter most. Broad features get noticed eventually through release notes or colleagues. But a change made in response to specific reported nuance — how a particular element type is extracted, which properties are carried through, how a host application behaves in one team’s workflow — is often only visible to the person who described the problem in the first place. If they are running an older connector, nobody confirms the fix landed, and the original limitation persists inside your organization as settled fact.
When someone in your organization raises a request or a bug report and it is released, treat that as an update trigger rather than waiting for your next scheduled window. Tell the person who raised it which release contains the change, so they can confirm it resolves their case.

​
Connector baselines

These are the releases that changed something structural. They are cumulative — landing on one gives you everything in the baselines above it — so they describe how far behind an estate is, rather than a menu to choose from. Aim for the current release; use the intermediate rungs only to understand what a constrained estate is missing.
When you do move, move to the current release rather than an intermediate rung. The validation effort is the same either way, and you arrive further forward.
Analytics features depend on the managed deployment baseline. Intelligence dashboards, Data Validation and Power BI rely on consistent object properties that older connectors do not publish. A workspace can be fully licensed for these and still return thin results if the connectors feeding it are older.

​
Runtime alignment

The managed deployment baseline is also where Speckle connectors moved to the .NET 10 runtime. That matters less for what Speckle does than for when you schedule the work. Microsoft ends support for .NET 8 in November 2026, and Autodesk is migrating Revit 2025 and 2026 to .NET 10 to follow the long-term support line. Revit 2027 ships on .NET 10 already. Most add-ins continue to work across that migration, but add-ins with native code or third-party dependencies may need recompilation. If your organization is already planning add-in validation for the Revit .NET 10 migration, bring your connector baseline into the same cycle. You test once rather than twice, and you finish on a connector built against the runtime your host applications are moving to.
This is a scheduling argument, not a compatibility warning. Speckle connectors below the managed deployment baseline are not expected to stop working because of the Revit runtime migration. The point is that the validation effort overlaps, so doing both together is cheaper than doing them separately.

​
Constraints that override the recommendation

Two situations set your baseline for you.
  • Legacy (v2) connectors. Moving off these is a migration to a different data model, not a version update. Check your workflow inventory first — some connectors are legacy-only. See Migrate from legacy connectors.
  • Revit 2022. Support for that host ended with the 2027 connectors, so those users cannot move past 3.21. The Revit upgrade is the blocking dependency, not the connector.

​
Host application support

Rhino and Grasshopper ship in a single installer, so updating one updates both. Connectors are Windows only.

​
Reading version numbers

From June 2026, all Speckle products — connectors, server, SDKs and viewer — use calendar versioning in the format Year.Month.Patch. 2026.6.0 is the first release published in June 2026; later releases that month increment the patch number.

Same year and month means full compatibility

Any Speckle products sharing a Year and Month are fully compatible with each other. This is the quickest way to check whether your connectors, server and SDK tooling are aligned.
Before this change, products released around the same time carried unrelated numbers — server 3.0.40, Python SDK 3.2.8, connectors 3.24.1 — with nothing to indicate they belonged together. Calendar versioning makes that legible at a glance. See Moving Speckle to calendar based versioning.
A calendar version such as 2026.6.0 is newer than 3.24.1, not older. If you maintain pinned version ranges, allowlists, or automated version comparisons, update them for the change in scheme.
The change affects numbering only. Release cadence, backwards compatibility commitments, and the way API deprecations are announced are unchanged.

​
Move to a new baseline

Connectors support both single-user and all-user installation, so the deployment model should not be what sets your update pace. Configuration follows the same pattern: settings can be written to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE, or supplied as environment variables. See Connector Configuration.
Running the .exe installer as an administrator does not produce an all-user installation. It installs the connector into the administrator’s profile, where the intended user cannot reach it. For a machine-wide deployment, use the manual ZIP route.
Because a single-user update needs no elevation, it can be delivered in user context through your endpoint management tooling or a logon script — useful for pilot groups, where you can scope to a handful of users without a separate package or image change.
1

Pick the baseline you will commit to

Start from the current release and work down only if a constraint forces it. You should end with a single target version for the whole estate.
2

Pilot with one team

Deploy to a small group covering your main workflows. Publish and load a representative model in each host application, including a large or federated one.
3

Verify published data

Open the published models in the web app and confirm geometry and properties appear as expected. Use the Report button in the connector to check for skipped objects.
4

Deploy and record the baseline

Roll out the validated version and record it, so your next update decision starts from a known position.
Crossing the managed deployment baseline changes how data is serialised and uploaded. Include large and federated models in that pilot rather than a simple test file.

​
FAQ

Ideally yes — approve them as a standing item and let them flow. If that is not possible, consolidate into a quarterly update rather than assessing each release individually.
More than a quarter. At that point you are missing capability your workspace plan already covers, and a future upgrade becomes a larger single change rather than a routine one.
Check the connector version first. Fixes to connector behaviour only reach users who have updated, so a fix released last month is not present in a connector deployed last year. Compare the release the fix shipped in against the version your estate is running before reopening the report.
Anything server-side — the web app, 3D viewer, dashboards and workspace administration — updates automatically. Anything that affects how data is extracted from or written back to a host application ships in the connector and requires an update.
Compare the year and month in the version numbers. Speckle products sharing a Year.Month are fully compatible. Older connectors are still supported under our backwards compatibility commitments, but matching year and month is the position we test against.
No — and you do not need to work out which release added it. Baselines are cumulative, so landing on a version gives you everything up to it. Choose the highest rung your change process can support.
It can. Conflicts between Speckle and third-party add-ins are addressed as they are reported, so the current release is the safest position for estates running a rich add-in set. If you hit a conflict, report it in the Community Forum with your host application version, connector version, and log file — fixes are usually released quickly.
Yes. Set SPECKLE_IS_UPDATE_NOTIFICATION_DISABLED as a registry value or environment variable — see Connector Configuration. Use this when users are not permitted to run installers themselves.
Yes, from the managed deployment baseline onward. Use the ZIP-based manual installation route where executable installers are restricted, and pre-configure global settings such as the default server URL via registry values — see Connector Configuration.
Yes, via the manual ZIP route — target %ProgramData% or %ProgramFiles% instead of %AppData%. Note that running the .exe installer as an administrator does not achieve this; it installs into the administrator’s profile instead.
Not for a single-user install, which is why pilot rollouts can be delivered in user context without a machine-level package. An all-user install needs the usual rights for writing to %ProgramData% or %ProgramFiles%.
Users can see their connector version in the connector UI. For a fleet-wide view, use your software inventory or endpoint management tooling — Speckle does not currently report connector versions in use across a workspace.
It remains valid and viewable. Your baseline affects what users can do going forward, not what already exists. The exception is legacy (v2) data, which uses a different data model — see Migrate from legacy connectors.
Connectors uninstall like any other Windows application, and previous versions remain available from releases.speckle.systems. Report the problem in the Community Forum or to [email protected] with your host application version, connector version, and log file.
Last modified on July 31, 2026