Let’s Automate

Documentation

How to run Xeplr Analytics, how its model layer works, and how to build your own application on the open-source Xeplr OS packages.

These docs cover two things that share one foundation.

What it is Licence Where it comes from
Xeplr Analytics The BI application of the Xeplr Pro Suite: connections, datasets, reports, dashboards, data moves, a DuckDB warehouse with cubes, AutoML models, and a problem list Proprietary A deployment bundle you run on your own servers
Xeplr OS The @xeplr/* packages the application is built from: sign-in, the API base, database access, jobs, actions, the screen designer, tables, charts MIT npm

Xeplr Analytics

Three processes: a React UI, a sign-in service (@xeplr/auth) and an API. The API also embeds @xeplr/jobs (scheduling), the workflow engine (mounted at /workflow) and the AutoML engine. It needs PostgreSQL, Redis and local disk for DuckDB files.

  • Quickstart: run it locally, with its databases, settings and npm scripts.
  • Self-hosting: the deployment bundle, install.sh, nginx, systemd, and what has to be true before it serves anyone.
  • Datasets and cubes: datasets, nested datasets, filters and parameters, cubes on a DuckDB replica, and how compiled SQL is kept safe.

Xeplr OS

Every package is usable on its own. The quickest way to see them working together is the scaffolder, which writes an API, sign-in and a React UI that already talk to each other:

npx @xeplr/cli@latest new myapp
  • Build an app: the questions @xeplr/cli asks, what it generates, how to start it and how to add a UI.
  • Forms and screens: @xeplr/ui-factory and @xeplr/factory, meaning screens designed as JSON, records saved in real tables, hooks and models.
  • Access and menus: @xeplr/auth and @xeplr/ui-account, covering roles, the access object, menu keys and labels, and multi-tenancy.
  • Package reference: one page per package, rendered from its README.
  • The CLI: xeplr new and xeplr encrypt.

Rules that apply everywhere

Several decisions show up in every package and every app. The Security page collects them, and these four matter most:

  • No guessed database names, connections or storage paths. A missing value stops the process at startup and names the setting. A wrong-but-present value would start cleanly and read as empty data.
  • REDIS_PREFIX is required and unique per app. Apps sharing a Redis under the default prefix serve each other’s sessions, menus and API permissions.
  • The browser is not a security boundary. Clients send ids and values, and the server decides what runs.
  • Keys for code, labels for people. Menu items and forms each have a key that never changes and a label that can be renamed from the app.

Last updated 16 September 2026