Sizing is based on the number of concurrent users and the number of concurrent queries that you have. For <10 concurrent users and <100 active queries, a tiny machine that has a dual core, 2 GB memory should be enough.

On the other hand, if you have 50-100 concurrent users and 1,000 active queries, you will need at least 16-32 GB RAM and a quad-core CPU.

• Redis - Memory intensive
• Postgres - CPU and memory
• Celery - CPU and memory (the more workers you have, the more CPU you need. If workers won't keep up and build up a queue, it starts to consume memory)

If you're hosted in the cloud, you can always start with a smaller machine and expand if needed. The same goes for deploying Redash inside a VM in your own data center.

As a good...

In this section, we will cover the options you have when installing Redash. If your machine resides in the cloud, you will be able to choose an existing image of Redash with all the necessary components already predefined.

In case you prefer to have more control over the installation, you can run the setup.sh script or manually run Docker installation.

There are various installation options for Redash, and they are as follows:

For the Cloud (AWS/GCE):

• Using a predefined image
• Manually using a Setup script

For your own datacenter (VM or Physical Machine):

• Docker
• Manually using a Setup script
  In all of the aforementioned options, you can provide your own...

The setup.sh script is the core of all the cloud based installation options. Regarding an image-based installation, you don't have to dive into the details of this script, but if you want to install Redash manually (or are just curious about the internals), it's better to take a quick look at it.

Let's break the script into parts while going over it.

At first, we set Redash base installation path...

The main thing to bear in mind here is that setup.sh (core of all the installation processes) is not idempotent.

This means that if somehow the script failed in the middle of running, you can't simply run it again.

In case something went wrong with the installation, follow these instructions:

1. Try to check the output of the setup.sh script and figure out what the reason for its failure could be. Possible reasons include permissions/missing packages.
2. It's always better to reinstall rather than try and run the script from where it stopped.
3. Review the section which explains setup.sh, in combination with the logs. This might give you the answer.
4. If using AWS/GCE, verify that ports 22, 80, and 443 are reachable (sometimes, even if not in the cloud, corporate users have strict firewall rules, so you might have to check it even if not on AWS/GCE).

In order to experience Redash to its fullest, after installing it, you need to run some configurations, for example, for users and emails.

Redash uses email as part of user management (password reset and so on) and as a destination for alerts to be received at.

After your first setup, when you log in to Redash, you will see the following notification telling you that your email has not yet been configured, which means that you can't enjoy all the features of Redash:

The email configuration resides inside an env file.

We can use the find or locate Linux command to find where exactly the env file resides on our machine.

By default (in case you used setup.sh based installation...

Not all data is meant to be viewed and edited by all users, and there are rare cases where we don't need to restrict the access to one or more resources in some way (except maybe proof-of-concept works, or garage-mode startups where everyone is an admin).

In this section, we will cover the permissions mechanism in Redash.

The core of Redash's permissions model are Groups.

Users are members of groups, while Data Sources are associated with groups.

Group membership by a user defines the actions they can perform, and the Data Sources they can access.

Each DataSource can be associated with one or more groups.

Currently, there are two types of relations between a DataSource and a group:

• Full...

In this chapter, we covered the different options of installing a self-hosted Redash, including detailed step by step guidance. We also reviewed the setup.sh script, which is the basis of all of the installation options, and went through a common troubleshooting practice.

Then, we covered how to configure and test emails, went over all of Redash's environment settings, and in addition covered the permissions mechanism (Users and Groups) in Redash.

The next chapter will guide you in how to create your first queries, visualizations, and dashboards.