# speckle-server: the monorepo behind a data hub for building design > The Speckle server repository holds seven packages of the Speckle v2 web stack in one Yarn workspace, from the Node server and the Nuxt frontend to the three.js viewer and the service packages that generate previews, fire webhooks and import files. What makes it interesting is that the connectors for Revit, Blender, SketchUp and the rest live in separate repositories, so this is the hub rather than the whole ecosystem. **specklesystems/speckle-server** — The Speckle Server, Frontend, 3D Viewer, & other JS utilities. - Repository: https://github.com/specklesystems/speckle-server - Website: https://speckle.systems - Stars: 855 · Forks: 254 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/specklesystems-speckle-server ## What the repository is This monorepo is the home of the Speckle v2 web packages, and the README describes the project as the first AEC data hub that connects with your favourite AEC tools. The motivation it gives is a fragmented industry where communication, creative workflows and the exchange of data are hindered by siloed software and processes. The description covers the server, the frontend, the 3D viewer and other JavaScript utilities. The project is TypeScript, the licence field carries a custom classification that GitHub cannot label, and the homepage is speckle.systems with a community forum at speckle.community and developer documentation at docs.speckle.systems. ## Seven packages in one workspace The repo structure section lists the packages and each has a clear job. packages/server is the Server, a Node.js app. packages/frontend-2 is the Frontend, a Nuxt and Vue app. packages/viewer is a three.js extension that lets you display 3D data and it is published to npm as @speckle/viewer. packages/objectloader is a small JavaScript utility class that helps you stream an object and all its sub-components from the Speckle Server API, also published to npm as @speckle/objectloader. Then there are three services: packages/preview-service generates object previews for Speckle objects headlessly and is meant to be called on by the server, packages/webhook-service makes external webhook calls, and packages/fileimport-service parses and imports files. ## The connectors live elsewhere, which is the point The Other repos section is arguably the more important list. There is speckle-sharp-connectors with the .NET connectors and desktop UI, and speckle-sharp-sdk with the .NET SDK, tests and objects. There is specklepy for Python, and connectors for SketchUp, Excel, Unity, Blender, Unreal Engine, QGIS and PowerBI, plus more connectors and tooling in the organisation. So the repository you are looking at is the hub and the server side, not the interoperability layer itself. That split has a practical consequence: the data model that every connector depends on is defined by the SDK repositories and the server, so a change to the object model is a coordinated change across several repositories rather than a patch in one. ## Building the monorepo The development section is a TL;DR with the essentials. The project uses yarn and its workspaces functionality to manage the monorepo, and you should be using Node version 22. The setup is four commands. ```bash corepack enable yarn yarn build:public yarn build ``` After that you can use the scripts in the individual packages or run them all in dev mode with yarn dev. The package manifest shows the shape of the build orchestration, and it is worth a look because it explains why there is a separate public build step. The build script runs yarn workspaces foreach in parallel with a topological order, so packages build in dependency order. build:public first ensures the tailwind dependencies are present, then runs the frontend postinstall, and only then builds the non-private packages. The package manager is pinned to yarn 4.17.0, the workspaces glob is packages/*, and the engine requirement is Node ^22.17.1. ## Docker for dependencies, and a Kind cluster for the rest The scripts give you two ways to run the infrastructure. The dev:docker family uses docker compose against docker-compose-deps.yml, with up, down, a variant that also removes volumes, and a restart. Then there is a dev:kind family that applies a cluster configuration with ctlptl, for a local Kubernetes cluster, and a Tilt-based option that runs a Helm deployment against a kind cluster named kind-speckle-server, with the up and down variants both pointing at a Tiltfile. Having both paths means a developer can run the same deployment topology in CI and on a laptop, and the repository carries separate compose files for dependencies, for the ingress and for the main Speckle stack, plus one for tests. The helm readme is generated by a script in utils, which is the kind of detail that says the deployment chart is treated as part of the contract rather than as an afterthought. ## The editor setup is part of the developer experience There is a whole section on the IDE, and it is unusual for a README to go into this much detail. The suggested IDE is VSCode because the repository has special configs to improve the developer experience there, with auto-format and auto-lint and recommended extensions. The repository relies on VSCode multi-root workspaces, so for the best experience and proper formatting and linting you should open the project using the workspace.code-workspace file rather than just opening the folder. For TypeScript support the project relies on the Volar extension and not Vetur, and because the default Volar setup is resource intensive with both standard TypeScript and Vue language server instances running, they use Volar Take Over Mode, which means ensuring Volar is enabled and the built-in TypeScript and JavaScript Language Features extension is disabled for the workspace. There is also a .zed directory and a mise.toml, so an alternative editor and a tool version manager are both anticipated. ## Where speckle-server is the wrong choice Four limits apply. It is a monorepo, so a contributor who only wants the three.js viewer or the objectloader has to take the whole workspace and its build, and the topological parallel build is not free. The operational surface is wide: a Node server, a Nuxt frontend, background services for previews, webhooks and file imports, a database and the infrastructure to run them, which is why the README routes all deployment detail to a separate documentation site rather than trying to summarise it. The viewer and the objectloader are genuinely reusable on their own and are published to npm, so a project that only needs to display Speckle data should take those packages rather than the repository. And the licensing is the first thing to check, since the field carries a custom classification rather than a standard licence identifier, and a file in the repository root is the document that governs what a company can do with it. ## Conclusion Use this repository when you are running or extending a Speckle instance, because the server, the frontend, the viewer and the background services all live together and share one workspace and one lockfile. Do not treat it as the whole of Speckle, because the connectors for the design tools are separate repositories, and the interoperability that Speckle is known for lives in those. Verify first which version of the server you are deploying, since the 2.31.x line has been through many patch releases, that your Node version satisfies the engine requirement, and that you read the deployment documentation rather than the README alone, since the README routes all operational detail to the docs site. ## FAQ ### What is in the speckle-server repository? It is the Yarn monorepo for the Speckle v2 web packages: the server as a Node.js app, the frontend as a Nuxt and Vue app, the three.js viewer, the objectloader, and the preview, webhook and file import services. ### Where are the connectors for design tools? In separate repositories. The README lists speckle-sharp-connectors and speckle-sharp-sdk for .NET, specklepy for Python, and connectors for SketchUp, Excel, Unity, Blender, Unreal Engine, QGIS and PowerBI, with more in the organisation. ### How do I build the Speckle server locally? Use yarn workspaces with Node version 22. Run corepack enable, then yarn, then yarn build:public and yarn build, and afterwards use the scripts in individual packages or yarn dev to run them all in development mode. ### What are the npm packages from this repository? @speckle/viewer, a three.js extension for displaying 3D data, and @speckle/objectloader, a small utility class that streams an object and all its sub-components from the Speckle Server API. ### Which editor does the Speckle server project recommend? VSCode, because the repository carries configs for auto-format, auto-lint and recommended extensions, and it relies on multi-root workspaces, so you should open the workspace.code-workspace file. For TypeScript support it uses Volar in Take Over Mode with the built-in TypeScript and JavaScript Language Features extension disabled. ## Sources - [Issues](https://github.com/specklesystems/speckle-server/issues) - [Project website](https://speckle.systems) - [README](https://github.com/specklesystems/speckle-server/blob/main/README.md) - [Releases](https://github.com/specklesystems/speckle-server/releases) - [specklesystems/speckle-server on GitHub](https://github.com/specklesystems/speckle-server) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/specklesystems-speckle-server