Visivo v1.0.75: The Full Local App Now Ships With pip install

Visivo v1.0.75 closes the gap between installing the CLI and seeing your first dashboard. The viewer now ships inside the pip package, so pip install visivo gives you the complete local BI tool with nothing left to build. This release also adds a --verbose flag to visivo run for clearer, more detailed output when you need to see exactly what the run is doing.

If you have ever followed a getting-started guide that worked right up until a separate asset-build step quietly failed, this release is for you. The headline is friction removal: fewer commands between pip install and a running dashboard, and a sharper picture of what happened when a run does not go as planned.

What shipped in v1.0.75

Two changes, both aimed at the first ten minutes with the tool:

• The viewer is bundled into the pip package. Installing Visivo now installs the full local app. There is no separate build or asset-fetch step before visivo serve can render your dashboards.
• A new --verbose flag for visivo run. Pass it to get more detailed run output, which is what you want when a query is slow, a model is not resolving, or you just want to watch the pipeline work.

Neither is a flashy new feature, and that is the point. The best releases for a developer tool are often the ones that remove a step you did not realize you were tolerating.

The viewer now ships inside the pip package

Visivo has always had two halves that have to meet: the Python CLI that compiles your YAML, runs your queries, and builds artifacts, and the viewer, a React app that renders those artifacts into interactive dashboards in your browser. In earlier setups, getting the viewer in place could involve an extra build or fetch step on top of the install. That is one more thing to get right, one more place for a version mismatch to creep in, and one more line in every onboarding doc.

In v1.0.75, the viewer is packaged with the CLI and published together. When you run:

pip install visivo

you get both halves at once, already matched to the same version. There is no asset step to remember and no chance of running a new CLI against an old viewer build. The CLI knows where the bundled viewer lives and serves it directly.

The same is true if you prefer the install script:

curl -fsSL https://visivo.sh | bash

Either path lands you in the same place: a single, self-contained local app.

One install, the whole local app

The practical effect is that the path from zero to a live dashboard is now genuinely short. Install, point Visivo at a project, and serve it:

pip install visivo
visivo serve

visivo serve compiles your project, runs the queries it needs, and opens the bundled viewer in your browser with hot reload watching your files. Edit a YAML definition, save, and the dashboard updates. There is no second tool to install, no Node toolchain to provision just to see your charts, and no build step that can drift out of sync with the CLI.

For anyone evaluating Visivo, this matters more than it sounds. The moment a new tool asks you to run three commands and one of them fails on your machine, the evaluation is effectively over. Shipping the viewer in the package means the happy path is the only path. It is the same principle behind treating your whole analytics setup as reproducible BI environments: the fewer moving parts a teammate has to assemble by hand, the more reliably they end up in the same working state you are in.

Debugging runs with the new --verbose flag

The other change in v1.0.75 is a --verbose flag for visivo run. By default, visivo run keeps its output tidy: it tells you what it is doing without flooding the terminal. That is the right default for a clean run. It is the wrong default the moment something is off and you need to see inside the pipeline.

visivo run --verbose

With --verbose, you get more detailed output as the run progresses: more visibility into the steps Visivo is executing, so you can pinpoint where a slow query, an unresolved model, or a misconfigured source is costing you. Instead of guessing why a run took longer than expected or stopped short, you can read what actually happened.

This pairs naturally with Visivo's existing debugging environment variables. Set DEBUG=true for verbose application output and STACKTRACE=true for full error traces when you need to file an issue or dig into a failure. The --verbose flag gives you a lighter-weight first look before you reach for those. The docs at docs.visivo.io cover the run and serve commands in full.

What it unlocks for your workflow

The combined effect of these two changes is a tighter, more honest feedback loop.

Onboarding gets shorter. New teammates can go from pip install visivo to a running dashboard without a sidebar of caveats. That lowers the cost of bringing someone onto a code-first BI project, which is exactly the kind of friction that quietly decides whether a tool gets adopted across a team. We have written before about why faster feedback cycles are the real productivity unlock for data work, and a one-step install is the very first cycle.

CI and containers get simpler. When the viewer ships with the package, a pip install visivo in a Dockerfile or a CI job is the whole install. There is no separate build stage to add, cache, or keep in sync. That makes Visivo easier to drop into the automated pipelines where BI-as-code earns its keep.

Debugging gets less mysterious. The --verbose flag means that when a run misbehaves, your first move is to ask the tool to show its work rather than to start commenting things out. More signal, less guessing.

None of this changes how you author dashboards. Your models, metrics, and Insights are defined exactly as before. What changes is the surface area between you and a working local app, and v1.0.75 shrinks it.

If you want to try the shorter path yourself, /get-started walks from install to first dashboard in a few minutes, and the examples gallery has live projects you can run locally to see the viewer in action.

Previously in Visivo

New to the BI-as-code approach Visivo is built around? Start with what BI-as-code is and why it matters for the philosophy behind defining dashboards, metrics, and tests as version-controlled files. Then come back here to see how v1.0.75 makes getting started on that model a single command. The next recap lands when the next version does.