Apache Superset

Sign in to the AWS Management Console, open the EC2 service and choose Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Apache Superset. Choose Select on the SecureAnyCloud listing, then choose Continue on the subscription summary.

Choose an instance type of m5.large or larger, because Apache Superset, PostgreSQL, Redis and the Celery worker run together on the instance. Choose your EC2 key pair under Key pair (login). Under Network settings, choose your VPC and subnet, then create or choose a security group. The group must allow inbound port 22 from your management network and inbound port 8088 from the networks your analysts use. Keep the root volume at the default size or larger.

Choose Launch instance. First boot initialization takes a couple of minutes after the instance state becomes Running and the status checks pass. During this time, the first boot generates the per-instance credentials and prepares the metadata schema.

The following command launches an instance from the SecureAnyCloud Apache Superset Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22 and 8088 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=apache-superset-01}]'

On success, the command prints a JSON document. Note the instance ID, then get the public address once the instance is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you chose and the public IP address from step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Apache Superset 6 on Ubuntu 24.04 ubuntu

ssh <login-user>@<public-ip>

The first boot service runs before the SSH daemon is ready, so the credentials file is in place when you first log in.

The first boot generates the Superset administrator password and writes it to a root-only file. Read the file with sudo:

sudo cat /root/superset-credentials.txt

The plain text file contains the Superset URL, the login URL, the administrator username (admin) and the administrator password. Copy these values to a secure place such as a password manager or encrypted vault. Do not commit them to source control.

From the same SSH session, you can confirm that every component of the stack is healthy. First, confirm that the four services are active:

sudo systemctl is-active superset.service superset-celery.service postgresql redis-server

Each line of the output is a service state, and all four should read active:

active active active active

Confirm that first boot initialization completed:

sudo test -f /var/lib/sac/data/superset-firstboot.done && echo FIRSTBOOT_DONE

Confirm that gunicorn is listening on port 8088:

sudo ss -tln | grep 8088

Confirm that the Superset health endpoint responds:

curl -s -o /dev/null -w 'health HTTP %{http_code}\n' http://127.0.0.1:8088/health

A health HTTP 200 response confirms the Superset web application is serving requests.

Open a web browser and go to http://<public-ip>:8088/login/. Superset shows the sign-in form.

Enter the administrator username admin and the administrator password from /root/superset-credentials.txt, then choose Sign in. After your first successful sign-in, Superset records your session and shows the home page with the top navigation bar.

After you sign in, the home page gives you quick access to every area of Superset. Dashboards holds interactive dashboards, Charts holds individual visualizations, and Datasets holds the logical tables that charts are built on. The SQL menu opens the SQL Lab editor. The Settings menu in the top right holds database connections, user and role administration, and your account profile.

On a freshly deployed instance, the dashboards and charts lists are empty. The next steps walk through connecting a data source and building your first content.

For a production deployment, rotate the administrator password that the first boot generated. Choose Settings in the top navigation, then List Users. Find the admin user, choose the edit action, enter a new password and save.

You can also reset the administrator password from the command line with the Superset CLI. The CLI needs the per-instance secret key and database password in the environment file, so source that file first. Replace <new-password> with your new password:

set -a; sudo . /etc/superset/superset.env; set +a cd /srv/superset/home && sudo -u superset env \
  SUPERSET_SECRET_KEY="$SUPERSET_SECRET_KEY" \
  SUPERSET_DB_PASSWORD="$SUPERSET_DB_PASSWORD" \
  PYTHONPATH=/etc/superset FLASK_SKIP_DOTENV=1 \
  /opt/superset/venv/bin/superset fab reset-password \
  --username admin --password '<new-password>'

Superset explores data that lives in your own databases and data warehouses. In the top right, open Settings, then Database Connections, then choose + Database to open the connection wizard.

Choose one of the built-in connectors. Common AWS pairings:

• PostgreSQL: point at an Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL instance, or another SecureAnyCloud PostgreSQL image

• MySQL or MariaDB: point at Amazon RDS for MySQL or MariaDB

• Amazon Redshift: the Redshift connector is included for data warehouse workloads

• Amazon Athena: query data in Amazon S3 through Athena

• Snowflake, Google BigQuery, ClickHouse, Trino and Presto: these modern analytical engines are first-class connectors in Superset

Enter the connection details and choose Test Connection to confirm that Superset can reach the database. Then choose Connect to save it.

The SQL Lab editor is the fastest path from a query to a chart. In the top navigation, open SQL, then SQL Lab. Choose the database you connected in step 9, write a query and run it. Superset hands long-running queries to the Celery worker, so they run asynchronously and do not block the web application.

Choose Save, then Save dataset, to keep a query as a logical dataset. From a dataset, choose Create chart to open the explore view. Choose a chart type, drag dimensions and metrics into the configuration panel, and save the chart. Add charts to dashboards under the Dashboards menu.

Apache Superset listens on plain HTTP on port 8088 by design. For any production deployment, put a TLS-terminating reverse proxy in front of it so that session cookies and credentials cannot be intercepted. The image already sets ENABLE_PROXY_FIX in /etc/superset/superset_config.py, so Superset honors the X-Forwarded-Proto and X-Forwarded-For headers that a proxy sets.

A common pattern is nginx with a Let's Encrypt certificate on the same instance. This pattern assumes that a DNS record points your fully qualified domain name at the instance's public IP address.

sudo apt-get update && sudo apt-get install -y nginx certbot python3-certbot-nginx
sudo certbot --nginx -d superset.your-domain.example \
  --non-interactive --agree-tos -m you@your-domain.example --redirect

Configure the nginx server block to proxy to http://127.0.0.1:8088, then restrict the security group so that port 8088 is no longer reachable directly from the internet. Alternatively, place an Application Load Balancer with an AWS Certificate Manager certificate in front of the instance and route the target group to port 8088.

Check the service status:

sudo systemctl status superset.service --no-pager | head -n 15

Stop, start or restart the Superset web application and the Celery worker together:

sudo systemctl restart superset.service superset-celery.service

View the gunicorn and Celery worker logs:

sudo tail -n 50 /var/log/superset/gunicorn.log
sudo tail -n 50 /var/log/superset/celery.log

The Superset metadata (every database connection, dataset, chart and dashboard) lives in the PostgreSQL superset database. Back it up with pg_dump:

sudo -u postgres pg_dump -Fc superset > /var/backups/superset-metadata.dump

To restore on a new instance, stop the Superset services, then run pg_restore. Replace <backup-dir> with the directory that holds your dump file:

sudo -u postgres pg_restore -d superset --clean --if-exists <backup-dir>/superset-metadata.dump

Copy the dump to an Amazon S3 bucket for durable off-instance storage, and schedule the backup to run nightly. Ubuntu applies security patches for the kernel and packages automatically. To update Apache Superset within the 6.x line, activate the virtual environment, upgrade the apache-superset package, then restart the services.

For larger deployments, move the components onto managed services:

• Move the metadata database to Amazon RDS for PostgreSQL and update SQLALCHEMY_DATABASE_URI in /etc/superset/superset_config.py

• Move caching and the Celery broker to Amazon ElastiCache for Redis and update the cache and Celery settings in the configuration file

• Run several Superset web instances behind an Application Load Balancer, and run the Celery workers on their own instances. Point all of them at the shared RDS and ElastiCache endpoints

The official Apache Superset documentation at https://superset.apache.org/docs/ describes each of these changes.

Component Path

Superset Python virtual environment /opt/superset/venv/

Superset CLI /opt/superset/venv/bin/superset

Application configuration /etc/superset/superset_config.py

Environment file /etc/superset/superset.env

Superset home /srv/superset/home/

PostgreSQL data directory /srv/superset/postgresql/16/main/

Log directory /var/log/superset/

gunicorn systemd unit /etc/systemd/system/superset.service

Celery worker systemd unit /etc/systemd/system/superset-celery.service

First boot script /usr/local/sbin/superset-firstboot.sh

First boot service /etc/systemd/system/superset-firstboot.service

Credentials file /root/superset-credentials.txt

First boot sentinel /var/lib/sac/data/superset-firstboot.done