Installing and maintaining SimoneBox yourself: the skills you actually need

This article is written for confirmed self-hosters and open source developers. Not beginners — and "confirmed" matters here. If you can set up a systemd service, harden SSH, and configure WireGuard without following a step-by-step tutorial, you're the right audience. If not, the box below is for you.

For those who have the skills: here is a concrete breakdown of what you'll need.

Advanced Linux — beyond the basics

Knowing how to navigate a terminal isn't enough. Installing and maintaining SimoneBox requires real mastery of Linux — not kernel-expert level, but clearly beyond "I know how to ls and cd."

You need to be able to create a dedicated user to run a service, give it exactly the permissions it needs — no more, no less — and understand why this matters. Every service running with excessive privileges is a potential attack surface.

systemd — keeping services running in the background

SimoneBox is not a script you run by hand. It's a set of services that start automatically at boot, restart on failure, and run continuously in the background. systemd handles all of that.

You need to be able to write a .service file — define the user running the service, the working directory, the launch command, dependencies. You need to know how to enable a service for auto-start, check its status, read its logs in real time, and understand why it stopped.

Security hardening — the part people tend to skip

The SimoneBox's Raspberry Pi has no open ports on grandma's router — it connects outbound as a client, exposing nothing. The central WireGuard server you host at your own home, however, does expose a UDP port to the outside world. That's the machine that's on the front line.

This section therefore applies primarily to that central server. That's where SSH must be hardened, where fail2ban must run, and where the firewall must be carefully configured. The SimoneBox itself, behind grandma's NAT, receives no inbound connections and doesn't need these protections.

These skills can't be improvised. You need to have already administered an exposed server, already locked yourself out of your own firewall, and understood why. Hands-on experience is irreplaceable here.

WireGuard VPN — the most complex piece

This is probably the trickiest part of the entire installation. And it's also the one that makes remote maintenance possible — without which a SimoneBox quickly becomes unmanageable if you don't live at your grandparent's home.

A note on architecture first: the touchscreen tablet and the Raspberry Pi are a single physical unit. The Pi is screwed to the back of the screen. They are never separated. The whole thing — the SimoneBox — sits at grandma's home, connected to her ISP router. No port is opened on that router. The SimoneBox has no fixed IP address and doesn't need one.

The technical solution is a hub-and-spoke VPN using WireGuard. The WireGuard server runs at the maintainer's home — on their own router, where a single UDP port is opened. The Raspberry Pi inside the SimoneBox connects as a client to that server, outbound, as soon as it boots. Family members' phones do the same.

The result: everyone ends up on the same private virtual network, regardless of which ISP router grandma has, regardless of what her current IP address is. The SimoneBox can move, switch routers, change locations — it finds the tunnel on its own.

WireGuard is well-documented, and its configuration is more readable than OpenVPN's. But it's still a hub-and-spoke VPN — and setting up the central server requires understanding what you're doing. A mistake leaves all clients outside the tunnel, or worse, inadvertently exposes services that shouldn't be reachable.

Python and Flask — the web app at the core

The brain of SimoneBox is a web application written in Python with Flask. It's what serves pages to the tablet, triggers image updates, and orchestrates the different modules. You don't need to have written one from scratch to maintain it — but you do need to be able to read and modify Python code without getting lost.

Routine maintenance means knowing how to update dependencies, understanding why a module changed its API between two versions, debugging a Python traceback, and occasionally modifying a function to adapt behaviour to a new RSS feed or image source.

Monitoring and updates — don't let the system age out

A system running without supervision will eventually have problems — full disk, expired certificate, outdated dependency with a security vulnerability. Monitoring doesn't need to be sophisticated, but it must exist.

The minimum: occasionally check that services are running, that the disk isn't filling up, and that the logs don't contain repeated errors. Going further, you can set up something that sends an alert if a service goes down or disk space drops below a threshold.

Automatic security updates take care of themselves once configured. But Python dependency updates require manual intervention — test them on a development machine before deploying, verify nothing breaks.

Adapting RSS feeds — recurring maintenance

SimoneBox's content comes from RSS feeds. These feeds change. Sources modify the structure of their pages, change their URLs, evolve their data formats. What worked six months ago may not work today — not because SimoneBox is broken, but because the source has changed.

Maintaining SimoneBox long-term means maintaining these external connections too. When a news source changes its format, you need to be able to identify the new format and adapt the script. It's not daily work — but it's work that comes up.

What distinguishes a maintained system from an abandoned one isn't the quality of the initial code. It's the ability to adapt it when the world around it changes.

Building a community around this project

If you've read this far and recognise these skills as your own, you are exactly the profile SimoneBox needs to exist beyond a personal project.

What's missing for other families to benefit from it: structured installation documentation, reproducible scripts, people who can debug edge cases and update the code when RSS feeds change. Not the same profile as the end user — but just as essential.

I don't yet know what form this community will take. A few motivated people are worth more than an empty forum. If you think you could contribute — even occasionally — now is the time to say so.

To understand what SimoneBox actually does day-to-day — before deciding whether to install it — here's what Simone sees and what runs behind the screen →