Visivo v2.1.0: A Workspace for Building and Exploring

A question rarely starts as a finished dashboard. You inspect a source, try a query, change a calculation, and decide which result is worth sharing. The useful work happens between those steps.

Visivo v2.1.0 brings more of that work into one Workspace. In local visivo serve, visual dashboard building, project editing, lineage, and exploration now share a place to work. You can follow a question from a source to a chart, then turn the result into part of your project without rebuilding it in another screen.

The v2.1.0 release, published August 7, 2026, also adds automatic and manual run controls, improves deployment feedback, and simplifies the model system. Here is what changed and what to check when upgrading from 2.0.3.

Build dashboards in the Workspace

The Workspace brings the project library, open tabs, editing tools, and dashboard canvas together. Instead of moving between separate editor and lineage pages, you can keep the project in view while working on an individual object.

On the dashboard canvas, you can drag items between rows, fill empty slots, use row templates, and adjust layout. The library gives you a place to find and create project objects, while the right-hand editor exposes the selected object's properties.

That editor also becomes more consistent. Schema-driven forms handle chart and Insight properties, with validation in the save path. You do not have to leave the visual workflow just to find the right shape for a configuration field.

Edits remain visible as pending changes. The top bar shows saving activity and the pending-change count, with Commit and Discard controls. Drafting an edit and committing it are separate steps, so you can inspect the result before persisting the project changes.

The underlying project still uses version-controlled configuration. Locally, Commit writes your project edits to YAML; you can then review and commit the file changes in Git. For the objects behind the canvas, see the dashboard concepts guide.

Explore a question, then keep the result

Explorer now sits inside the Workspace alongside Project and Semantic Layer. An exploration is a saved working object: create one, try queries and charts, leave it in a tab, and return to it later.

The source library lets you drill from a source into schemas, tables, and columns. In the build rail, typed field pills expose aggregation choices without making you assemble raw configuration expressions for every change.

The important step is what happens after you find something useful. You can promote an exploration's Insights and charts into the project. From a dashboard, New Chart can take you through an exploration and back to Place in dashboard. From an existing project object, Explore this takes you in the other direction.

Consider a question about revenue by region. You can investigate it in an exploration, try the aggregation and presentation, and promote the useful chart when you are ready to keep it. The investigation does not have to become a permanent dashboard immediately, and a useful result does not have to be recreated from scratch.

See the relationships behind a chart

The Workspace also connects editing to the project's structure. Source views expose tables and columns, while the semantic-layer view makes models, fields, and relations easier to inspect together.

You can create a model from a source table, work with metric and dimension fields, and build a relation by connecting columns. Lineage is available in the same working environment rather than as a separate destination you visit only after something breaks.

That helps when a chart raises a question about its definition. You can move from the visual result toward the model and relation that explain it, then edit in context. The shared definitions remain the place to fix a calculation used by more than one dashboard.

The semantic-layer guide explains how metrics, dimensions, and relations fit together.

Choose when data runs

v2.1.0 adds Automatic and Manual modes for editor-triggered runs. The Runs view lists data changes waiting to be built, and the Runs tab signals when work is pending.

Automatic mode keeps the local edit-and-see loop moving. Manual mode lets you make several edits before starting the data work yourself. Local serve defaults to automatic; the cloud setting defaults to manual.

The staged list answers a specific question: what data work would a run build? It is different from the list of uncommitted project edits. A chart color or dashboard layout change can need a commit without needing another query.

There is an important local boundary: manual mode controls saves made through the editor. External YAML file changes and commit-triggered rebuilds still rebuild automatically in local serve. It is not a switch that disables every rebuild.

Deployment feedback improves too. Deploy reports what it is uploading, sends individual project resources in batches, and refuses to proceed when the required run output is missing. Missing artifacts become an actionable failure instead of an upload that appears to have succeeded. See the deployment guide for the hosted workflow.

Upgrade script models to source seeds

The model system gets a structural change in this release. SQL models remain the model type; script-generated CSV data moves into a source's seeds list. A seed runs a command and loads its CSV output into a named table before models query that source.

For example, a source can load a checked-in CSV before a SQL model uses it:

sources:
  - name: scratch
    type: duckdb
    database: target/scratch.duckdb
    seeds:
      - args: [cat, data/orders.csv]
        table_name: raw_orders

models:
  - name: orders
    source: ${ref(scratch)}
    sql: SELECT * FROM raw_orders

Seeds run before source schema introspection, so the resulting tables are available to the editor as well as to model queries. Models can share a source and join its tables with SQL.

If your configuration runs a command inside a model, migrate it before using this release. The migration command converts these definitions into seeded sources and SQL models. The older model-level merge mechanism is removed; the migration reports these definitions for a manual rewrite rather than guessing how to combine their SQL. Move the inputs onto a shared source and express the join in the model's SQL.

Start with a dry run so you can review what will change:

visivo migrate

Then apply the supported rewrites and inspect the resulting configuration diff:

visivo migrate --apply

Resolve any reported manual migrations before running the project.

Try the release

To install this specific version with the install script:

curl -fsSL https://visivo.sh | bash -s -- --version 2.1.0

For an existing project, review the migration above, then run it and open the local Workspace:

visivo run
visivo serve

The installation guide covers platform requirements and alternative installation methods. If you are starting a project, the getting-started guide and examples provide a shorter route to something you can explore.

For every change included in the release, read the full changelog from v2.0.3 to v2.1.0.

Previously in Visivo

The v2.0.3 recap covered CLI and cloud API consistency, deploy authorization, and release-build hardening. v2.1.0 builds on that foundation with a more connected place to create and investigate your dashboards.