FAQ

Is there any advantage in running DeQ on a bigger homelab setup instead of a Pi?

While DeQ works great on a Pi, it wasn't designed for it. But the fact that it does is proof of the lightweight architecture. Shifting it to a more capable homelab machine offers these practical benefits:

Better Performance and Responsiveness

The dashboard, file manager (especially uploads/downloads, zipping, or browsing large directories), and polling multiple remote devices via SSH can feel snappier on faster CPU/multi-core systems with more RAM. On a Pi (especially older or Zero models), heavy file operations or managing many devices might introduce lags.

Handling Larger/More Complex Homelabs

If your setup includes dozens of devices, VMs, containers, or frequent large file transfers/backups (rsync across network), a bigger machine manages the load more easily without straining resources. The Pi remains fine for small setups but can bottleneck under heavier concurrent use.

Improved File Manager Experience

Dual-pane operations, uploading big files, or compressing/extracting archives run faster and more reliably with better I/O (e.g., NVMe SSD vs. SD card on Pi) and more RAM for buffering.

Room for Co-Running Services

On a Pi, you might hesitate to overload it with other tasks. A dedicated mini PC or server lets DeQ coexist comfortably with demanding services (e.g., Plex, Frigate NVR, Home Assistant, or VMs) without competition for resources.

Future-Proofing

More horsepower supports potential future enhancements (the project is actively developed), custom scripts, or integrating with heavier tools. The Android app's advanced polling/notifications also benefit indirectly from a more responsive host.

Stability and Heat/Power Trade-Off

x86 mini PCs (e.g., Intel N100 or older i5/i7 systems) often run cooler and more stably under sustained load than a Pi pushing its limits, though they consume more power (counter to the project's energy-efficiency ethos).

Bottom Line

The core philosophy of DeQ favors minimalism and low power, so a Raspberry Pi is often the ideal spot for it - especially if you already have one always-on for light duties. Running on bigger hardware doesn't unlock new "locked" features (since it's not resource-intensive by design), but it enhances the experience in larger or more demanding homelabs. If your setup is modest, stick with the Pi to align with the project's spirit!

Is DeQ's minimal approach equal to a lack of features?

No. DeQ's minimalism isn't about having the fewest possible features or being a bare-bones status monitor - it's about minimal overhead, dependencies, and complexity in deployment/runtime while delivering practical, hands-on control for a typical homelab.

Here's why those "advanced" features align perfectly with that ethos:

Single-file core with zero dependencies

Everything (dashboard, UI, file manager, scheduling, etc.) lives in one Python file (server.py). No external libraries, no pip install, no node_modules bloat, no database engine. This is radically simpler than most dashboards (e.g., Homepage, Homarr, Dashy, or Heimdall), which often pull in dozens of dependencies or require Node.js runtimes.

No Docker/containerization

DeQ explicitly rejects Docker because it adds overhead and breaks raw system access needed for real control. Instead, it runs bare-metal as root via a simple systemd service. This enables features like:

• Wake-on-LAN (raw sockets)
• Direct filesystem ops
• Host-level shutdowns

Things containers should block. We're not going to punch holes in a sandbox system.

Features are lightweight wrappers around Unix basics

In Essence

DeQ's minimalism is opinionated pragmatism. It avoids the bloat of modern web stacks and containers, but includes just enough integrated tools to replace separate scripts/CLIs you'd otherwise cobble together (manual SSH for files, cron jobs for backups, etherwake for WOL).

This reduces overall system complexity - one lightweight always-on service instead of multiple tools/services - while staying energy-efficient and dead simple to install.

Compared to "truly minimal" dashboards that are just pretty link lists with basic stats, DeQ prioritizes useful raw control without sacrificing the low-resource philosophy. That's what sets it apart.

Why no Docker? Isn't running as root a security risk?

This is the most common question - and the most important one to understand.

Why DeQ rejects Docker

DeQ could technically run in a container, but it would defeat the entire purpose. To provide actual system control (Wake-on-LAN, host shutdowns, direct filesystem access), a containerized DeQ would need:

• network_mode: host (bye-bye network isolation)
• Docker socket mounting (full control over all containers)
• Privileged mode or extensive capability grants
• Volume mounts for every path you want to manage

At that point, you've negated every isolation benefit Docker provides while adding overhead and complexity. You're running a "container" that has full host access anyway - just with extra steps.

The resilience argument

Here's something power users appreciate: DeQ stays up when everything else breaks.

When your Docker daemon crashes, when an update borks the container network, when Portainer decides it can't reach its own backend - your containerized dashboard goes down with the ship. DeQ, running as a simple systemd service, is often still reachable when everything else is on fire. That's not a hypothetical; it's a real operational advantage.

Root access in context

Yes, DeQ runs as root. Here's why that's not the scandal it sounds like:

1. It's behind your VPN. DeQ explicitly assumes you're running it on a secured network (Tailscale, WireGuard, etc.). If you're exposing your homelab dashboard to the public internet without authentication, you have bigger problems than DeQ.
2. The code is readable. All ~300KB of it. A technically competent user can audit exactly what DeQ does in an afternoon. Compare that to trusting a 200MB Docker image with layers of abstraction you'll never inspect.
3. Root enables the features you want. Raw socket access for WoL, writing anywhere on the filesystem, controlling system services - these require elevated privileges. The alternative is a dashboard that can show you things but not do anything about them.

Bottom Line

The security model is "trusted tool on a trusted network," not "sandboxed app on a hostile network." DeQ filters its audience: if you don't have your network security figured out, this tool isn't for you yet. And that's okay.

Why JSON config instead of YAML or a database?

JSON over YAML

JSON is what YAML was supposed to be but never became. YAML promises "human readable" but delivers:

• Whitespace sensitivity that causes silent failures
• Ambiguous type coercion (yes becomes boolean, 3.10 becomes float)
• Multiple ways to express the same thing

JSON is stricter (yes, you need quotes), but it's deterministic. And Python's json module is zero-cost - it's in the standard library, no dependencies.

Why no database?

A database would be overhead for what DeQ stores: a list of devices, some scheduled tasks, user preferences. That's a config file, not a dataset.

More importantly: portability. Your entire DeQ setup is one config.json you can copy, backup, version-control, or inspect with any text editor. No database migrations, no schema versions, no "oops, SQLite locked the file."

The server is the source of truth. The config is just the instruction manual.

What's with the 500KB file size limit?

This is a deliberate creative constraint - a "digital cage" to prevent scope creep.

The problem it solves

Every homelab dashboard starts lean and ends bloated. Homepage, Homarr, Dashy - they all began as simple tools and grew into dependency monsters. The developer (hi, that's me) knows this pattern intimately because I'm prone to it too.

The 500KB limit is a forcing function: if you want to add a feature, you have to earn it by optimizing or refactoring elsewhere. Features compete for space. Only the genuinely useful survive.

The finished product

The goal is a complete, stable tool at ≤500KB. Not "feature-complete and then we'll keep adding stuff." Actually complete. The kind of software you install once and forget about because it just works.

How does the Android app handle battery life?

Honestly? It doesn't micromanage it - you do.

The approach

The app uses Android's WorkManager for background health checks - efficient and battery-friendly:

• Free version: Fixed 30-minute background polling
• Pro version: User-configurable background polling (from seconds to hours)

When visual features are active (Live Wallpaper, Screen Saver, Ambient Mode), polling runs at 10-second intervals in both versions - this only happens while the feature is visible on screen.

This puts the power/information tradeoff in your hands.

Real-world impact

Long-term testing with two devices - a Samsung Galaxy S22 Ultra and a Poco F3, both with degraded batteries (~85% health) - showed under 1% battery consumption over 24 hours at 60-second polling intervals.

At 5-minute intervals (the sweet spot for most users), it's essentially invisible in your battery stats. For comparison: Tailscale, Slack, or any email client doing background sync will typically consume more.

The app itself is ~1MB. No background analytics, no telemetry, no "checking for updates" nonsense. It wakes up, pings your server, updates the notification, goes back to sleep.

How can DeQ be so lightweight?

The Unix philosophy

DeQ follows principles that have guided Unix tool design for decades:

• Do one thing and do it well. DeQ is a control layer. Not a monitoring suite, not a home automation platform, not a general-purpose admin panel.
• Text streams as universal interface. JSON config, SSH commands, stdout/stderr - everything is text you can inspect, pipe, and debug.
• Small, composable tools. DeQ doesn't replace rsync, ssh, or systemctl. It wraps them. The heavy lifting happens in battle-tested Unix tools.
• Transparency over magic. 300KB of readable code instead of black-box containers. You can understand exactly what DeQ does.

These aren't arbitrary constraints - they're a design philosophy that's proven itself over 50 years.

What "no dependencies" actually means

DeQ has dependencies. Lots of them: Linux, Python, SSH, rsync, systemd - the entire Unix ecosystem.

What DeQ doesn't do: pull in external Python libraries. No pip install, no requirements.txt, no virtualenv. Everything comes from Python's standard library: subprocess, socket, json, http.server.

The distinction matters. DeQ uses what your operating system already provides instead of adding abstraction layers on top. When you run DeQ, you're running Linux tools through a thin Python wrapper - not a parallel universe of npm packages.

SSH as the universal interface

Here's what DeQ actually is: an SSH wrapper with a web UI.

Almost everything DeQ does on remote devices goes through SSH:

No agents to install on remote machines. No proprietary protocols. No ports to open beyond SSH (which you already have). If you can SSH into a device, DeQ can control it.

This is why DeQ can do things containerized dashboards can't: it's not sandboxed from your systems - it speaks their native language.

Why everything lives in one file

The single-file architecture isn't a gimmick. It's enforced discipline.

When you commit to "no external libraries" and a 500KB limit, embedding the frontend is the only consistent choice. The rule is "one file." No exceptions. No "but the HTML doesn't count."

This is radical and intentional. Every time we look at the code, we're reminded to shrink it. A neatly separated project with /src /assets /styles invites bloat - a few extra lines of CSS here, another utility function there. Nobody notices. With everything in one file competing for the same 500KB budget, every line has to justify itself.

The structure is the constraint. The constraint is the quality control.

The numbers:

• Total size: 299 KB
• HTML/CSS/JS (embedded frontend): 217 KB (72.5%)
• Python (entire backend logic): 82 KB (27.5%)

The complete backend - file manager, Docker control, SSH operations, Wake-on-LAN, task scheduling, device monitoring, backup orchestration - lives in 82 KB of Python.

Built for users, not developers

DeQ isn't optimized for contributors. It's optimized for users.

We nerd out in the backend so users don't have to in the frontend. The codebase is unconventional - HTML embedded in Python, no traditional separation of concerns. That's not an accident or a limitation. It's the direct result of prioritizing user experience over developer convenience.

Users get: single-file deployment, zero libraries, instant setup and portability. A tool that just works.

Developers who want to contribute can still do so - we maintain the HTML separately during development and merge it for release. But the product isn't shaped around making contributions easy. It's shaped around making usage easy.

That's a deliberate choice. We're not apologizing for it.

Where does DeQ fit compared to other dashboards?

DeQ is an accessible control layer for your homelab. Not only a dashboard that shows you things - a tool that does things.

The ideal habitat

DeQ thrives on a small, dedicated, always-on machine: a minimal Debian netinst server, a Raspberry Pi 4, a ZimaBoard 432. From there, it controls your "Big Irons" - the Proxmox hosts, the Unraid boxes, the NAS systems that do the heavy lifting. You can also install it on your big boy. But you will lose the external control instance.

Hardware sweet spot: Pi 4 or ZimaBoard 432 class devices. Enough power for snappy UI, file transfers, and backups across your network.

Pi Zero compatibility: Yes, DeQ runs on a Pi Zero. That's not a recommendation for large networks with many containers or big file operations - it's a proof of concept for the engineering. A flex. It demonstrates just how lean the codebase is. It will even run on a WRT router BTW.

The always-on companion

DeQ is the buddy that's always there.

When you've shut down all your servers for the night, DeQ is still running on your 2W device. Right there on your nightstand, accessible from your smartphone. It's a control layer that doesn't sleep.

Low-power devices are useful anyway for files you always need access to. Sync them to your DeQ server - using DeQ itself as a scheduled task - and you have those files available even when the Big Irons are sleeping. Download them directly through the file manager on your phone or laptop. Upload new ones. And when the big server comes back online, sync the files back. Automatically, with DeQ.

No overhead from heavy operating systems or bloated applications. Just Debian netinst and DeQ. And if you want even more value from that low-power setup, throw Pi-hole on there bare metal. With an old ZimaBoard, you're looking at 2.5W idle. That's about 40 cents per month in electricity for a massive amount of utility.

When everything else fails

When your Proxmox host hangs, DeQ is still running. When Unraid becomes unresponsive, DeQ notices and the Android app tells you. As long as SSH still works, you can reboot that server remotely right from the DeQ app or web ui.

That's the core value: DeQ stays up when the things it monitors go down.

More than monitoring

You can use DeQ purely as a watchdog. But you get more value by making it your browser start page.

Open a new tab and you immediately see what's happening: which containers are running, which devices are online, what needs attention. Start the containers you need. Upload files to your NAS. Download something from your server. Wake up a sleeping machine. All without navigating through multiple interfaces.

That's why DeQ includes bookmarks and customization options - not as bloat, but to integrate into your daily workflow. The goal is to meet you where you are.

The philosophy

DeQ delivers maximum utility in a minimal package without overwhelming you with visual noise.

It doesn't demand your attention. It doesn't need focus - it focuses you. It does what a server should do: it serves. Like a good butler, it handles routine tasks silently and only interrupts you when something actually matters.

The landscape for context

The trust factor

A user can read and understand DeQ's entire codebase in an afternoon. That transparency creates a level of trust that no 200MB Docker image with layers of node_modules can match.

What about the paid app?

The paid Android app offers a straightforward value exchange: you pay money, you get tangible features.

What the paid version includes

• Configurable polling intervals (vs. fixed 30min in free)
• Possibly Future Android Auto integration (stats on your car display)
• Possibly Future Wear OS support (homelab status on your wrist)

We say possibly, because it very much depends on Google's grace if they allow these features. We can code them - but we don't know if we can deliver.

How to support DeQ

Buy the Pro app. One-time purchase, concrete features, no subscription. You get widgets, Android Auto, custom polling intervals – and you fund development. That's a fair trade.

Become a Patron. Not everyone uses the Play Store, and some people just want to support the project directly. Patreon keeps DeQ sustainable as a full-time effort.

Is DeQ trying to replace Homepage/Homarr?

No. DeQ is complementary, not competitive.

Different tools for different jobs

Homepage and Homarr excel at what they do: beautiful dashboards with extensive service integrations, widgets, and customization options. If you want a polished homepage with weather widgets, service health indicators, and a unified look for 50+ services - use them.

DeQ does things they can't do because of their containerized architecture:

• Wake up sleeping machines
• Shut down hosts directly
• Manage files across your network via SSH
• Control the Docker containers on remote machines
• Run scheduled tasks that involve actual system operations

While Homepage and Homarr do things DeQ can't do because of our 500KB self restriction. If you're a minimalist, like we are, then you can replace Homepage or Homarr with DeQ.

The typical setup

Some users run both: Homepage/Homarr as the pretty "front door" to their services, DeQ as the operational control layer running on a low-power device that's always on.

They solve different problems. There's no conflict. And it's not redundancy when you hide the bookmark section in DeQ's UI.

What's the development philosophy behind DeQ?

Core principles

1. Single-file, zero dependencies. Everything in one server.py using only Python's standard library. No pip installs, no npm, no external databases. The only dependencies are Linux, systemD, ssh, rsync.
2. Features must justify their existence. The 500KB limit forces hard choices. If a feature doesn't provide clear value to typical homelab users, it doesn't get in. It's a "kill your darlings" process.
3. Unix philosophy with a web face. DeQ is essentially a collection of lightweight wrappers around standard Unix tools (rsync, SSH, system calls). The web interface is just a convenient way to trigger them.
4. Transparency over abstraction. Users should be able to understand what DeQ does by reading the code. No magic, no hidden complexity.

What this means in practice

• New features are weighed against their byte cost
• Complexity is pushed to clients (Android app) where it doesn't affect server footprint
• Edge cases that require heavy dependencies get declined
• "Works on a Pi Zero" remains a hard requirement

Is the 500KB limit carved in stone?

No. But for now it is. When we see there are devices much more powerful than a Pi Zero and available for the same price, then we can move on. We're not here for saving old SBCs from the scrapyard. Sustainability is about you and buying/scrapping things. Not about DeQ.

Can I contribute or request features?

Yes, but with caveats.

Feature requests

Open an issue on GitHub. But understand that DeQ is opinionated. Features that would:

• Require external dependencies
• Significantly increase the codebase
• Add complexity without proportional value
• Break the "works on a Pi" requirement

...will likely be declined. That's not rudeness; it's staying true to the ethos.

Code contributions

PRs are welcome for:

• Bug fixes
• Unexpensive feature upgrades
• Performance improvements
• Code cleanup that reduces size
• Documentation improvements

For new features, open an issue first to discuss whether it fits the project's scope.