With the hardware running, the network sorted and CasaOS managing our containers, it's time to talk about the applications that make the HomeLab useful. After three years of experimenting, we've settled on a core set of services that we use for everything from client projects to daily operations.
In this post I'll go through the main applications running in the Alpha Bits HomeLab, why we chose each one, and how we've configured them to work together.
Purpose-built, not everything at once
Early on I made the classic mistake of deploying every interesting application I found. Media servers, monitoring tools, development environments, automation platforms: if it had a Docker container, I probably tried it.
I ended up with a sprawl of services that ate resources, needed constant maintenance and gave me very little back. I spent more time managing the infrastructure than using it.
Now every application has to serve a specific purpose in our business or in what we're trying to learn. If it doesn't help with client work, team productivity or skill development, it doesn't get deployed.
The core stack
Node-RED
If I had to pick one application that shows what HomeLab infrastructure can do, it would be Node-RED. This visual programming tool now sits in the middle of almost everything we run.
We use it to collect and process sensor data from client IoT deployments, connect systems and services that were never designed to talk to each other, automate repetitive business processes, run ETL jobs for analytics and reporting, and send alerts, reports and status updates.
One example: a Node-RED flow monitors our I.C.E. Battery thermal storage installations. It processes 10,000+ sensor data points daily in real time, stores them in InfluxDB, triggers alerts for anomalies and generates reports. The entire pipeline runs on a Raspberry Pi 4.
A word of caution, though. A tiny bug in a flow, literally one missing character, can bypass a safety limit, overpower a system and instantly melt wiring. I know this from personal experience. When software flows control physical hardware, test obsessively and build in failsafe nodes.
Node-RED is in the CasaOS app store with ARM optimization. The deployment sets up persistent data volumes for flows and configuration, environment variables for security settings, network configuration for MQTT and HTTP endpoints, and automatic restart policies.
We've tried writing traditional code, cloud automation platforms and other workflow tools. Node-RED wins for us because non-developers can follow a visual flow, the library of pre-built nodes is huge, it runs well on ARM, the community is active, and it's ideal for prototyping and iterating quickly.
Databases: PostgreSQL, Redis and InfluxDB
Our projects need different kinds of storage, so we run three databases.
PostgreSQL
PostgreSQL is our main relational database. It holds Directus CMS data, client application databases, user management and authentication, and business logic and transactional data.
It runs on our Pi-Data device with 8GB RAM and handles multiple databases and concurrent connections comfortably. The ARM64 builds are mature.
Redis
Redis handles API response caching, session storage and real-time data sharing between services. It's memory efficient, which matters on a Raspberry Pi where every MB counts. We give Redis about 256MB, enough for our caching without starving other services.
InfluxDB
For IoT and monitoring data we use InfluxDB. It stores sensor data from our I.C.E. Battery installations, system performance metrics and application analytics. The compression is very good: 10,000+ data points daily barely dents disk usage. One tip: put InfluxDB on an SSD, not an SD card. The write patterns will kill an SD card within months.
Directus
We've covered Directus in previous posts, but it belongs on this list too. It runs in Docker via CasaOS and handles content management for our website and blog, provides the API backend for client projects, gives non-technical team members an admin interface, and lets us model data without custom development.
It runs well on ARM, which makes it a good fit for our distributed setup.
Monitoring: Grafana and Uptime Kuma
Grafana
Grafana connects to our data sources for system performance dashboards, IoT sensor data, business metrics and KPIs, and client project monitoring.
Being able to build custom dashboards and share them with clients has helped a lot, both to show them what they're getting and to keep things transparent.
Uptime Kuma
Uptime Kuma monitors all our services. It checks HTTP/HTTPS endpoints and database connections, alerts us before SSL certificates expire, and gives clients good-looking status pages.
It's lightweight and pleasant to use, which suits a HomeLab.
Development and productivity tools
Code-Server
Running VS Code in a browser sounds odd, but it's very useful. We get the same development environment on every device and can reach our codebase from anywhere without syncing configurations between machines. It's ideal for quick edits and configuration changes.
FileBrowser
FileBrowser gives us secure file access through the browser. We use it to upload and download files on any Pi, edit configuration files directly, share files with team members, and run backup and restore operations.
How everything works together
Most of the value comes from how these applications connect.
Data flow example: IoT monitoring pipeline
- Sensors send data via MQTT to Mosquitto broker
- Node-RED processes and enriches the data
- InfluxDB stores time-series data
- PostgreSQL stores device metadata and configurations
- Grafana visualizes data in real-time dashboards
- Uptime Kuma monitors the entire pipeline
Content management workflow
- Directus provides content creation interface
- PostgreSQL stores content and metadata
- Redis caches frequently accessed content
- Node-RED handles webhook notifications
- Cloudflare Tunnel exposes APIs to the public
Deployment practices
We spread applications across devices based on what they need most:
- CPU-intensive: Node-RED flows, data processing
- Memory-intensive: Databases, caching layers
- I/O-intensive: File management, backup operations
- Network-intensive: API gateways, monitoring
For data persistence, critical data lives on USB SSDs with regular backups. Cache data stays on local storage with automatic cleanup, logs go to centralized logging with rotation, and configuration is version controlled and backed up.
On security, internal services are reachable only over ZeroTier. We use strong passwords and API keys, update containers regularly with Watchtower, and alert on unusual activity or failures.
What actually works on ARM
After running these applications for months, this is how they've performed.
Excellent on ARM:
- Node-RED: Handles complex flows without issues
- Redis: Memory efficiency is perfect for Pi constraints
- Uptime Kuma: Lightweight and responsive
- FileBrowser: Fast file operations
Good on ARM:
- PostgreSQL: Solid performance with proper tuning
- Grafana: Some lag with complex dashboards
- Directus: Good for moderate traffic
Needs some optimization:
- InfluxDB: Benefits from SSD storage
- Code-Server: Better on higher-memory Pis
Cost
Every application in our stack is open source: Node-RED, PostgreSQL, Redis, InfluxDB, Directus, Grafana, Uptime Kuma. Total software licensing cost: $0/month. The only costs are hardware (covered in our hardware guide) and electricity, about $3-5/month for the Pis running 24/7.
Lessons learned
- Start small and scale gradually. Don't deploy everything at once. Start with one or two core applications and add others when you have a specific need.
- Watch resource usage. CasaOS's monitoring shows which applications use the most resources, which helps with tuning and capacity planning.
- Document everything. Keep detailed notes on configurations, integrations and customizations. You'll be glad of them during troubleshooting or migrations.
- Plan for failure. Critical applications need backup and failover plans, and you should test those regularly so they work when you need them.
- Use the community. The open-source communities around these applications are a great resource. Ask questions, and contribute back when you can.
What's next?
That covers the core stack. In the next post, we'll look at advanced topics and where the HomeLab goes from here.
If you have questions about specific configurations or integration patterns, the earlier posts cover a lot of it. If we missed something, it'll probably show up in a future write-up.
Next up: "HomeLab Future: Advanced Topics and What's Coming Next"