Installation Methods
How should you install Liteset? Here's a comparison of the different options. It will help if you've first read the Architecture page to understand the components of a Liteset deployment.
Liteset is a drop-in async replacement for Apache Superset 6.0.0 and reuses the same metadata-DB schema, frontend bundle, and Celery worker. Most installation patterns documented here are inherited from upstream Apache Superset and apply unchanged, but the runtime is Litestar/ASGI on Uvicorn — not Flask/Gunicorn.
The fundamental trade-off is between you needing to do more of the detail work yourself vs. using a more complex deployment route that handles those details.
Docker Compose
Summary: This takes advantage of containerization while remaining simpler than Kubernetes. This is the best way to try out Liteset; it's also useful for developing & contributing back to Liteset.
If you're not just demoing the software, you'll need a moderate understanding of Docker to customize your deployment and avoid a few risks. Even when fully-optimized this is not as robust a method as Kubernetes when it comes to large-scale production deployments.
You manage a superset_config.py file and a docker-compose.yml file. Docker Compose brings up all the needed services — the Liteset application, a Postgres metadata DB, Redis cache, Celery worker and beat. They are automatically connected to each other.
Responsibilities
You will need to back up your metadata DB. That could mean backing up the service running as a Docker container and its volume; ideally you are running Postgres as a service outside of that container and backing up that service.
Unlike upstream Apache Superset, the Liteset lean image already ships both the runtime PostgreSQL driver (asyncpg) and the migration driver (psycopg2-binary), so no extra layering is required to talk to the metadata database. You will still want to extend the image for additional data-warehouse drivers (Snowflake, BigQuery, MSSQL, etc.) or for the headless browser used by Alerts & Reports. The -dev image bundles those development extras but runs as root, which is not recommended for production.
Ideally you will build your own image that extends lean, adding what your deployment needs. See the Docker images reference (Dockerfile targets and docs/deployment/production-docker.md).
Kubernetes (K8s)
Summary: This is the best-practice way to deploy a production instance of Liteset, but has the steepest skill requirement — someone who knows Kubernetes.
You will deploy Liteset into a K8s cluster using the in-repo Helm chart at helm/superset/.
A K8s deployment can scale up and down based on usage and deploy rolling updates with zero downtime — features that big deployments appreciate.
Responsibilities
You will need to build your own Docker image (or pull a Liteset-tagged one) and back up your metadata DB, both as described in Docker Compose above. You'll also need to customize your Helm chart values and deploy and maintain your Kubernetes cluster.
PyPI (Python)
Summary: This is the only method that requires no knowledge of containers. It requires the most hands-on work to deploy, connect, and maintain each component.
You install Liteset as a Python package and run it that way, providing your own metadata database.
If you want caching, you'll set up Redis or RabbitMQ. If you want Alerts & Reports, you'll set up Celery.
Responsibilities
You will need to get the component services running and communicating with each other. You'll need to arrange backups of your metadata database.
When upgrading, you'll need to manage the system environment and packages and ensure all components have functional dependencies.