Self-Hosted Digital Signage Software: Complete Guide (2026)

Why you might want to self-host your digital signage CMS, what you need to do it well, and how to deploy ScreenTinker on your own server.

Why self-host digital signage?

Most digital signage products are cloud-only. That works for many businesses, but there are real reasons to keep the server in-house:

• Data sovereignty. Healthcare, finance, government, and education often cannot put internal information into a third-party cloud. Self-hosting keeps content, schedules, and access logs on your network.
• Cost control. Per-screen monthly fees stack up fast. Self-hosting trades that for a fixed server cost - typically $5 to $50 per month for a small VPS that can run hundreds of screens.
• Network isolation. Some deployments live on private LANs with no internet access at all. Self-hosting is the only way to manage signage in those environments.
• No vendor lock-in. If the cloud vendor disappears, raises prices 3x, or pivots away from your use case, your deployment goes with them. Self-hosters control their own roadmap.
• Customization. Open source self-hosted means you can fork the code, add a custom widget, or wire it into your existing systems.

What you need

Hardware / VPS

A modest Linux server is enough for most deployments:

• Up to 25 displays: 1 vCPU, 1 GB RAM, 20 GB disk. ~$5/month on Hetzner, DigitalOcean, or Vultr.
• 25-100 displays: 2 vCPU, 2 GB RAM, 40 GB disk. ~$12-20/month.
• 100+ displays: 4+ vCPU, 4+ GB RAM, faster disk. Plan for content storage at ~50-200 MB per screen depending on media volume.

An on-prem VM works just as well as a cloud VPS - in fact, on-prem is often the whole point.

Software prerequisites

• Ubuntu 22.04 or 24.04 LTS (Debian 12 also works)
• Node.js 18 or newer
• A domain name pointed at your server (or just an internal hostname / IP for LAN deployments)
• SSL certificate (Let's Encrypt is free; or self-signed for LAN)

Deploying ScreenTinker

Detailed setup is in the GitHub README. Quick version:

git clone https://github.com/screentinker/screentinker.git
cd screentinker/server
npm install
cp .env.example .env
# edit .env with your domain, JWT_SECRET, and SELF_HOSTED=true
node server.js

Set SELF_HOSTED=true in the env. This unlocks the enterprise plan for your account, disables subscription expiry checks, and skips Stripe entirely. It is meant for the operator-controlled deployment case.

Reverse proxy and TLS

ScreenTinker listens on HTTP/HTTPS directly, but in production you typically front it with nginx or Caddy for TLS termination, gzip, and rate limiting. A minimal Caddyfile:

signage.example.com {
  reverse_proxy localhost:3001
}

Caddy handles Let's Encrypt automatically. nginx works too if your team prefers it.

Running as a service

Use systemd to keep the process alive across reboots. A unit file at /etc/systemd/system/screentinker.service:

[Unit]
Description=ScreenTinker Digital Signage Server
After=network.target

[Service]
WorkingDirectory=/opt/screentinker/server
ExecStart=/usr/bin/node server.js
EnvironmentFile=/opt/screentinker/.env
Restart=always
User=screentinker

[Install]
WantedBy=multi-user.target

Enable with systemctl enable --now screentinker.

Backups

The state lives in two places:

• server/db/remote_display.db - SQLite database of users, devices, playlists, schedules
• server/uploads/ - uploaded media (images, videos, thumbnails)

A nightly tarball of those two paths gives you a full restore point. Pair with offsite sync (rclone, restic) for disaster recovery.

Self-hosted vs cloud-hosted comparison

When the cloud is the right answer

Self-hosting is not free of cost - it requires someone who can run a Linux server, monitor it, and apply security updates. If your screen count is small (under ~10) and you do not have IT capacity, the managed cloud version is probably the right choice. ScreenTinker's hosted plans start at $39/mo for 5 devices.