Anthias runs on any ARM board, provided your image is Debian-based

The name exists because two products had one name

The about section explains the project's name before it explains the project. Anthias is a digital signage platform for small computers and desktops. It was formerly known under a name that combined the vendor with an open-source suffix, and it was renamed to clear up confusion between that project and a separate paid product from the same company. The explanation is expanded in a blog post linked from the paragraph, dated December 2022. Two things follow from that history. The documentation site, the repository and the forum all carry the new name rather than the old one, so older tutorials and forum threads refer to something that no longer exists under that label. And the rename is the reason the compatibility section exists in the shape it does, because supporting a board nobody at the company tested is the kind of thing a community-driven rebrand has to spell out.

bun build ./src/anthias_server/app/static/src/vendor.ts --outfile=./src/anthias_server/app/static/dist/js/vendor.js --target=browser --minify-whitespace --minify-syntax

Debian-based images only, and the failure lands at apt update

The section on generic single-board computers begins with a generous offer and then narrows it sharply. The installer recognises any 64-bit ARM host that is not a Raspberry Pi, classifies it as one architecture, and runs the same stack on it, naming one distribution and three board families as examples. The dashboard, the scheduler and the asset library are all said to work as they do on a Pi. Then the constraint: only Debian-based images are supported, naming two Debian releases, and the reason is mechanical rather than a policy. The installer points at a container repository hosted under the Debian path, so an Ubuntu-based image fails at the package update step, before anything is installed. The advice is to pick the Debian build for your board. That is the single most likely first failure for a new user, and it is the one the documentation bothers to explain rather than merely forbid.

Video decodes in software, and that is the board question

Before you choose a board there is a list of things to know, and only one of them is about video, but it dominates. Video decodes in software on these boards, which the documentation quantifies: fine for casual 720p playback, stutter-prone at 1080p on slower system-on-chip designs, and not suitable for 4K at all. The stated recommendation follows directly: if your content is mostly video, use a Pi 4 or 5, or use x86. Images and web pages, by contrast, are said to run smoothly across the supported boards, so the guidance is not that the platform is slow but that it is slow at one specific thing. Hardware decode per system-on-chip vendor is named as the planned follow-up, with three vendor-specific implementations listed and a single tracking issue for all of them. It is worth separating the two problems hiding inside that phrase, because they have different fixes. On a board with no decoder for its own video format, every frame has to be decompressed by the processor and the cost scales with resolution and bitrate, which is why the documentation is comfortable at one resolution, cautious at the next and dismissive at the third. On a board whose decoder exists in the silicon but whose kernel driver support is incomplete, the capability is there and unreachable, which is the separate problem the vendor caveat below addresses.

Four tested boards, and one family to keep off video

The tested list is four boards: two from one family, one from another and one from a third. Then an exclusion, and it is stated as a family rather than a model: boards built on one system-on-chip vendor, with one model given as an example, currently have weaker mainline display support and are best limited to non-video content. That phrasing is more precise than a support matrix usually is, because it separates two variables that are easy to conflate. Decode capability and display output are different problems, and a board can be fine at one and weak at the other. So the four-board list tells you what was exercised, the vendor caveat tells you what was not, and the video caveat from the previous section tells you which of the two differences actually matters for a signage screen.

The boot splash is wired up and will not display

One of the listed caveats is about appearance rather than function, and the documentation is refreshingly specific about why. The boot splash is configured, but typically does not appear on these boards, and the reason given is not a missing package: their bootloader does not hand the kernel an early display device for the splash to draw to. What you see instead is the kernel boot log scrolling on the screen until the viewer takes over and renders the first asset. The documentation's own assessment is that this is functionally fine and less polished than the boot on a Pi or an x86 machine. That is the right level of honesty for a caveat, because it tells you the cost is cosmetic and names the layer responsible, so a reader who does need a clean boot can judge whether it is worth the work.

The frontend build refuses to shorten identifiers

The build configuration carries a comment longer than most scripts, and it is worth reading because it explains a flag that is absent rather than one that is present. The front end uses a small declarative library whose click handlers are evaluated at runtime against a scoped closure, so the names of its internal variables are part of the program's contract rather than an implementation detail. The bundler's identifier-shortening pass renames those variables, and in one file it also renames handler names, which breaks the lookup. The comment says this happens silently. The fix is that two of the bundler's three minimisation passes are enabled, whitespace and syntax, and the third is deliberately left off, with the stated benefit that it halves the bundle without touching identifiers.

An empty dependency list and a Python 3.13 floor

The Python project metadata declares a version floor of 3.13 and a runtime dependency list that is completely empty, and both facts are explained by the same decision: the application ships as a container image rather than as an installed library, so its dependencies come from the image. What the manifest does provide is a single command entry point, and three named dependency groups that correspond to three jobs rather than three features. One is for host development, with a linter, a type checker and a pile of stub packages. One is for building the container image, with a template engine and a Git library. One is for the server itself, with the web framework, the task queue, the websocket layer, the API schema generator and the imaging pair. The comments inside those lists are as useful as the lists, because two of them record decisions that look wrong until you read the reason. One pins a stub package directly because a dependency dropped it transitively in a particular release, which is what dependency pinning is for. The other explains that two imaging libraries together power a normalisation pipeline that converts modern formats into a lossless web format at upload time, and that the underlying system library is supplied by the base image rather than installed by the language toolchain.

That last point is the one to carry away. An empty runtime dependency list is not an achievement, it is a statement about where the dependencies live, and anyone installing this package into a virtual environment of their own will find that none of the web framework is present.

Editorial conclusion

Anthias suits a small screen on a single-board computer, especially one built around images and web pages rather than video. It does not suit a video-heavy installation on a non-Pi board, where the documentation says decode happens in software and the result stutters. Before deploying, check which base image your board's Armbian build uses, since the wrong family fails at a package update rather than at install time, and decide whether a scrolling boot log matters to the location.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Screenly/Anthias on GitHub