Univer is an Office SDK you assemble from plugins, not a spreadsheet app you drop in

Every capability ships as a plugin, and presets are curated bundles of them

Univer is built plugin first. Each capability is delivered as a composable plugin, so a feature can be added, removed, replaced or lazy loaded without taking the rest of the stack. That gives two ways to integrate it.

Preset mode uses the curated plugin collections in the presets/ directory. This is the route when you want a working spreadsheet or document editor quickly and are happy with the default set of plugins.

Plugin mode means composing packages by hand. The project points to it for custom loading order, smaller bundles or deep integration with your own application. The trade is that you take over the decisions a preset made for you: which plugins load, in what order, and which are deferred.

The build scripts reflect the same split. build:plugins builds every package except those under common/ and presets/, and build:presets builds the presets after their dependencies. A preset is a layer on top of plugins, not a separate product, so anything a preset does you can reproduce by composing the plugins yourself.

One Facade API covers workbooks, ranges and formulas in the browser and in Node.js

The central programming surface is the Facade API. It is a higher level API over workbooks, worksheets, ranges, documents, formulas, commands and events, and the same surface is meant to work in the browser and on Node.js.

That isomorphic design is the reason Univer pitches itself at AI infrastructure. You can run workbook and document logic headless in Node.js to drive agents, automation and server side workflows, using the same architecture that powers the interactive editor in the browser. A job that fills a workbook on the server and a user who opens it in the browser are working through the same model rather than two separate implementations.

For teams that already script spreadsheets on the server with one library and render them in the browser with another, this is the main practical argument for Univer. Under the Facade sits a lower layer of custom plugins, commands, services and UI components, which is where you go when the Facade does not expose what you need.

Rendering happens on Canvas, with a dedicated formula engine

Univer does not draw cells as DOM elements. It uses a Canvas based rendering engine, and the rendering layer is shared across document types, so spreadsheets, documents and presentations draw through the same engine. Paired with a dedicated formula engine, this is what the project credits for keeping large, complex workbooks responsive.

The UI components and the rendering engine both adapt to light and dark themes, so dark mode does not stop at the toolbar while the grid stays white.

On the UI side, Univer integrates with React, Vue, Web Components and framework specific application shells. Framework adapters and presets are listed as part of what makes it a product ready SDK. If your product is built in one of those stacks, the editor can sit inside your existing shell rather than in an iframe pointing at a hosted app, which is the point the project makes when it says Univer does not force you into a hosted app or a fixed UI.

The open-source repository covers less than the product family name suggests

The project tagline lists Spreadsheets, Documents, Presentations, Bases, Boards and PDFs, and the wider Univer product family shares a runtime for storage and computation, with content that can be embedded across tools and linked references that update together. That description is of the product family, not of this repository alone.

The scope of dream-num/univer itself is defined in its Open Source and Pro section, and product coverage is listed separately in a capability matrix on univer.ai. A team that reads the tagline and assumes every listed surface is available under Apache-2.0 from this repository can end up designing around a feature that sits in the Pro tier.

The practical consequence: before you plan an integration, map each feature you need against the capability matrix and the Open Source and Pro scope. Do this before writing code, because swapping out an editor after users have started working in it is far more expensive than checking a table first.

The agent integrations live in separate repositories with their own licensing

The agent story is a large part of how Univer now presents itself, under the banner of an Office harness for AI agents. Most of the concrete agent tooling, though, is not in this repository. It ships as separate projects built on the SDK:

Univer Workspace is an open source, self hostable workspace where people and agents create, collaborate on and review Office content. Agents there can generate spreadsheet based mini apps such as dashboards and interactive reports, with metrics, charts and controls bound to cells.

Univer CLI is a local command line workspace for agents to create, edit, inspect and deliver Office content. Univer Office for DeepSeek Harness adds connected content, validation and isolated worktrees for agent collaboration. Univer Office for OpenClaw provides tools for creating, reviewing and delivering Office content in OpenClaw. Univer Office for WorkBuddy, with MCP previews and draft review, is marked as a development preview.

Each of those projects documents its own setup and SDK licensing requirements. The Apache-2.0 license on dream-num/univer does not settle the licensing of what you build from them, so read each project's terms separately before shipping it.

Working from source requires pnpm 12, Node.js 22.18 and turbo

The repository is a pnpm workspace orchestrated by turbo. package.json pins packageManager to [email protected] and declares a devEngines runtime of node >=22.18, so an older Node.js install is outside the declared range before you run anything. The examples app under examples/ is a Vite project with separate Tailwind configs for docs, sheets and slides.

The root scripts that matter for a first look at the code:

pnpm --filter univer-examples dev
pnpm run build:plugins && pnpm run build:presets
turbo test -- --passWithNoTests

The dev script starts the examples app, build runs the plugin build followed by the preset build, and test runs through turbo with passWithNoTests, so packages without tests do not fail the run. There is also a Storybook package, started with storybook:dev, for working on UI components in isolation. Releases go through verso, configured by verso.toml at the repository root.

Releases arrive every few days on a dev default branch

The project is moving quickly. v1.2.0 shipped on 22 October 2026, v1.3.0 on 29 October 2026 and v1.3.1 on 2 November 2026, and the last push to the repository landed on 2 November 2026. The default branch is dev, which is where commits land between releases.

For an SDK you embed inside your own product, that pace cuts both ways. Fixes reach you fast, but two minor versions in about a week means APIs and plugin behavior can shift under you between upgrades. Pin an exact version in your package manager, read CHANGELOG.md before each bump, and test plugin compositions you assembled by hand more carefully than presets, since you own their wiring.

Univer is also explicit that it is not a spreadsheet file viewer only. It is a framework for building your own productivity surface, which means the work of designing the surrounding product, permissions and storage is yours. Teams that only need to display a workbook will be carrying a framework they do not need.

Editorial conclusion

Univer fits teams building their own product who need editable spreadsheets or documents inside it, or headless workbook processing in Node.js with the same logic as the browser. It does not fit someone who wants a finished office app or a simple file viewer, since you assemble the UI shell yourself. Before committing, check the Open Source and Pro section and the capability matrix to see whether the features you need are in this Apache-2.0 repository, and pin a version given how often releases ship.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes