Monitor from anywhere. Literally anywhere.

Read more

Deploy private locations on a Raspberry Pi

Deploy private locations on a Raspberry Pi
MK
Maximilian Kaske
5 min read
engineering

We just pushed the first version of Private Locations at openstatus - and I had to test it on my old Raspberry Pi 3.

Since 2016, I've been using the Pi for AirPlay to connect to my receiver but other than that, it's been sitting around without any other use case.

Time to revive it!

My bare metal Raspberry Pi on top of the receiver I use for AirPlay
bare metal raspberrypi on a receiver

Deployment Guide

Obviously connecting to the Raspberry Pi via ssh - and if you're like me, the default password is secure enough:

Hardware Specs

I didn’t know exactly which Debian version it was running, but it was very old - so I took the opportunity to clean everything up and upgrade to the latest available version.

Model:

Linux Kernel:

Operating System:

I'm running the OS on a 16GB micro SD card. The Pi has 1GB of RAM, which is perfectly enough for this use case.

Statistics from htop command
htop stats

Install Docker Image

Let's freshly install Docker using the official Debian repository instructions:

https://docs.docker.com/engine/install/debian/#install-using-the-repository

Once installed, Docker should already be running.

You can verify it with:

Pull and Run the OpenStatus Container

Let's grab the image:

If you have access to Private Locations in the Dashboard, create one - it'll will provide you a token to use as an environment variables:

Create a private location
dashboard create private location form

Add the token to your shell profile:

Reload the shell profile:

If you are using oh-my-zsh you might be using the ~/.zshrc file instead.

Check that it worked:

Run the Container

Now let's launch it:

What these flags do:

  • -d: run in background (detached mode)
  • --restart: auto-start on reboot
  • --name: give it a nice readable name
  • -e: pass your env var into the container

Don't sleep on --restart=always! How often I had to quickly switch position of and need to reboot the Raspberry, this is a game changer.

To see live logs:


What Happens Next

Once the container is up, openstatus automatically fetches the endpoints you've chosen for this private location and starts monitoring them.

Every few minutes (last_seen_at), the agent refreshes its internal database to stay up-to-date with any changes - like added monitors or updated headers.

The responses of the pings are sent to our ingest endpoint for storage and aggregation.

Access your logs within the openstatus Dashboard.
response logs in the openstatus dashboard

Light on Resources

Our Docker image is just 8.5 MB in size. Compare that to 1GB+ for some competitors (yes, they pack more features, but still 🤯).

It's wild that a tiny 1 GB-RAM device from 2016 can now handle this so easily.

Why Private Locations?

Running a private probe means your checks happen from within your own network - not just from public cloud servers.

It’s useful for:

  • Monitoring internal applications or databases
  • Testing network latency from real-world locations (like your office or home)
  • Running low-cost monitoring nodes on tiny devices (e.g. in agriculture or industrial setups)

Closing Thoughts

And that’s it - my Raspberry Pi (2016) is officially back in action. Running quietly next to my receiver, it’s now part of the openstatus network, checking endpoints from my home.

Not bad for a 9-year-old piece of hardware.

If you'd like to try this out yourself, contact us (discord, email) and head over to:

https://github.com/openstatusHQ/openstatus/pkgs/container/private-location

Private locations are currently in beta and we're gathering feedback from early users. If you've got an old Raspberry Pi lying around - this is your excuse to bring it back to life.


A few more useful Commands

Deploy private locations on a Raspberry Pi | openstatus