Docker, Heroku Container Registry, and GitHub Actions: Building Fast, Performant Streamlit Apps

This article assumes that you are familiar with using Streamlit for building your data apps and dashboards, or at the very least, have heard of Streamlit before.

Siora on Unsplash

Not too long ago, I was assigned to work on a dashboard that’d automate part of my company’s development workflow. And being a strong, unofficial advocate of Streamlit — having given numerous talks on Streamlit at about 6 or 7 international conferences — it’s only natural that I’d use Streamlit on this project.

Streamlit has always been always easy and straightforward to use, but performance on Heroku, more often than not, has been a complex issue. This led me to research how to make my Streamlit app load as fast as possible, without having to sacrifice anything.

All the techniques that I tried out are listed below and I’d delve into why you might consider using them, so you don’t run into all the niggling issues that I ran into.

• Building a Streamlit app
• Don’t push straight to Heroku, use Docker
• Reducing your image size: If it’s Streamlit, don’t use Alpine!
• Automating subsequent deployments with GitHub Actions Workflow
• Other useful techniques (Streamlit’s internals)

*Drumroll**

Building a Streamlit app

If you’re familiar with Streamlit already, then you’d know that using Streamlit to create web apps is as straightforward as writing plain Python scripts with few API calls here and there. For our purpose, here is a sample script:

This is a simple script that takes user input and creates a line chart based on the condition satisfied by the user input.

To run this in local server, it is as straightforward as running the command below in the terminal/command prompt;

$ streamlit run app.py

Don’t push straight to Heroku, use Docker

Once we have the web app, the next logical step is to push to the cloud, which Heroku is a good, free option for. And this is where the problems might start to arise.

The usual technique is to create a requirements.txt, Procfile, and setup.sh files, then use Git to push to the Heroku app which is added as a remote to your existing Git repository. But Streamlit apps have a reputation of loading very slowly on Heroku server.

One good theory is that Streamlit has a lot of package dependencies (which is understandable to some extent, considering how much it abstracts away lots of stuff), and these dependencies could consume a huge chunk of your Heroku’s memory size. So if your app contains a bunch of other memory-hogging functions, it is almost certain to experience drags in load speed.

A good way to solve this is by using Docker. Docker is a platform for building, shipping, and running applications very quickly without worrying much about infrastructure’s dependencies. One of my teammates had an issue with installing Streamlit on her machine (blame the zillion dependencies!) and Docker was a nice way to doublecross this inconvenience.

All you’d need alongside your code directory is your requirements.txt file, after which you’d create Dockerfile. Once the Docker image of the web app has been built, then it’s quite easy to push to Heroku Container Registry to start accessing the web app externally.

The first line of code uses a Python image as the base image. Then we copy and install the dependencies listed in requirements.txt. Afterward, we copy our directory contents into a new directory named /app and initialize it as our work directory. Finally, the last line of code spins up the Streamlit app.

To test the Docker image out locally, the two lines of command below would build the Docker image and run the container;

$ docker build -t app:latest .
$ docker run app:latest

This would spin up the Docker container locally and you’d access it via the displayed network URL.

Deploying to Heroku Container Registry

To deploy to Heroku, the commands below would be needed;

$ heroku login
$ heroku container:login
$ heroku create app_name
$ heroku container:push web
$ heroku container:release web
$ heroku open

The first two lines of command are needed to log in to Heroku and Heroku Container respectively. The next line of command creates the app on Heroku using the name specified. The next line builds the image and pushes it to Container Registry. The following line of command releases the image to the app while the final line opens the now deployed app in your browser.

But even with doing this for my project, my Docker image size is still 3GB+ and it takes forever for the deployed web app to load. :(

Reducing your image size: If it’s Streamlit, don’t use Alpine!

While researching on how to resolve this bottleneck, using Alpine Linux was what almost every resource out there recommended. So I used it and my Docker image just won’t build. It couldn’t install some of Streamlit’s dependencies.

I researched why “Captain America, but for smaller image sizes” won’t save me when I needed it the most, and I stumbled upon this awesome article on why Alpine is not the best guy for smaller image sizes when it comes to Python Docker. Turned out that standard PyPi wheels don’t work on Alpine and Streamlit has those lovely wheels in abundance. :(

So I replaced “Alpine Linux” with “Python-slim” as my base image. I also used the “ — no-cache-dir” flag in “pip install” so it won’t store the installation files of the packages in the cache after installing them.

Doing this dramatically reduced my project’s docker image size from almost 4GB to just a little over 300MB. Whoop whoop!

Automating subsequent deployments with GitHub Actions

If you’d like to keep making changes to your web app without having to use “heroku container:push” and “heroku container:release” every single time, GitHub Actions workflow is the next DevOps tool to make use of. GitHub Actions can be used to automate the deployment part of your development workflow, which means you don’t have to push manually to Heroku again after the first initial push.

All you need to do is to create the CI.yml file in your project directory, in the format below;

.github -> workflows -> CI.yml

The CI.yml would contain lines of code like those below;

The “name” key describes the purpose of the CI.yml file. The “on” key triggers the workflow anytime a push is made to the main repository. Within the “job” key are the Heroku commands to log in, push the new build, and release the new build to the web app.

Finally, to allow access to Heroku, an access key should be added to GitHub Secrets. To generate the authentication key, the line of code below would do that;

$ heroku authorizations:create

Copy the generated key and save it in your GitHub repository by navigating to Settings →Secrets →New repository secret. I’d name the secret key as “HEROKU_API_KEY” to match the variable name used by Heroku, even though you can change the name to any word you like. You should make sure that you make use of the same name in the workflow file.

Other useful tips

I don’t want this article to get longer than necessary and the tips below are not specifically related to deployment, as they are Streamlit’s internal techniques to make the app’s memory size more efficient. So I’d just mention them here but I might write an article on them later though.

• Remove static files from your project’s directory, as they’d add to the bulk of your file. Your app would be better off if those static files are saved on, say Amazon s3, and are loaded into your app via URLs, which leads us to our next tip;
• Use st.cache as much as possible. Files or functions not used very much, like pd.read_csv, should be cached religiously. This means that the cached files won’t be reloaded every time you interact with your web app.
• Use session state to store variables across reruns. Asides from helping with the reloading time, this honestly saved me the whole lot of stress attached with writing lots of functions to make sure that my variables are permanently stored for reuse.

In conclusion;

In this article,

• I explained why you should use Docker to deploy on Heroku instead of deploying your web app straightaway on Heroku.
• I also elaborated on how to reduce the Docker image size by using Python-slim as your base image.
• We also explored how to use GitHub Actions to automate subsequent deployments.
• Finally, we went through other useful techniques to help keep the size of our app down.

Thank you for coming this far. Happy Streamlit’ing!

Feel free to connect with me on LinkedIn and Twitter. I’d be happy to take any of your questions or Streamlit freelancing gigs :)