DevOps4UA

Preparing a Raspberry Pi Like a Real Server (Before Installing Anything)

Jenkins

Source: Dev.to | Jan 23, 2026 (UTC)

Introduction

In my previous post, I wrote about why I enjoy running small pieces of infrastructure at home and pressure-testing ideas outside of work.
This post is where that thinking turns practical – and where I had to actively stop myself from installing everything on day one.

Before installing any services, I wanted to understand the Raspberry Pi in its most honest, unmodified state – a fresh operating system, minimal configuration, and no assumptions. The goal wasn’t to make it useful yet, but to make it predictable.

I approached the Pi the same way I would a new Linux server. establish a clean baseline, observe how it behaves under default conditions, and understand where disk, memory, and network boundaries actually are.

Before diving into services, I want to document the baseline and mindset that shaped every decision that follows – including the exact steps and commands I ran to get there.

Nothing runs on this machine yet – and yes, that’s a deliberate choice. Because the reliability of everything that comes later depends on the discipline applied at the start.

Before we start: prerequisites

Before setting anything up, this is what I used. Nothing fancy -just the basics needed to get a clean, predictable system up and running.

Hardware

  • Raspberry Pi Zero 2 W
  • 32 GB microSD card
  • Power supply for the Raspberry Pi
  • Laptop or desktop (macOS / Linux / Windows)
  • microSD card reader (if your laptop doesn’t have one)

Software

  • Raspberry Pi Imager
  • Raspberry Pi OS Lite (Debian Bookworm–based)

No fancy gear – just the essentials needed to get a Raspberry Pi off the ground.

Downloading Raspberry Pi OS and flashing the SD card

To prepare the operating system, I used Raspberry Pi Imager, the officially supported tool from the Raspberry Pi Foundation.
You can download it from:

https://www.raspberrypi.com/software/

Here is how the website looks like!

After installing Raspberry Pi Imager on my laptop, I followed these steps:

  • Insert the microSD card into the laptop
  • Open Raspberry Pi Imager
  • Select Raspberry Pi OS (Other) -> Raspberry Pi OS (Legacy, 64-bit) Lite
  • Choose the SD card as the target storage

Before writing the image, I opened the advanced options and configured:

  • SSH (enabled)
  • Username and password
  • Wi-Fi SSID and password
  • Locale and timezone

This allows the Raspberry Pi to boot and be reachable over the network immediately – no monitor, keyboard, or desk gymnastics required.

Once configured, I flashed the OS to the SD card and safely ejected it.


Choosing the boring OS on purpose – less UI, fewer surprises later.

At the time of setup, this option installs a Debian Bookworm–based 64-bit Raspberry Pi OS Lite image.


Pre-configuring SSH and Wi-Fi to enable a fully headless first boot.

The rule I set before installing anything
Before touching any services, I set a simple rule for myself:
This Raspberry Pi would be treated like a server, not a project board.

It’s tempting to install DNS filters, VPNs, dashboards, and security tools immediately – especially when every tutorial on the internet starts with “just install this first.” But that approach often hides problems rather than solving them.

I wanted to understand how this system behaves before it does anything useful:

  • How much disk space is actually available?
  • How tight is memory?
  • What does a normal idle state look like?

By delaying installations, I could observe the Pi in a clean state and establish a baseline I could trust. That baseline becomes the reference point for every change that follows.

In practice, this meant resisting progress that only looked like progress – and choosing predictability over speed, even when speed felt more satisfying.

First boot and accessing the Raspberry Pi

With the SD card prepared, I inserted it into the Raspberry Pi, connected power, and let it boot.

Since SSH was already enabled, I connected from my laptop using the pattern below:

ssh <username>@<hostname-or-ip>

Enter fullscreen mode

Exit fullscreen mode

In my setup, the username is sid and the hostname is pihole.local.

Once logged in, I confirmed I had stable access and landed in a normal Linux shell.


Successful SSH access to the Raspberry Pi after first boot.

Establishing a baseline I could trust

Before installing anything, I wanted a clear picture of what this Raspberry Pi looked like in a known-good, idle state.

The first step was updating the system – not because it’s exciting, but because debugging problems on an outdated OS is even less exciting.

sudo apt update sudo apt upgrade -y

Enter fullscreen mode

Exit fullscreen mode

Once updated, I started checking the basics – not to optimise anything yet, but to understand the constraints I was working within.

Disk usage

df -h

Enter fullscreen mode

Exit fullscreen mode

This shows how storage is laid out and how much space is genuinely available on a fresh install. On small devices, storage fills up faster than expected, so this becomes an important reference point.


Disk layout and available storage on a Raspberry Pi OS installation.

Memory availability

free -m

Enter fullscreen mode

Exit fullscreen mode

This gives a clear picture of RAM and swap usage before any background services are installed. Whatever runs later will eat into these numbers – so this becomes my baseline.

Memory and swap usage at idle

At this point, nothing useful was running – but I now had something more important than features: a baseline I could trust.

From here on, every change could be measured. If disk usage spikes, memory tightens, or latency appears later, I’ll know exactly when – and why – it happened.

CPU (identity, not usage)

lscpu

Enter fullscreen mode

Exit fullscreen mode

This confirms the system is running on a 64-bit ARM architecture (aarch64) with a small number of CPU cores – exactly what you’d expect from a Raspberry Pi Zero 2 W.

At this stage, I’m not interested in how busy the CPU is, only in what kind of CPU I’m working with. Actual usage only becomes meaningful once services are running.

What I deliberately chose not to install (yet)

At this stage, it would have been very easy to start installing services – and I had to consciously not do that.

DNS filtering, secure remote access, monitoring, and hardening were all already on my list. But I deliberately held back.

Installing services before understanding the baseline only creates noise. When something breaks later, it becomes difficult to tell whether the issue lies with the service itself or with assumptions made earlier.

By stopping here, I kept the system in a known, explainable state – no background daemons doing work I hadn’t measured, and no configuration drift I couldn’t account for.

This wasn’t a delay. It was a checkpoint.
This was the point where I closed the terminal and walked away – on purpose.

Closing

In the next post, I’ll start adding the first real service to this system – DNS.
With a clean baseline in place, it becomes much easier to see what actually changes once something starts running.
That’s where things begin to get interesting.

Final note

Screenshots in this post are taken from a real, already running system.
Your output may differ depending on hardware, storage size, and usage – and that’s expected.

For further actions, you may consider blocking this person and/or reporting abuse

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Читайте також