Stacklight: A Deep Dive into the Zero-Backend Native iOS Homelab Monitoring App

For enthusiasts in the self-hosted community, securely and conveniently monitoring and controlling their homelab from a mobile device has always been a persistent pain point. Self-hosting refers to users choosing to run services and applications on hardware they own and control, rather than relying on third-party cloud providers. The homelab is the physical embodiment of this philosophy—typically consisting of one or more servers, NAS storage devices, and networking equipment, running software stacks ranging from virtualization platforms to media servers. The core driving force behind this community is data sovereignty: users want complete control over where their data flows, where it's stored, and who can access it, free from any commercial company's privacy policy changes or service disruptions.

Most monitoring solutions on the market either rely on cloud relay, require additional backend services, or are simply cookie-cutter status grids lacking targeted operational capabilities. Recently, a native app called Stacklight made its debut on the r/selfhosted Reddit community, offering its own answer through a remarkably aggressive privacy-first architecture.

Core Philosophy: A Truly "Zero-Backend" Architecture

Stacklight's biggest selling point lies in what the developer repeatedly emphasizes—it has no backend server whatsoever. In today's app ecosystem where "cloud sync" and "account systems" are the norm, this shows remarkable restraint.

The developer explicitly defines its privacy boundaries: no Stacklight servers, no analytics or telemetry of any kind, and no third-party SDK integrations. Every framework linked in the entire app comes exclusively from Apple. This means your data flow never passes through any intermediary.

At the implementation level, several design details are worth noting:

• Credential Storage: All account passwords are stored in the iOS Keychain, encrypted at rest locally by the system, and never leave the device. The iOS Keychain is Apple's built-in credential management system that uses hardware-level encryption (based on the device's Secure Enclave chip) to protect sensitive data. Unlike regular app sandbox storage, data in the Keychain is extremely difficult to extract even on jailbroken devices, because encryption keys are bound to the device hardware. Each app can only access Keychain entries it has stored itself, and system-level access controls ensure data isolation between apps, making the Keychain the industry best practice for storing highly sensitive information like API keys and passwords.
• Configuration Sync: Service configuration information (URLs, names, environments, etc.) syncs through the user's own iCloud account, not the developer's servers.
• Direct Communication: Every integration is an HTTP client that connects directly to your own service's API—no relay, no proxy, no middleman.

For self-hosting enthusiasts who treat "data sovereignty" as a matter of principle, this architecture is practically tailor-made—your homelab data always remains in your own hands.

Security Design: A Detailed Look at the TOFU Certificate Pinning Mechanism

A common technical challenge in homelab scenarios is self-signed certificates. On the public internet, HTTPS certificates are issued by trusted Certificate Authorities (CAs), and browsers and operating systems have these CAs' root certificates built in, forming a complete chain of trust. However, homelab services typically run on internal IPs or local domain names and cannot obtain free publicly-trusted certificates like Let's Encrypt through domain validation. Tools like Proxmox (an open-source virtualization platform) and TrueNAS (a network-attached storage operating system) generate self-signed certificates by default during installation. While these certificates provide encrypted transport, they aren't in any public CA's chain of trust and will be rejected by standard TLS validation procedures. This forces users to either deploy an internal CA (using tools like step-ca or mkcert) or manually trust each certificate on the client side. Many apps simply provide a global "allow all insecure connections" toggle as a workaround, which essentially trades security for convenience.

Stacklight rejects this lazy approach. It employs a TOFU (Trust-on-First-Use) certificate pinning mechanism: on first connection, it records and pins the certificate, then validates against it on subsequent connections. TOFU is a security model for establishing trust relationships in the absence of pre-established trust anchors. Its most well-known application is the SSH protocol—when you first connect to an SSH server, the system prompts you to confirm the server fingerprint; once confirmed, that fingerprint is recorded, and subsequent connections will trigger a warning if the fingerprint changes. The core tradeoff of this model is: it cannot defend against man-in-the-middle attacks during the first connection, but it effectively prevents downgrade attacks and certificate substitution attacks on all subsequent connections. Compared to the traditional PKI (Public Key Infrastructure) trust model that relies on hierarchical certificate authority chains, TOFU is far more practical for homelab scenarios.

The developer specifically emphasizes that there will "never" be a global "ignore all certificate errors" toggle in the app. This design strikes a pragmatic balance between security and usability: it accommodates the real-world need for self-signed certificates while avoiding exposing users to man-in-the-middle attack risks. For security-conscious users, this detail is quite convincing.

Deep Control Capabilities Across 23 Integrations

If the privacy architecture is Stacklight's skeleton, then its rich service integrations are its flesh and blood. The developer deliberately avoids creating a "cookie-cutter status grid," instead designing detail views tailored to each of the 23 integrations' specific characteristics, providing real control capabilities wherever the API allows.

Server & Storage Management

This covers TrueNAS, Synology, Unraid, and Proxmox. Proxmox supports starting, stopping, and restarting virtual machines; Docker containers can be restarted via Portainer; and Linux hosts are monitored through Glances. Glances is a Python-based cross-platform system monitoring tool that exposes real-time metrics including CPU, memory, disk I/O, network traffic, and process lists through a REST API. Unlike heavyweight monitoring stacks like Prometheus + Grafana, Glances' advantage lies in lightweight deployment—a single command launches it in web service mode, making it ideal for homelab scenarios where long-term historical data storage isn't needed and real-time status viewing suffices.

Network & Media Services

On the networking side, it integrates Pi-hole (with ad-blocking toggle), AdGuard Home, Nginx Proxy Manager, and OPNsense. In the media realm, it includes Plex, Jellyfin (with session termination), the *arr suite, Overseerr (approve/deny requests), as well as qBittorrent and Transmission (pause/resume downloads).

The *arr suite is the self-hosted community's collective term for a series of media automation management tools ending in "arr," including Sonarr (TV show management), Radarr (movie management), Lidarr (music management), Prowlarr (indexer management), and more. These tools work together to form an automated pipeline from content discovery to downloading to library organization. Overseerr serves as the frontend request portal for this pipeline, allowing family members to submit viewing requests through a friendly interface while administrators can approve or deny them. The entire ecosystem embodies the self-hosted community's Unix philosophy of "one tool does one thing."

Documents, Monitoring & Smart Home

Document and photo management supports Immich and Paperless-ngx; monitoring covers Uptime Kuma, Scrutiny, and Bitaxe; smart home and development scenarios connect to Home Assistant (automation and switch control) and Gitea.

Uptime Kuma is a popular open-source self-hosted monitoring tool that monitors service availability through various probe methods including HTTP, TCP, and DNS, providing beautiful status pages and multi-channel alert notifications. Scrutiny focuses on hard drive health monitoring, reading S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) data to assess disk lifespan and failure risk—critical early-warning capability for homelab users who heavily rely on consumer-grade drives. Bitaxe is an open-source Bitcoin ASIC mining hardware project, appearing here as a monitoring target, reflecting the trend of some self-hosting enthusiasts incorporating cryptocurrency mining into their homelabs.

This "tailored-to-each-service" design philosophy is far more practical than simply listing online/offline status, truly turning your phone into an operations console for managing your homelab.

Apple Watch: A Read-Only Design Philosophy

Stacklight also provides a native Apple Watch app, letting you view the aggregated health status of your entire stack as well as each service's individual status from your wrist.

Notably, the developer deliberately designed the Watch app as read-only. His reasoning is straightforward: "Accidentally shutting down a VM is not a feature I want to ship." Behind this statement lies a mature product philosophy—on a small-screen, easily mis-tapped device, deliberately limiting dangerous operations demonstrates more responsibility to users than piling on features. This design approach aligns with the Principle of Least Privilege: each interaction interface should only possess the minimum operational permissions needed to accomplish its core task. The Apple Watch's core use case is a quick glance to confirm status, not executing complex operational tasks.

Conclusion: A New Privacy-First Choice for Homelab Management

Stacklight's emergence reflects the self-hosted community's growing demand for privacy and data sovereignty. With its pristine "no backend, no telemetry, no third-party" architecture, combined with deep integration across 23 mainstream services, it offers a compelling solution for mobile homelab management.

Of course, a purely local architecture also means certain tradeoffs: for example, the lack of server-side historical data retention across devices, and configuration sync being entirely dependent on the iCloud ecosystem. Additionally, as a native app bound to the Apple platform, it naturally excludes Android users. But for self-hosting enthusiasts who are already deeply invested in Apple devices and extremely privacy-conscious, these limitations may be precisely what makes it trustworthy.