lzstealth/pulse-signage
1
0
Fork 0
Code Issues Pull Requests Actions Packages Activity

Add multi-player and remote bridge support

Browse Source
This commit is contained in:
lzstealth
2026-08-07 02:58:18 +01:00
parent a4f8a807ff
commit 74318eb34e
58 changed files with 3785 additions and 432 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+24 -67
View File
@@ -1,81 +1,38 @@
# Pulse Signage
Pulse Signage is a self-hosted digital signage platform built for teams that want clear, flexible control over what appears on every screen.
Pulse Signage is a self-hosted digital signage platform for teams that want clear, reliable control over the content on every screen.
It gives you one place to manage playlists, slides, templates, screen assignments, announcements, data-driven content, and live player control without handing that workflow to a third-party service.
It gives you one place to publish playlists, slides, announcements, and live updates without handing the workflow to a third-party service.
## Why It Stands Out
## What It Can Do
- Keep signage under your own control.
- Build polished screen experiences with reusable templates and playlists.
- Push announcements, schedules, RSS feeds, API content, and other dynamic content to screens.
- See what is live, what is queued, and what needs attention from a single admin dashboard.
- Use the same system for everyday signage, timed messages, and more structured information displays.
- Run polished screen experiences with playlists, slides, and reusable templates.
- Keep announcements, schedules, RSS feeds, API content, and other live data in sync.
- Manage many screens from a single dashboard.
- Support everyday signage, event messages, lobbies, dashboards, and other always-on displays.
- Keep the player, dashboard, and bridge connected so updates move quickly and consistently.
## What It Handles
## Why It Fits
- Screens and playlist assignments.
- Slides, templates, and canvas sizes.
- Announcements and screen-specific targeting.
- RSS feeds, API sources, and schedule-based content.
- Roles and permissions for admin access.
- Background tasks and scheduled refresh jobs.
- Player onboarding and live playback control.
- It keeps signage under your own control.
- It is built for teams that need screens to stay current without extra manual work.
- It works well for offices, venues, campuses, and operations teams.
- It stays focused on display management instead of trying to be a general-purpose CMS.
## Simple Deployment
## Deploying
Pulse Signage ships with a Docker Compose stack for the published image:
Docker Compose is the recommended way to deploy Pulse Signage. It keeps the web app, player, bridge, and database together in a predictable setup.
- Published-image stack: `docker compose -f docker-compose.yml up -d`
If you want the details, start with the [Compose guide](docker-compose/README.md).
Use this stack when you want to run the tagged image instead of building from source.
## Docs
## Environment File
- [Documentation home](docs/README.md) - the technical reference index.
- [API reference](docs/api.md) - the player HTTP surface and onboarding endpoints.
- [Database schema](docs/schema.md) - the tables and data model the app maintains.
- [WebSocket reference](docs/websocket.md) - the live player and snapshot channels.
- [Compose guide](docker-compose/README.md) - deployment options and service layout.
The compose files read from a root `.env` file. Start by copying `.env.example` to `.env`, then adjust the values for your setup.
## Explore The Docs
The variables are split by who uses them:
Shared across the stack:
- `PULSE_SIGNAGE_IMAGE`
- `PULSE_SIGNAGE_SHARED_SECRET`
Web container:
- `SESSION_MAX_AGE_DAYS`
- `DEFAULT_ADMIN_USERNAME`
- `DEFAULT_ADMIN_NAME`
- `DEFAULT_ADMIN_PASSWORD`
- `PASSWORD_HASH_ITERATIONS`
Player container:
- `PLAYER_PUBLIC_BASE_URL`
- `PLAYER_INTERNAL_BASE_URL`
MySQL container:
- `DB_HOST`
- `DB_PORT`
- `DB_NAME`
- `DB_USER`
- `DB_PASSWORD`
- `MYSQL_ROOT_PASSWORD`
`DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, and `DB_PASSWORD` are shared in practice because both app containers talk to the same database service.
`PLAYER_INTERNAL_BASE_URL` is used by the web side for server-to-player calls, while `PLAYER_PUBLIC_BASE_URL` is used for browser-facing player links.
## First-Time Use
The first startup seeds a default admin account if the database is empty.
- Username: `admin`
- Password: `admin`
## In Practice
Pulse Signage is designed to feel focused and reliable rather than heavy or noisy. It works well when you want a clean internal signage system for offices, venues, dashboards, or any environment where screens need to stay up to date without a lot of manual effort.
The player and admin pieces stay linked, so changes made in the dashboard can flow out to screens quickly and consistently.
The project includes a dashboard for managing content, a player runtime for rendering screens, an onboarding flow for connecting devices, and a bridge layer for remote screens. If you want to understand how the pieces fit together, the docs above cover the technical details without repeating the project overview.