DataLens ships as Docker Compose first, with a Helm chart for Kubernetes

It ran as Yandex's primary BI tool before it was open sourced

The provenance is the strongest thing about this project and the README leads with it. DataLens was developed and extensively used as a primary BI tool inside Yandex, and is also part of the Yandex Cloud platform at datalens.yandex.com.

That history explains several things that would otherwise look odd. The architecture is Postgres-centric, with separate databases for the authorisation service, the control plane, the meta manager, Temporal and a demo dataset, all inside one Postgres instance. A system built for one company's internal scale does not need to abstract over a choice of database. The compose file confirms it, naming six database variables: `POSTGRES_DB_COMPENG`, `POSTGRES_DB_AUTH`, `POSTGRES_DB_US`, `POSTGRES_DB_DEMO`, `POSTGRES_DB_META_MANAGER` and `POSTGRES_DB_TEMPORAL`, plus `POSTGRES_DB_TEMPORAL_VISIBILITY`.

Temporal is in there because long-running operations such as exports and scheduled refreshes need a durable workflow engine, and that is what Temporal is.

The documentation is at https://datalens.tech/docs, and there is a Telegram community linked as YandexDataLens. The repository itself is Apache-2.0, which is worth noting given the internal origin: the licence is permissive enough for commercial use without negotiation.

One command for the quick start, and the admin password is admin

Docker is the only prerequisite, with platform-specific install instructions for macOS, Linux and Windows. The README also pins Compose expectations, which is the kind of detail that saves an afternoon: the Docker Compose v2 plugin ships as `docker-compose-v2` on Ubuntu 20.04, 22.04 and 24.04, while the legacy utility as a separate package needs version `1.29.0` or later and is in the base APT repository only on Ubuntu 22.04.

Clone and start:

git clone https://github.com/datalens-tech/datalens && cd datalens

HC=1 docker compose up

The UI comes up on http://localhost:8080 with `admin` and `admin` as the default credentials. A different port comes from the `UI_PORT` environment variable:

UI_PORT=8081 docker compose up

The `HC=1` prefix is the Highcharts switch, which the README treats as a licensing decision rather than a performance one. Leave it off and charts render through D3.js instead.

The image tags in the compose file are pinned rather than floating, for example `ghcr.io/datalens-tech/datalens-postgres:16-1.3.0`, and `pull_policy` defaults to `always`. Every component version is tracked in `versions-config.json`, which the README badges read from, so there is one file to look at when you want to know what is deployed.

init.sh generates real secrets, and the default compose does not

The quick start above is explicitly not for production. For that, the README points at `init.sh`, which generates a compose file with random secrets, stores them in a `.env` file and prepares a production template.

# generate random secrets with openssl, store it to .env file and prepare production compose template
./init.sh --hc

# and then run production compose
docker compose -f ./docker-compose.production.yaml up -d

# you can also generate and run production compose file with one command
./init.sh --hc --up

The generated admin password lands in the `.env` file and is printed to the terminal, and `./init.sh --help` lists every argument.

Compare that with what the base compose file ships as a default. The password variable falls back to a literal string:

POSTGRES_PASSWORD: "${POSTGRES_PASSWORD:-postgres}"

and there is a hardcoded fallback for the control API crypto key. That default is base64 and decodes to a readable phrase, which means anyone who finds your deployment and did not change it knows the key. This is fine for a local trial and wrong for anything reachable, which is exactly the distinction the README draws by routing you to `init.sh`.

The Kubernetes path exists too, with a Helm chart in an OCI registry at `oci://ghcr.io/datalens-tech/helm/datalens`, and requires generating four RSA key pairs for the auth service, Temporal and the two dynamic auth paths before install.

Highcharts is the licence fork in the road

This is the decision that matters most when you are evaluating DataLens, and it is buried in a collapsible section of the README.

Highcharts is a proprietary commercial product. If you enable it in your DataLens instance, using the `HC=1` variable, you should comply with the Highcharts license. If you disable it, DataLens uses D3.js instead.

And here is the catch, in the README's own words: only a few visualisation types are currently compatible with D3.js, with work ongoing to add more, and an intention to completely replace Highcharts with D3 eventually.

So the choice is between a complete chart library under a commercial licence and an incomplete open one. For an internal dashboard where the chart types you need are among the supported ones, D3 is the clean answer. For anything needing the long tail of chart types, you are paying Highcharts or waiting.

This is also why the quick start command is `HC=1 docker compose up` rather than plain `docker compose up`. The default quick start turns on the proprietary library, which means a first-run install has licence obligations attached to it by default. That is a defensible default for an evaluation and an unfortunate one for a production deployment nobody thought about.

Upgrades are a git pull because state lives in one volume

The update path is short:

git pull

# if you use base compose file
docker compose up

# if you use init.sh script
./init.sh --up

The reason it is safe is stated plainly: user settings, connections and created objects are preserved because they are stored in the `db-postgres` Docker volume, and the update does not affect that data.

This is the design decision that makes DataLens deployable as a git checkout rather than a released artifact. There is no migration step to run, no versioned installer and no upgrade path to plan around, because there is no state outside the Postgres volume. What you are really doing is redeploying images.

The same simplicity means there is nothing to back up except that volume, and nothing else to save either. A team running this in production should treat a Postgres volume snapshot as the whole backup strategy.

The repository structure supports the workflow: `postgres/`, `temporal/`, `dev/`, `scripts/`, `helm/`, `docker-compose.yaml`, `docker-compose.dev.yaml` and `init.sh` at the root, plus a CHANGELOG.md and SECURITY.md.

Versions lag the last commit, and the language is PLpgSQL

The primary language in the repository metadata is PLpgSQL, which is a direct consequence of the architecture. The application logic that lives in the database is written in Postgres procedural SQL, and the container images are Postgres images rather than a general-purpose runtime image.

Release history: v2.9.0 on 2026-02-19, v2.8.0 on 2026-02-11, and v2.7.0 on 2025-11-21. Two minor versions were released eight days apart in February. The last push was on 2026-08-24, after v2.9.0.

That gap is the thing to weigh. The repository is not archived and the documentation site is live, but there has been no tagged release since February while commits have continued to land. Anyone deploying from a release tag is several months behind `main`, and anyone deploying from `main` is deploying something no one has versioned.

Component versions are tracked separately in `versions-config.json`, which carries `uiVersion`, `usVersion`, `backendVersion`, `authVersion` and `metaManagerVersion` fields pointing at sibling repositories: datalens-ui, datalens-us, datalens-backend, datalens-auth and datalens-meta-manager.

So DataLens is not one codebase. It is an umbrella repository holding deployment configuration over five separately versioned services. That is a real consideration for anyone planning to contribute upstream.

Yandex Maps is opt-in and needs its own token

One visualisation requires explicit configuration. Yandex Maps support is available since release v1.11.0 and is off unless you enable it.

Two parameters control it, `YANDEX_MAP_ENABLED` set to `1` or `true`, and `YANDEX_MAP_TOKEN` carrying a Yandex Maps API key. Both work with compose directly:

YANDEX_MAP_ENABLED=1 YANDEX_MAP_TOKEN=XXXXXXXXX docker compose up

and with the init script, which has matching flags:

./init.sh --yandex-map --yandex-map-token XXXXXXXXX --up

The fact that this needs a separate token is worth noting alongside the Highcharts question. An internal BI deployment can end up with two commercial dependencies of different kinds: a charting library that is baked into the images and a map service that makes runtime calls to Yandex. Neither is free to ignore, and both are easy to enable without noticing.

There is also a demo dataset, controlled by `INIT_DEMO_DATA` and `INIT_DB_DEMO` which both default to `1`. That is convenient for evaluation and something you would want to turn off for a real deployment, which is the kind of setting the init script exists to handle.

For anything beyond local use, the roadmap is published as a GitHub project board under the datalens-tech organisation, and release notes are on the releases page.

Editorial conclusion

DataLens is the right choice if you want a self-hosted BI tool with a Postgres-backed connector model and the option of a Kubernetes deployment, and it is Apache-2.0 so commercial use is not a licensing question. It is the wrong choice if you need visualisation types outside what D3 supports, because the D3 path is incomplete and Highcharts is proprietary. Before running `./init.sh --hc` for anything beyond a local trial, decide whether you will keep Highcharts enabled, since that decision determines both your licence obligations and how much of the chart library you can use.

Frequently asked questions

Official sources

1. datalens-tech/datalens on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases