piSignage: a Raspberry Pi signage player with playlists, groups and a local server option

One player image, several hardware targets, and a very specific install path

piSignage is described as a digital signage solution primarily used with Raspberry Pi boards, though the README notes it can also work on other Linux based hardware platforms such as an Intel NUC, with a link to an installation procedure for the second player build. It is also available on Android devices through the Google Play Store and as a web app, and the Amazon Signage Stick is listed as a place it runs.

All Raspberry Pi models are supported, but the README is emphatic that you should use the specific image for the various models, and the download list is organised around exactly that. There is a Trixie OS based 5.4.1 image family, with a 64-bit build for models above the Pi 3B+ and a separate 32-bit build for the lower models, both based on 64-bit or 32-bit Raspberry OS as released in December 2025, and an older 5.3.2 pair for other boards. There is also a 3.2.9 image based on Raspberry Buster OS, described as using the proprietary omxplayer to display video and still a strong performer on a Pi 4 with 1GB and a Pi 3, plus an armv6 variant for the Pi Zero, 0W, 1 and 2.

That last image is a good example of why the split exists. The omxplayer path is the hardware-accelerated video decoder, and keeping it in a legacy image is how a signage player keeps playing video smoothly on boards that are now several years old. A player that had to be current with the newest Raspberry OS would lose that.

The method is deliberately not a normal install. You download a complete player image, program it onto an SD card of at least 16GB, class 10 or above, and the README warns in bold that a simple copy-paste of the file onto the card will not work. The image is written with Raspberry Pi Imager or balena Etcher, and the README asks that you use the custom option for the OS and not apply your own customisations such as ssh, wifi or autologin, because piSignage configures those itself. Then the card goes into the board, the board is powered on, and the player is registered with a player id at pisignage.com to be manageable from the cloud.

The alternative route, described as Method 2, is installing player2 yourself on top of standard Raspberry OS or Debian and Ubuntu for other platforms, with the procedure published separately.

Three ways to manage a screen, and only one of them needs the vendor

The management model is the part of the system that decides whether it fits, and the README is clear that there are three options.

Players can be managed centrally using the managed services at pisignage.com. They can be managed using a separate server running open sourced server software, hosted at the piSignage server repository. Or they can be managed independently using the player web UI, which is reachable at the player's own address on port 8000.

That third option is the one that matters for a small installation and for anyone who does not want a subscription. A single screen with one playlist needs no dashboard and no account, and the player web UI gives you the same content model without the central service.

The quick reference table gives the connection details: the player web UI is at http://player-ip:8000, the default username is pi, the default password is pi, and the access point SSID follows a pattern of piplayer- followed by four characters. The defaults are the first thing to change, since a screen with a default credential on a network is exactly the kind of device that gets found.

The hardware requirements are modest by design. The Raspberry Pi connects to a television through the HDMI interface, and it needs network connectivity to reach pisignage.com or whatever piSignage server is configured locally. The point of the local server option is that the network path is to your own infrastructure rather than to a hosted service.

The Android and web app builds matter for the same reason. A screen that is not a Raspberry Pi can still run the player, so a shop that already has an Android device or a spare laptop can display signage without buying dedicated hardware.

Content is organised as assets, playlists, layouts and groups

The README describes managing screens as a few steps, and the four steps map onto four objects in the data model.

Step one is uploading: images and videos, web or streaming links, and HTML assets designed and uploaded as a zip file. That last option is the interesting one, because it means the signage screen is not restricted to a slideshow, and the examples/ directory in the repository shows what that looks like in practice. There are example layouts for a UV index, a Washington DC Metro bus schedule, an analog clock, automated birthday wishes, a countdown timer, a custom layout, a date and time display, weather in both current and obsolete variants, a dynamic menu, an Instagram layout, an RSS feed, a media RSS XML layout, a side zone, a Twitter layout, a vertical fast food menu, a welcome notice and a set of templates.

Step two is playlists. You pick one of the built-in layouts or a custom layout made in the template designer, add assets and drag them into order, and set the duration of play for each asset. The same step covers a ticker feed, and it also covers what the README calls special playlists, which are playlists for advert insertion, for domination content, for lounge music and for content play based on events.

Step three is groups. You create a group and assign players to it, then assign and schedule multiple playlists to the group, define display settings, schedule the television on and off, and set other group properties. Deploying a playlist to every player in the group is then a single click, which is the entire reason groups exist.

Step four is monitoring. The dashboard and player screens show a current snapshot of the television, and you can get reports, update software and issue debug piShell commands to a player remotely.

The utilities underneath are smaller but real: playlists can be played and paused, and individual assets can be played from both the player and the server UIs. Players can run in kiosk mode, pointing at the URL provided and playing normal playlists when no key is pressed, which is the behaviour you want on a screen nobody will touch. And there is autoconfiguration of players for bulk management.

The repository is documentation and release notes, not the player source

The top-level contents of the repository are worth reading before you form an expectation of it, because they are not what a software repository for a signage player usually contains.

There is a README, and then a set of release notes kept as separate files: one for the 3.x players, one for the 5.x players, one for the server, and a general one. The player itself is not here. The downloadable artefact is the SD card image, and the images are hosted as zip files on the project's own storage, with Google Drive links offered alongside for each one.

The documentation is a mixture of formats. There are PDF files for the basic install, for the layouts and for an advanced install, and a GPIO media control instructions file with a name that includes spaces, which is the sort of naming that only survives because it was typed once in 2014. A privacy policy document for the remote app sits at the root as well.

The rest is content. There is a translation-files/ directory, a robotjs-keys/ directory, and the examples/ directory with the layout samples listed above. The translation directory is the practical bit for anyone running the player in a non-English environment, since the player interface and the built-in layouts have their own strings.

The primary language of the repository is recorded as HTML, which is consistent with the mixture of markdown, PDF and asset files here, and the license is recorded as unknown, which is worth resolving before you redistribute any of the layouts or examples. The site at pisignage.com is the project's homepage, and the terms of service are linked from the download note, with the agreement that using the player software means accepting them.

One release tag from 2014, and a project that is clearly still running

The release history is the confusing part of this repository, and it needs the version numbers from the download list to make sense.

There is exactly one GitHub release, 0.1.0, tagged as an install script working version, dated 2014-04-03. That is the only release the repository has ever published, and it corresponds to an era when the player was installed by a script rather than flashed as an image.

The current player versions live in a different place entirely. The download list refers to 5.4.3 and 5.3.2 for the image builds, and the Android custom APK is offered as 5.5.3 with support for future over the air updates. The player2 naming, which appears throughout the README and in the URLs for the installation procedure and the web app, refers to the second-generation player, and the release notes are split between 3.x and 5.x to match.

So the GitHub release list is not the version history of the product. The release notes files in the repository are, and they are split by player generation and by the server, which is the sensible split given that the player and the server version independently.

The maintenance picture overall is that the project is alive. The repository is not archived, the last push was on 2026-09-23, the images are being rebuilt against Raspberry OS releases from December 2025, and the Android build is being extended with over the air update support. What is not alive is the GitHub release tagging, which stopped in 2014 and was replaced by images hosted elsewhere. If you are evaluating this, read the release notes for the player version your image actually contains rather than the tag list.

Editorial conclusion

piSignage is worth evaluating if you are running screens in a shop, an office or a lobby and want a player that a Raspberry Pi can run for a long time without a device fleet vendor managing it, because the group model, the scheduling and the option to run your own server are the parts that matter at that scale. It is the wrong tool if you want to write the signage application yourself, because the content model is fixed around playlists, layouts and groups, and it is the wrong tool if you need a guaranteed support contract, because the hosted service and the images are tied to a commercial operation. Before you commit, verify three things yourself: that you have picked the right image for your board, since the download list is organised by Pi generation and by 32-bit or 64-bit Raspberry OS, that you have changed the default credentials, because the quick reference lists the username and password as pi, and that the release notes for your player version are the ones you read, because the repository keeps separate release note files for the 3.x players, the 5.x players and the server.

Frequently asked questions

Official sources

1. colloqi/piSignage on GitHub
2. Issues
3. Project website
4. README
5. Releases