A graphical toolbox for training, evaluating and deploying state-of-the-art AI models.
DashAI pairs a visual, interactive workbench with reproducible execution: you design datasets, experiments and pipelines in the browser, while Kedro governs pipeline runs with an explicit DAG, per-run reproducibility manifests and exportable standalone projects (see Kedro integration).
git clone https://github.com/DashAISoftware/DashAI.git
cd DashAI
./start.shstart.sh creates a virtual environment, installs the backend, builds the
frontend if Node/Yarn are available, and launches the app at
http://localhost:8000. Useful flags:
./start.sh --port 8080 # serve on another port
./start.sh --no-browser # don't auto-open the browser
./start.sh --dev # backend with DEBUG logging (pair with 'yarn start' for the frontend)
./start.sh --skip-install # fast start when deps are already installed
./start.sh --build-front # force a frontend rebuild
./start.sh -- --window-mode # pass extra flags through to 'python -m DashAI'Run ./start.sh --help for the full list.
macOS Intel note: torch 2.2.2 (the last release with x86_64 macOS wheels) is built against NumPy 1.x, while the newest scipy/shap/opencv releases require NumPy ≥ 2 and recent numba/llvmlite ship no Intel-mac wheels at all.
start.shresolves this automatically by applyingconstraints/macos-intel.txt(numpy<2 plus the last NumPy-1-compatible releases of the affected packages) to every install and repair step. If installing manually, usepip install -e . -c constraints/macos-intel.txt. On Apple Silicon, make sure you are not using an Intel (Rosetta) Python — check withpython -c "import platform; print(platform.machine())".
The easiest way to get started. Desktop installers, ready to use, are published with every release. They are CPU only and bundle everything you need, so no Python or extra setup is required.
Download the file for your system from the latest release:
- Windows (x64):
dashAI-<version>-x64-windows.exe - macOS (Apple Silicon):
dashAI-<version>-arm-osx.dmg - macOS (Intel):
dashAI-<version>-x64-osx.dmg - Linux (x64):
dashAI-<version>-x64-linux.AppImage
On Windows and macOS, run the installer, launch dashAI, and the graphical interface opens automatically.
On Linux, make the AppImage executable and run it:
chmod +x dashAI-<version>-x64-linux.AppImage
./dashAI-<version>-x64-linux.AppImageThe AppImage bundles its own Python, so nothing needs to be installed. It
requires glibc 2.35 or newer (Ubuntu 22.04+, Debian 12+, Fedora 36+, and most
distributions from 2022 on) and FUSE 2 to mount. If FUSE is missing, run it
with ./dashAI-<version>-x64-linux.AppImage --appimage-extract-and-run.
When double clicked, the AppImage opens a terminal window to show the server logs. This needs a terminal emulator, which every standard desktop (GNOME, KDE, XFCE, and others) already provides, so no setup is required. On a minimal system with no terminal emulator the log window is skipped, but the app still starts and opens the browser as usual.
Note: the desktop installers ship with CPU only PyTorch and
llama-cpp-python. For NVIDIA (CUDA) or AMD (ROCm) GPU acceleration, use the
pip installation below.
dashAI needs Python 3.10 or greater. We strongly recommend installing it
inside an isolated environment (venv or conda) to avoid clashes with
other packages.
Installing dashAI also installs PyTorch with the default build for your
platform, which works out of the box on CPU. To enable GPU acceleration
(NVIDIA CUDA or AMD ROCm), or to force a CPU only build, reinstall PyTorch
from the matching index as shown in step 3. llama-cpp-python is required to
run LLM models (GGUF / Llama, Mistral, Qwen, and similar) inside the app, but
it is never installed automatically, so install it in step 3 if you need
those models.
Linux / macOS (venv)
python3 -m venv dashai-env
source dashai-env/bin/activateWindows (venv)
python -m venv dashai-env
dashai-env\Scripts\activateconda (any platform)
conda create -n dashai python=3.12
conda activate dashaipip install dashaiThis step is optional on CPU (step 2 already installed a working PyTorch).
CPU only (smaller install on Linux):
pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu --force-reinstall --no-cache-dir
pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu --force-reinstall --no-cache-dirNVIDIA (CUDA):
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128 --force-reinstall --no-cache-dir
pip install llama-cpp-python -C cmake.args="-DGGML_CUDA=on" --force-reinstall --no-cache-dir --verboseAMD (ROCm):
pip install torch torchvision --index-url https://download.pytorch.org/whl/rocm6.4 --force-reinstall --no-cache-dir
pip install llama-cpp-python -C cmake.args="-DGGML_HIP=on" --force-reinstall --no-cache-dir --verboseThe -C cmake.args=... commands above compile llama-cpp-python from
source. They require:
- CMake (required to drive the build)
- A C compiler:
- Linux:
gccorclang - Windows: Visual Studio (C++ build tools / MSVC) or MinGW
- macOS: Xcode
- Linux:
- NVIDIA (CUDA): NVIDIA drivers and the NVIDIA CUDA Toolkit. Use version
>=12.8for RTX 5000 series GPUs to work. - AMD (ROCm): the ROCm / HIP SDK and AMD drivers.
If you want to skip compilation, precompiled llama-cpp-python wheels are
available for CPU and CUDA:
pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu --force-reinstall --no-cache-dir
pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/<cuda-version> --force-reinstall --no-cache-dirReplace <cuda-version> with your CUDA tag. Prebuilt wheels are published
for cu118, cu121, cu122, cu123, cu124, cu125, cu130 and
cu132 (for example cu124). See the
llama-cpp-python installation docs
for the available wheels and other backend options.
Start the server and graphical interface with:
dashaiThen open http://localhost:8000/ in your browser to access the dashAI graphical interface.
Useful options:
dashai --port 8080 # serve on another port (or set DASHAI_PORT)
dashai --no-browser # don't auto-open the browser
dashai --window-mode # native desktop window (PyWebView)
dashai --local-path <dir> # data directory (default ~/.DashAI)
dashai --logging-level DEBUGDashAI includes a visual pipeline editor backed by two compatible execution
paths: the native DashAI runner and a Kedro-governed runner. The same saved
visual graph is used by both engines. DashAI owns the interactive workflow,
component configuration, job supervision and results UI; Kedro owns the
reproducible DAG execution, DataCatalog lifecycle, run manifests and project
export.
The editor stores the node configuration (steps) and the visual connections
(edges) as a directed acyclic graph. Connections are not decorative: they are
validated by the backend and become real execution dependencies in both the
native runner and Kedro.
The current pipeline nodes have the following contracts:
| Node | Input | Output | Valid next nodes |
|---|---|---|---|
| Data Selector | Stored DashAI dataset | Dataset context | Data Exploration, Train Model, Retrieve Model |
| Data Exploration | Dataset context | Persisted exploration results | Terminal node |
| Train Model | Dataset context | Trained-model contract, metrics and model artifact | Prediction |
| Retrieve Model | Prediction dataset context | Loaded model contract from a previous pipeline | Prediction |
| Prediction | Model contract produced by Train Model or Retrieve Model | Persisted predictions | Terminal node |
A common branched workflow is:
┌──> Data Exploration
│
Data Selector ───────────┤
│
└──> Train Model ───> Prediction
For inference with an already trained model, use:
Data Selector ───> Retrieve Model ───> Prediction
Prediction intentionally has one predecessor. Train Model and
Retrieve Model carry the selected dataset and model metadata through their
branch context, so a second edge from Data Selector to Prediction is not
required.
Data Selector selects an existing dataset and propagates its id, name, path
and in-memory dataset object to the next node.
Data Exploration supports one or more DashAI explorers in the same node.
Explorer parameters and selected columns are validated against the component
schema and dataset dtypes before execution. Results are persisted under the
DashAI local data directory and are rendered in the pipeline RESULTS view.
Train Model uses 1-based column selections in the UI (ranges such as 1-7
are supported), split proportions, task, model, model hyperparameters and
metrics. Before saving the node, DashAI normalises the selected indexes to
canonical dataset column names and validates task compatibility. The backend
also accepts legacy 1-based indexes for stored pipelines, rejects out-of-range
or duplicated columns, and prevents input/output overlap.
The graph validator additionally rejects invalid node types, duplicate semantic nodes, incompatible edges, missing required predecessors, self-connections, multiple predecessors and cycles. The same constraints are checked again by the execution layer as a safety net.
The toolbar exposes the normal RUN action and, when Kedro is available, a KEDRO action showing the installed Kedro version.
| Execution mode | Behaviour |
|---|---|
| RUN | Executes the saved graph through DashAI's PipelineJob and Huey job queue. Every node receives only its direct predecessor's context, preventing state leakage between branches. |
| Run with Kedro | Converts the same steps + edges graph into a real kedro.pipeline.Pipeline, executes it with DataCatalog + SequentialRunner, and tracks the run through the same DashAI job queue. |
| Export Kedro project | Downloads a standalone Kedro project that rebuilds the visual DAG and can be executed with kedro run. |
In the Kedro bridge, every visual edge becomes a catalog dependency
(ctx__<node>). When a graph branches, each node receives a copy of its
predecessor context; terminal branches are merged only after they complete.
This makes branch execution deterministic instead of depending on the order of
the JSON steps array.
Pipeline outputs are written back to the saved pipeline and reused by the
RESULTS tab regardless of whether the run used the native runner or Kedro.
Exploration outputs use DashAI's existing visualizers (tabular, Plotly JSON and
images), while training exposes model information, parameters, metrics and
graphs. The GRAPHS tab reuses DashAI's standard results graph components and
adapts the pipeline metrics for the train, validation and test splits, so
bar/heatmap visualizations share the same rendering path as the regular model
results UI. If no graphable metrics are available, the UI shows an empty-state
message instead of failing the React render tree. Prediction runs persist their
result and metadata as JSON.
The result-bearing artifacts are stored below the configured DashAI
LOCAL_PATH:
pipelines/exploration/<pipeline_id>/ # explorer notebooks/results
pipelines/train/<pipeline_id> # trained model artifact
pipelines/predictions/prediction_*.json
kedro/runs/<run_id>/manifest.json # Kedro reproducibility manifest
kedro/exports/ # exported standalone projects
Every Kedro run produces a manifest containing the pipeline id/name, exact steps and edges, a stable SHA-256-derived fingerprint of the canonical steps/configuration, Python/Kedro/DashAI versions, timestamps, final status and the keys produced by each node. A new Kedro run also clears previous pipeline outputs before it is enqueued so the UI does not display stale results while the worker is running.
The integration API lives at /api/v1/kedro:
| Method & path | Purpose |
|---|---|
GET /api/v1/kedro/ |
Kedro availability, version and registered job type |
POST /api/v1/kedro/runs/{pipeline_id} |
Enqueue a reproducible Kedro run |
GET /api/v1/kedro/runs |
List recorded Kedro runs |
GET /api/v1/kedro/runs/{run_id} |
Read a run manifest |
GET /api/v1/kedro/pipelines/{pipeline_id}/dag |
Inspect the generated Kedro DAG |
POST /api/v1/kedro/export/{pipeline_id} |
Export the visual pipeline as a standalone Kedro project |
For implementation details, execution semantics, persistence paths and
troubleshooting, see
docs/docs/deep-dive/kedro.md. If Kedro is not
installed, the core DashAI pipeline runner continues to work and the Kedro
button is shown as unavailable.
dashAI can also run inside a container. Two Dockerfiles are provided at the repository root.
Dockerfile builds a CPU only image (CPU PyTorch). Build and run it with:
docker build -t dashai .
docker run -p 8000:8000 dashaiDockerfile.cuda builds a CUDA enabled image (CUDA 12.8 PyTorch and
llama-cpp-python compiled with CUDA offload). Build and run it with:
docker build -t dashai:cuda -f Dockerfile.cuda .
docker run --gpus all -p 8000:8000 dashai:cudaThen open http://localhost:8000/ in your browser.
To pass the host GPU into the container with --gpus all you need the NVIDIA
drivers plus the runtime that wires the GPU into Docker. How you get that
runtime depends on your setup:
- Native Linux Docker: install the NVIDIA Container Toolkit on the host.
- Docker Desktop (Windows / macOS): the GPU runtime is bundled with the WSL 2 backend, so you only install the NVIDIA driver on Windows and enable the WSL 2 backend. See the Docker Desktop GPU docs.
- Docker Engine inside a WSL 2 distro (without Docker Desktop): install the NVIDIA Container Toolkit inside the WSL distro, following the CUDA on WSL guide.
Some datasets you can use to try dashAI are available here.
To download and run the development version of dashAI, first, download the repository and switch to the developing branch:
git clone https://github.com/DashAISoftware/DashAI.git
git checkout developThe fastest way to a working dev setup is ./start.sh --dev, which prepares
the environment and starts the backend with DEBUG logging. For the full
manual setup:
All commands in this section run from DashAI/front.
- Install the LTS node version.
- Install the
Yarnpackage manager following the yarn getting started page. - Install the project packages and start the dev server:
cd DashAI/front
yarn install
yarn start # dev server on http://localhost:3000
yarn build # production build served by the backendSet up a Python (>= 3.10) environment, then:
pip install -e . -r requirements-dev.txt
pre-commit install
python -m DashAI --no-browser --logging-level DEBUGLint and format with ruff:
ruff check --fix
ruff formatFrom the repository root:
pytest tests/The backend tests use an in-memory SQLite database, so no setup is needed.
The database session is parametrized in every endpoint as
db: Session = Depends(get_db) so endpoints are tested on a test database
without touching the main one.
This project is developed in collaboration with:
- University of Chile - Leading Institution
- CENIA - Associated Institution
- IMFD - Collaborator
- Unholster - Industry Partner
Supported by ANID through Fondef IDEA ID25I10330, Fondef VIU23P 0110, and grants supporting the centers CENIA (FB210017) and IMFD (ICN17_002). Developed by students of DCC UChile and UTFSM.
To see the full list of contributors, visit Contributors in the dashAI repository on Github.