piSignage Server
Overview
This guide covers deploying and using piSignage Server with FerretDB on Ubuntu 24.04 on Azure, from SecureAnyCloud Azure Marketplace images.
The image bundles the open source signage server with a permissively licensed database:
- piSignage Server (MIT OR Apache 2.0) is the open source, self-hosted server for managing digital signage. From a web browser, you upload media, build playlists, organize displays into groups and labels, and manage the signage players that connect back to the server. This is the open source self-hosted server, not the piSignage cloud or hardware offering.
- FerretDB (Apache 2.0) is a truly open source database that speaks the MongoDB wire protocol while storing your data in PostgreSQL through the DocumentDB extension. piSignage stores its assets, groups, labels, players and settings here.
The image uses FerretDB instead of MongoDB Community Server. MongoDB Community is distributed under the Server Side Public License (SSPL), which is not freely redistributable in a paid marketplace image. FerretDB is a permissively licensed, MongoDB-compatible alternative, so the whole stack in this image is open source and free of restrictive licensing. The datastore is FerretDB, backed by PostgreSQL. It is compatible with MongoDB, not MongoDB itself.
Runs stand-alone. Physical signage players connect to the server over the network, but the server itself boots and is fully usable with no hardware attached. You can set up media, playlists and groups, and preview your content, before you register a single screen.
Security by design, no baked credential. Nothing in this image ships with a known password. The upstream piSignage project stores its login in its database with a well-known default, user name pi and password pi, and bakes in a fixed session secret. The image overrides both.
On first boot, each VM generates a unique web console administrator password, a unique database password and a unique session secret. It writes the console and database passwords to root-only files, and the default pi login is overridden and rejected.
The MongoDB-compatible endpoint is bound to loopback only, so only the local server reaches it. The web console is the single network-facing service, and HTTP authentication protects its entire interface and REST API.
What you get:
- piSignage Server 3.2, running under systemd as
pisignage.serviceon port 3000, with its whole UI and REST API behind HTTP authentication - FerretDB 2.7.0, running under systemd as
ferretdb.service, with the MongoDB wire protocol on loopback 127.0.0.1:27017 - PostgreSQL 17 with the DocumentDB extension as the storage backend (loopback only), running as
postgresql.service - The
mongoshMongoDB shell, plusffmpeg, ImageMagick and GraphicsMagick for media processing, preinstalled - A demo playlist
SacDemo, two demo media slides and aLobby Displaygroup, seeded on first boot so the console shows real content immediately - A per-VM web console password, database password and session secret, generated on first boot. The console and database passwords are written to root-only credentials files
- No swap in the image. PostgreSQL is tuned to fit in RAM on a
Standard_B2s
Deploying the VM
Launch the image from the Azure Marketplace as you would any other VM. The recommended size is Standard_B2s (2 vCPU / 4 GiB), which the shipped configuration is tuned for.
The web console listens on TCP 3000. In the Azure network security group, open 3000 only to the client addresses that need it, and never to the whole internet. Add 22 for SSH. The MongoDB-compatible database on 27017 is bound to loopback and is deliberately not exposed.
First boot
On the first boot of each VM, two ordered one-shot services run before the application starts:
ferretdb-firstboot.servicegenerates a unique database password, creates the PostgreSQL role that FerretDB authenticates as, and writes/root/ferretdb-credentials.txt.pisignage-firstboot.servicegenerates a unique web console administrator password and a unique session secret, wires piSignage to the database, seeds the demo playlist, media and group, and writes/root/pisignage-credentials.txt.
The application service, pisignage.service, starts only after first boot has finished seeding the per-VM credentials, so the well-known default login is never live. Both one-shot services complete within a few seconds of boot. Confirm that the whole stack is up:
systemctl status postgresql ferretdb pisignageSigning in to the web console
Retrieve the generated web console credentials (root only):
sudo cat /root/pisignage-credentials.txtThe file shows the user name (admin), a unique password and the URL. Open the console in your browser:
http://<vm-public-ip>:3000/Sign in with admin and the generated password. The upstream default login (pi / pi) is overridden and is rejected.
The Assets page shows the seeded demo media slides and the SacDemo playlist. The Players page shows the seeded Lobby Display group. Because this content is seeded, a freshly launched VM shows a working, populated console with no signage hardware attached.
Managing media, playlists and groups
From the web console you can use these pages:
- Assets: upload images, video and other media, and see them listed with thumbnails. Build playlists from your media in the Playlists panel on the same page.
- Players: organize your displays into groups, assign a playlist to a group, and monitor the players that report back to the server.
- Settings: configure server-wide options for your deployment.
The server is ready to accept players immediately. When you set up a physical piSignage player, point it at this server's address so it registers. Then assign the player to a group to start playing your content.
Working with the database directly
The MongoDB-compatible database (FerretDB) runs on the loopback interface. The mongosh shell is preinstalled. Read the database password (root only):
sudo cat /root/ferretdb-credentials.txtThen connect locally, substituting the password from that file:
mongosh "mongodb://admin:<database-password>@127.0.0.1:27017/pisignage?authMechanism=SCRAM-SHA-256&authSource=admin"Your existing MongoDB drivers work unchanged against the same endpoint. The database is bound to loopback and is not exposed on the network. To reach it remotely, open 27017 in the network security group and change FERRETDB_LISTEN_ADDR in /etc/ferretdb/ferretdb.env. Ideally, put TLS in front of it.
Security notes
- The web console is the only network-facing service. Open port 3000 only to trusted client addresses in the network security group. Before you expose it beyond a private network, put it behind TLS, for example an nginx or Caddy reverse proxy or an Azure Application Gateway.
- The web console administrator password, the database password and the session secret are unique per VM and generated on first boot. No two machines share a secret, and there is no default login to guess.
- The database endpoint is bound to loopback and is never exposed by default.
- The base OS is fully patched at build time and keeps unattended security updates enabled, so security patches continue to flow on your running VM.
Maintenance
The stack runs as ordinary systemd services and starts automatically on boot. Use these commands to manage it:
# Status of all three services systemctl status postgresql ferretdb pisignage
# Restart the application after a configuration change
sudo systemctl restart pisignage
# Application logs (recent)
sudo journalctl -u pisignage -n 50 --no-pagerTake regular backups of your media directory (/opt/media) and of the database. For the database, use standard MongoDB-compatible tooling against the loopback endpoint, or back up the underlying PostgreSQL cluster.
Support
Every SecureAnyCloud image comes with a deploy guide tested against the exact build, and with 24/7 SecureAnyCloud support by email and chat. Support covers the web console, media and playlists, player registration, authentication, the PostgreSQL and DocumentDB backend, backups and capacity planning.
Deploy on Azure
Launch piSignage Server with FerretDB on Ubuntu 24.04 on Azure with 24/7 support from SecureAnyCloud.
View this image
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com