Running the TICK Stack on a Raspberry Pi

8 minutes
Two Raspberry Pis and some InfluxData Stickers
The Raspberry Pi is a great platform for the TICK Stack!

Since its introduction in 2013, the Raspberry Pi platform has grown by leaps and bounds, gaining popularity and showing up in projects all over world, from quick hacks to fully commercialized products. It’s an inexpensive, low power, open-source, single-board computer with a variety of interfaces for connecting with sensors and actuators that can be used to interact with the physical world.

It’s also a solid choice when you need an always-on device for collecting data, and it’s powerful enough to run the complete TICK Stack. In fact, one of the most popular posts on our community site is about running the TICK Stack on a Raspberry Pi, so we wanted to provide some update instructions for installing and things to consider while operating the stack.

The Hardware

Your Choice of Pi

The first thing you’ll need to do is decide which Pi you’re going to use. The Raspberry Pi platform has gone through a few iterations since it was first released in 2013:

Model Cores Clock Speed RAM
Zero 1, 32-bit 1000 MHz 512 MB
A/B/+ 1, 32-bit 500 MHz 256 MB
2B 4, 32-bit 900 MHz 1024 MB
3B 4, 64-bit 1200 MHz 1024 MB
3B+ 4, 64-bit 1400 MHz 1024 MB

There have been some significant architectural improvements over the years, and your best bet is to go with one of the model 3 boards, with quad-core, 64-bit CPUs for the database itself, although I’ve tested running the complete TICK Stack on the model 2 B, 3 B, and 3 B+. In addition, the single-core Zero makes a great platform for collecting sensor data with Telegraf.


The storage system on the Raspberry Pi, which uses an SD or microSD card, is the slowest by far relative to the systems on a laptop or desktop computer, so it’s important to keep in mind storage performance when you’re considering a Raspberry Pi for your application. Which SD card you choose will have a major impact on the performance of your Raspberry Pi, especially if you’re planning on running a database like InfluxDB.

Get at least a Class 10 Card—the faster, the better. But understand that even with the fastest SD card, performance won’t come close to what you would get with an SSD, and this can often be the bottleneck for your applications.

Some manufacturers are also releasing “High Endurance” SD cards; I haven’t had a chance to do much research about them, but if you plan on writing large volumes of data, it might be worth investigating.

The Raspberry Pi 3 B and B+ also have the ability to enable a USB boot mode, although this is a permanent change for your device. While you’ll still be constrained by the speed of a USB 2.0 port, this would enable you to run a large-capacity SSD with better speed and performance.


The most common way to use a Pi is with the Raspbian operating system provided by the Raspberry Pi foundation, so that’s what we’ll be using in this blog post. Raspbian is based off the Debian distribution of Linux, with some modifications and utilities like raspi-config that contain functionality specific to the hardware. The latest version of Raspbian is April release based on Debian Stretch.

You can download Raspbian and find installation instructions on the Raspberry Pi foundation’s website.

Recommended: Install from the Official InfluxData Repository

The easiest way to install the TICK Stack is to set up the InfluxData package repository (repo) and use your platform’s package manager, which on Raspbian is apt. Packages contain the application binaries themselves, as well as some information about where and how to install and configure the application on your system. That means you can get everything up and running with just a few commands, and InfluxData regularly publishes the latest versions of the TICK Stack to its repository, so applying updates is easy as well.

The first step is to set up the InfluxData repo. You’ll need to identify which version of Raspbian you’re running, which you can do by taking a look at the /etc/os-release file. Run the following command:

$ cat /etc/os-releases
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION="9 (stretch)"

We need the version codename, which you can find in the VERSION field, in parentheses. For the version I’m running, 9, the code name is stretch. We’ll use that when we set up our repo so that we can get the correct versions for our OS.

Next, add the repo’s GPG key and add the repo itself:

$ curl -sL | sudo apt-key add -

and then add the repository:

$ echo "deb stretch stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Finally, run sudo apt-get update to refresh the package list with data from the new repository, and install the TICK Stack using sudo apt-get install telegraf influxdb chronograf kapacitor. If you want to only install some components of the stack, you can exclude the applications you don’t want from that command.

It’s also possible to download packages and install them yourself, without setting up the InfluxData repository. You probably don’t have a good reason for doing this, but for those who do, head over to our downloads page.


Docker is another great option for running the TICK Stack on a Raspberry Pi, and is what I use at home. Docker is an OS-level virtualization technology, which means that it isolates various applications by making it appear as though they each have their own Linux kernel and environment to run in. This provides isolation for your applications, while the Docker runtime provides easy-to-use tooling for creating and managing containers.

The recommended method for installing Docker on Raspbian is using the convenience script; you’ll also probably want to install docker compose.

You can refer to my Docker blog post from last week for more details about running TICK in docker containers, and I’ve written a simple Docker Compose file to help you get started.

Manual Options: Binaries and Building from Source

A few other options exist which provide additional level of manual control over how you want to build and install your applications. You can download a Linux binary from, or you can visit the respective Git repositories (Telegraf, InfluxDB, Chronograf, and Kapacitor), check out the code, and build the applications yourself.

Other Considerations

Since the Pi is a relatively constrained computing environment, you might have to make some tradeoffs in terms of how much software you can run and how much data you can process and store.

One thing to consider is that you don’t have to run Chronograf on the Pi; you can run a local copy on your primary computer, and set it up to talk to the InfluxDB instance on your Raspberry Pi over the network. This is the setup I’m currently running at home, and I find that it gives a nice performance bump over running everything on the Pi.

Another thing to keep in mind is the amount of storage space you have on your SD card. While InfluxDB is quite efficient at storing data, depending on the size of your card, the other software you have installed, and how much data you’re writing, it is possible to run out of space. You should definitely set up some kind of monitoring and alerting so that you can be informed when you run out of space. Telegraf’s disk plugin and Kapacitor’s alerts functionality would be a good fit for this!

You also might not need to keep your data around forever; a few weeks or months might be good enough for your use case. We often see users taking advantage of into InfluxData’s downsampling and retention policy functionality to reduce the resolution of their data and automatically delete it when it has reached a certain age. For more information on why you might want to do this, check out our recent training webinar, Downsampling Your Data.

That’s It!

Hopefully this post got you up and running, but if you have any questions or comments please feel free to reach out to me directly on Twitter @noahcrowley or feel free to post your comments on our community site at And if you build something great with Influx, don’t hesitate to let us know, there might be a hoodie in it for you!

Related Blog Posts

4 thoughts on “Running the TICK Stack on a Raspberry Pi”

  1. Hi, I’m hoping you can elaborate on this article about running Influx DB on an RPi with SD card to specific recommendations about running InfluxDB on an embedded Linux system. I think it could be a good fit for archiving sensor measurements on systems without a constant internet connection. Consider the following embedded Linux system with storage options:

    – a small, fast-read raw flash device like SPI-NOR (e.g., QSPI)
    – a larger, fast-write flash device like SD card or eMMC
    – availability of in-memory temp file system like tmpfs

    Here are a few questions along with my best guesses after scanning the links at the bottom:

    1. What are the best-fit storage locations for influxdb program, WAL and data dir? Despite the lower read speed, the data dir should be on the high capacity SD card because it won’t fit anywhere else as the data increases in size. The influxdb executable would ideally be on the QSPI (if there’s room, mounted RO) to be read in quickly, but SD card is acceptable because read happens just once at bootup typically. The WAL is written to a lot, so it should be on the SD card if durability is important. If it’s not important and I don’t mind losing uncommitted data during power loss but I want to reduce wear on the SD card, then not using it at all (if possible) would be better than putting it in tmpfs because the in-memory cache already serves that purpose. In most use cases, SD card’s wear leveling would handle the longevity issues transparently, so it wouldn’t be a major concern.

    2. How do each of these options interact with kernel disk cache? Every write to the WAL is fsynced immediately after, so the in-kernel cache is effectively nullified for writes. For reads, it’s still very applicable because the TSM files are read only and easily cached.

    3. Assuming the file system storing the WAL and TSM files is robust to power failure corruption, resulting only in potential loss of recent file changes / data, is there any situation in which influx DB could leave its required files in an unrecoverable, intermediate state?

    Thanks very much.

  2. Hi, I have a few questions about running influx on an SD card.

    1. If I wanted to store the WAL and TSMs of influx on an embedded system with SD card, with the only IO to the SD card being done by influx, and sudden power loss to the system is in fact very likely, then what filesystem do you recommend to best support influx’s IO patterns and prevent FS corruption?

    2. If power is lost to the system, even if the file system is not corrupted, could influx ever leave its own files in an unrecoverable, intermediate state?

    3. Does writing multiple points to the DB simultaneously as a batch reduce fsyncing frequency?

    4. If I put the WAL in a tmpfs volatile memory file system, is the only consequence of power loss the loss of uncommitted data?


  3. Correction:
    The command to find out the OS-release is : $ cat /etc/os-release (not …releases).
    In the explanatory text, the command is spelled correct.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top