Skip to content

FAQ

What exactly does DisplayHive do?

DisplayHive is self-hosted digital signage: it drives a network of displays (kiosks, TVs, info screens) from one admin panel. You position named containers on a layout, style them instance-wide with a design (colors, gradients, backgrounds), drop typed content (text, images, tables, Pretalx schedules, etc.) into those containers via content types, and assign that content to screen groups. Changes appear on screens instantly over Socket.IO — there's no publish step, caching, or refresh delay. See Layouts, designs, content types & content for the full workflow.

Is there something else than a Docker or NixOS deployment?

Yes. Both are convenience wrappers, not a requirement. Underneath, DisplayHive is a plain Flask + Flask-SocketIO app; the Docker image and the NixOS module's systemd service both ultimately just run:

alembic upgrade head
gunicorn --worker-class eventlet -w 1 --bind 0.0.0.0:<port> app:app

You can run that yourself on any Linux host with Python 3.13, Node.js, and a database (SQLite for small/single-instance setups, or PostgreSQL via DATABASE_URL) — install dependencies from requirements.txt, build the two frontends, put a reverse proxy (e.g. nginx) in front for TLS and WebSocket forwarding, and manage the process with systemd, another process supervisor, or a container of your own making. See the root README for the environment variables involved.

How many screens can I connect?

There's no built-in limit — a screen or device is just a database row, and nothing in the code caps or licenses that count. The practical ceiling comes from how the backend runs: the standard deployment uses a single gunicorn worker process (--worker-class eventlet -w 1). Eventlet handles many concurrent Socket.IO connections efficiently within that one process, but all traffic is serialized through it — there's no built-in horizontal scaling across multiple worker processes. The README describes DisplayHive as comfortable driving "one display or a hundred at once," which is the scale it's been built and tested around; nothing stops you from trying more, but very large deployments haven't been a focus yet.

What happens if a screen loses its online connection?

  • On screen: it keeps showing whatever content was last rendered — losing connection doesn't blank the display or reload the page. The screen client retries the connection automatically (a fixed 20-second delay between attempts) until it reaches the server again.
  • On reconnect: the screen re-syncs and picks up any content changes made while it was offline.
  • In the admin panel: the affected device and screen immediately show as Offline (a red badge) on the Devices, Screens, Screen Groups, and Matrix pages, so you can see at a glance which displays have dropped.
  • Alerting: if you've set up Telegram alerting, a Screen Offline / Device Offline notification fires as soon as the disconnect is detected, and a matching Online notification fires on reconnect.

There's no local content cache beyond what's already in the page, so a screen that loses power (not just network) and restarts will show a blank page until it reconnects and receives a fresh content push.

How does the "push" to screens actually work?

Whenever you save a change that affects what a screen should show — toggling content on or off, editing content, changing a design, adjusting a layout, or reassigning content to a screen group — DisplayHive figures out which screens are affected and immediately sends each of them an updated snapshot of everything they should be displaying (design plus the full rotation of content for that screen). The screen swaps this in on the spot; it's not a browser reload, so there's no flicker or downtime.

A few things worth knowing:

  • Only affected screens are updated. Screens that aren't assigned to the changed content or screen group don't receive anything.
  • There's no batching or delay. Every save triggers its own push right away, so if you make several edits in quick succession, each one is sent out separately.
  • Last save wins. If two people edit the same thing around the same time, there's no conflict warning — whoever saves last is what ends up on the screens.
  • Some content (like randomized images or live Pretalx schedules) can also refresh itself on the screen without any admin action, independent of this push mechanism.