Notes on Running Standalone Redash – Updated for Python3

reading time ( words)

Redash is an excellent tool to quickly build stunning dashboards to present your data. I use it to visualize data from my PostgreSQL databases for various projects, with the reliance in containers being a bit of a letdown for me. This post collects some notes on deploying redash as a group of standalone processes governed by systemd on my Linux servers. I can even run multiple instances on a single box, which is useful for testing new code versions or providing fully separate dashboards to different projects.

You might want to take a look at this github repo where I keep the template files discussed here.

If you are looking for a tutorial on installing Redash as per the project’s instructions, this is not the right place. The Redash project publishes various pieces of documentation on how to install and configure the software, with this one being my favorite. I am covering a different installation strategy here, that better suits my preferences and requirements.

Major components

I run my redash instances behind Nginx – this lets me do a few interesting tricks and provide a single, convenient location to log traffic and apply policies such as rate limits.

You’ll also need Redis. On my Debian servers, both of these are a simple install from the distribution packages. You will also need Node.js and Python 3, so let’s get that out of the way.

# As root
apt install redis-server nginx nodejs

I will not go into details on the Nginx configuration. However my github repo contains a template configuration based on the one I use for my live dashboards.

The installation process

On my systems, I like to run complex applications as dedicated users. I setup a special redash user whose home directory will host the code and assets. I also like to be able to run multiple instances of my services – this is useful for testing among other things.

Within this home directory, one or more Python virtual environments will be used to support as many instances of the service as needed. For this example, I will stick to a single instance that I will call production.

To setup the special user and its corresponding environment, you can follow these steps:

# As root
apt install python3
useradd --home-dir /home/redash --create-home --comment 'Redash user'
cd ~redash
mkdir code venv

You might want to configure the newly created redash account for SSH access or direct login as per your preference. After this step, software download and dependency installation will be performed:

# As the redash user
cd ~/code
git clone
virtualenv --python python3 venv/production
pip install -r ~/code/redash/requirements.txt
pip install -r ~/code/redash/requirements_dev.txt
pip install -r ~/code/redash/requirements_all_ds.txt

The installation will take a few minutes. In my case there were a few dependencies that were either unavailable or would not compile. Since my primary use case is concerned only with PostgreSQL, this is not a great concern to me.

This is a good time to place the bash-production-virtualenv file from my github repo into ~redash/. This file will take care of activating the Python virtual environment when systemd launches the services.

Once dependencies are out of the way, the site can be built:

# As the redash user
cd ~/code/redash
npm install
npm run build

After a few minutes of colorful logs about dependencies being downloaded and massaged, you should be almost ready for the systemd part, where the Redash components will come to life.

Systemd configuration

I wrote two systemd service files that launch celery and the server that Nginx proxies for. The service files are in my github repo. Most likely you will not need to make changes to them, unless you have opted for placing components on different locations or use a different Linux distribution.

The redash-production.default – which looks like as follows – contains the required runtime parameters to get Redash running. You will need to edit lines 3, 5 & 7 to include your real domain name; and, line 4 to add your real database coordinates and credentials.

# These settings control the production instance of redash.


# These settings are used by the virtualenv shell integration


Place this file at /etc/default/redash-production, where it will be used by the systemd service definitions later.

Database configuration

Prior to launching Redash, its own PostgreSQL database needs to be initialized. I create this database by hand:

-- As the postgres user

Database initialization if performed via the program. It needs its environment initialized, as follows:

# As the redash user
cd ~/code/redash
ln -s /etc/default/redash-production .env
./bin/run ./ database create_tables

If all is well, you will now have a populated redash database in your PostgreSQL instance.


Simply execute these commands to enable the new systemd services. Lines 5 through 7 below actually launch the service.

systemctl enable  redash
systemctl enable  redash-scheduler@production
systemctl enable  redash-worker@production
systemctl enable  redash-server@production
systemctl start   redash-scheduler@production
systemctl start   redash-worker@production
systemctl start   redash-server@production
systemctl restart nginx

At this point you can visit the Redash URL you defined in your Nginx configuration and complete your setup.