Common questions about Anthias.
Anthias is free, open-source digital signage software built by Screenly, Inc. Screenly is a paid, cloud-managed digital signage platform designed for professional multi-screen deployments. You can learn more about the differences on screenly.io.
Choose Screenly if you need multi-screen management from a single account, enterprise user management, or professional support. Choose Anthias if you’re comfortable managing individual devices and want a free, self-hosted solution.
Yes. Anthias is dual-licensed under GPLv2 and a commercial license. You can deploy it commercially under GPLv2 — including in customer-facing storefronts and lobbies — as long as you comply with the GPL’s copyleft terms when redistributing modified versions.
If you need a non-copyleft license, professional support, or fleet-scale management, see Screenly.
$HOME/anthias/bin/run_upgrade.sh) or pull the latest Docker images. Disk image installations are pinned to the version you downloaded.Anthias uses NetworkManager for networking when the installer’s “manage the network” prompt is enabled. SSH into the device and run sudo nmtui for an interactive UI, or use nmcli device wifi connect <SSID> password <pwd> from the command line.
The legacy WiFi-Connect captive portal has been removed; nmtui / nmcli are the supported path going forward.
sudo nmtui → Edit a connection → choose your interface → set IPv4 Configuration to Manual and fill in the address, gateway, and DNS. Apply and reboot to confirm. You can also do this with nmcli non-interactively if you’re scripting deployments.Whether SSH is enabled depends on the OS image, not on Anthias itself — the installer doesn’t touch sshd.
ssh into the /boot partition before first boot.Then connect with ssh <user>@<device-ip>.
A stock Debian install doesn’t include sudo (and often not curl either) if you set a root password during installation. Bootstrap both as root before running the Anthias installer:
$ su -
# apt update && apt install -y sudo curl
# usermod -aG sudo <your-user>
# exit
Log out and back in so your shell picks up the new group, then continue with the x86 install steps.
If you instead reinstall Debian and leave the root password blank, the Debian installer wires your regular user up as a sudo user automatically and you can skip this step.
Use the Settings page in the Anthias dashboard (“Screen rotation”). On Pi 5 / x86 / arm64 the viewer runs under the cage kiosk Wayland compositor and the rotation is applied via wlr-randr. On Pi 2 / Pi 3 / Pi 4 the viewer renders to the Linux framebuffer directly and the transform is applied inside the media player; the Settings page works the same way.
Edit /boot/firmware/config.txt and add one of:
display_rotate=1 # 90°
display_rotate=2 # 180°
display_rotate=3 # 270°
Then reboot. If display_rotate doesn’t take effect on a particular Pi 5 / KMS setup, set the rotation on the kernel cmdline instead — edit /boot/firmware/cmdline.txt and append video=HDMI-A-1:1920x1080@60,rotate=90 (or 180/270) on the same line. Many displays also expose a rotation setting in their own OSD as a fallback.
Anthias displays at whatever resolution the OS reports — there’s no resolution setting in the dashboard. Set the output mode at the OS level: on Raspberry Pi OS, use sudo raspi-config → Display Options → Resolution, or set hdmi_group / hdmi_mode in /boot/firmware/config.txt.
4K is supported on Pi 5 / x86 / arm64 — those run the viewer under the cage Wayland compositor and the GPU handles the upscale for free. On Pi 4 the viewer renders to the Linux framebuffer directly and mpv hands video scaling to the V3D, so 1080p source on a 4K connector works smoothly; demanding 4K-source video on Pi 4 will drop frames, however, because the V3D doesn’t have the bandwidth headroom Pi 5’s V3D 7.1 has.
This usually means the viewer container can’t reach the server, or there are no active assets. Try these in order:
docker compose ps from ~/anthias/ — all four containers (anthias-server, anthias-celery, anthias-viewer, redis) should be Up.docker logs -f anthias-anthias-viewer-1 (or …-server-1).cage on Pi 5 / x86 / arm64, or Qt linuxfb on Pi 2 / Pi 3 / Pi 4) and uses no X server, so xset won’t help.If a recent update broke the display, running ~/anthias/bin/upgrade_containers.sh re-creates the containers cleanly.
Pretty much anything you’d take with a phone or download from the web. Photos from iPhones (HEIC), Android phones, scanners, and screenshots all work — Anthias quietly converts unusual formats into something it knows how to display.
Videos work the same way. Drop in a clip from your phone or a camera, or pick something off your computer; if it’s not in a format your screen plays smoothly, Anthias prepares it for you in the background. Most files don’t need any conversion at all and start playing right away.
While a file is being prepared you’ll see a Processing badge next to it in the dashboard. If something goes wrong (a corrupt file, for example), you’ll see a Failed badge with a brief explanation when you hover over it, so you can fix or remove it without hunting through logs.
Yes — paste a YouTube URL into the Add Asset dialog. Anthias downloads the video and stores it on the device, so playback is smooth, doesn’t buffer, and never shows ads or recommended-video overlays.
If a particular video fails to load, it’s almost always because YouTube has changed something on their end — updating Anthias to the latest release usually fixes it.
Open the web dashboard, go to Settings, and pick HDMI or 3.5mm jack under Audio output. The change applies to video assets immediately — no reboot required.
Note: Raspberry Pi 5 only exposes the HDMI option in the dropdown — the 3.5mm jack was removed from the Pi 5 hardware, so the dashboard hides that choice on Pi 5 devices.
Yes — on a best-effort basis. If you flash a Debian-based Armbian image (Bookworm / Trixie) onto a 64-bit ARM board (Rock Pi, Orange Pi, Banana Pi and similar), the Anthias installer recognises it and sets things up the same way it does on a Raspberry Pi. The dashboard, scheduling, and asset library all work exactly as you’d expect.
Pick the Debian build of the Armbian image for your board. The installer wires Docker’s apt repository under the Debian namespace; Ubuntu-based Armbian downloads (Jammy / Noble) fail at the very first apt update because Docker doesn’t publish those codenames there. Supporting Ubuntu-based Armbian is a follow-up.
A few things to know before you pick a board for a serious deployment:
See issue #2849 for the roadmap on per-board hardware video acceleration.
Anthias sends an HTTP Accept-Language header derived from the device’s system locale, and sites that ship multiple languages use that header to pick which version to serve. Out of the box the locale is whatever the OS image was built with (usually en_GB.UTF-8 on the Anthias Raspberry Pi image), so multi-language URL assets default to English. Set the locale to the language you want and the site will follow.
Raspberry Pi OS / Debian: SSH in and run sudo raspi-config → Localisation Options → Locale, tick the locales you need, then pick one as the default — or, non-interactively, sudo update-locale LANG=nl_NL.UTF-8 (substitute your locale). Re-run ~/anthias/bin/upgrade_containers.sh so the new LANG is baked into the viewer container.
balena: open your fleet/device in the balena dashboard, add a Device Variable (or Service Variable scoped to anthias-viewer) with name LANG and value e.g. nl_NL.UTF-8. The balena supervisor restarts the viewer container with the new env var; no SSH needed.
Either way, the change takes effect after the viewer container restarts. Open a multi-language site in the dashboard’s Add Asset preview to confirm it picks up the new language.
SSH into the device and use either of these:
# Tail a single container directly
docker logs -f anthias-anthias-server-1
# Or via Compose (run from ~/anthias/)
cd ~/anthias
docker compose logs -f anthias-server
The container names are anthias-anthias-server-1, anthias-anthias-celery-1, anthias-anthias-viewer-1, and anthias-redis-1. If TLS is enabled, there’s also anthias-anthias-caddy-1.
The easy way: open the dashboard, go to Settings, and click Get Backup to download a single-file archive. To restore, click Upload and Recover on the same page.
If you’d rather copy the files manually, asset binaries live in ~/anthias_assets/ and configuration plus the SQLite database (anthias.db) live in ~/.anthias/. Backing up both directories captures everything.
~/anthias/, run ./bin/enable_ssl.sh. The default mode uses Caddy’s built-in local CA, which is fine for IP-based LAN access. For Let’s Encrypt or bring-your-own certificate, see the TLS / SSL section in the docs.Most reverse proxies — nginx, Apache (mod_proxy), IIS ARR — rewrite the upstream Host header by default. When that happens, Django’s CSRF protection rejects every POST with Origin checking failed and uploads, asset changes, and settings updates all fail.
You have two options:
1. Preserve the upstream Host (preferred). Tell the proxy to pass the original Host through:
| Proxy | Directive |
|---|---|
| nginx | proxy_set_header Host $host; |
| Apache | ProxyPreserveHost On |
| IIS ARR | preserveHostHeader="true" (or the GUI toggle) |
| Caddy | preserved by default — no action needed |
| Traefik | preserved by default (passHostHeader: true) |
With Host preserved, Anthias’s built-in same-host CSRF fallback handles HTTP-to-HTTPS scheme drift automatically.
2. Tell Anthias the public hostname directly. If you can’t (or don’t want to) change the proxy config, list the public origin in CSRF_TRUSTED_ORIGINS. From ~/anthias/, edit .env (or your compose override) and add:
CSRF_TRUSTED_ORIGINS=https://signage.example.com
Multiple origins are comma-separated. Restart with docker compose up -d.
The bundled ./bin/enable_ssl.sh Caddy sidecar handles all of this for you — the above is only relevant if you’re terminating TLS or proxying with something else.
http://<device-ip>/api/docs/.Devices with the Basic authentication mode enabled in Settings require credentials on every API call. Two paths resolve to the same operator account:
/login/ will 403 because the login form itself is CSRF-protected (the script has to GET /login/ first, parse out the csrfmiddlewaretoken form field and the csrftoken cookie, then POST both back), and DRF’s SessionAuthentication enforces CSRF again on every API write (POST / PUT / PATCH / DELETE) by requiring an X-CSRFToken header. Cookie-only scripts that skip either step get 403s.Authorization: Basic <base64(user:pass)>. Retained for back-compat with pre-2826 Anthias-CLI and third-party scripts; the server logs a DEPRECATED: warning the first time it sees each (user, client IP, path) tuple and then again roughly once an hour for the same tuple (throttled so a polling client doesn’t flood the log). A UI-managed personal-token system that will replace Basic for headless callers is tracked as a follow-up.Devices with authentication disabled (the default on a fresh install) accept either of these but don’t require them.
Ask on the forum or open a GitHub discussion.