Nehas Digital Signage
An AWS-native platform for operating screen fleets, content, campaigns, and reliable playback
- My Role
- Founder, product architect, full stack engineer, and AWS platform designer
- Platform
- Multi-tenant enterprise SaaS with web, Windows, and Raspberry Pi player paths
No public link yet. This project is in active build.
Quick Overview
Development-deployed digital signage platform with tenant-scoped operations, secure media delivery, playlist and campaign publishing, web and desktop players, proof of play, observability, and controlled device releases.
- Who it serves
- Organizations that operate networks of digital signage screens and need central control over content, scheduling, and device health
- Current status
- Active Build
Development PASS / production NO-GO. The AWS development backend, console, and player are live in us-west-2; production deployment, signed Windows distribution, physical device acceptance, and human-owned provider configuration remain incomplete. The earlier Supabase system is reference-only and was not migrated.
The Problem
Running digital signage at any real scale means more than pushing an image to a screen. Someone has to know which screens are online, roll out content on schedule, react when a screen goes offline, and keep everything consistent across a growing fleet.
An earlier version of this idea existed as a read only reference build on Supabase. It showed which workflows mattered, but it was not the system this platform is being built as. Nehas is a new AWS native build, not a migration of that earlier project.
The Solution
Nehas now has a deployed AWS development environment that connects fleet management, secure media operations, playlists, publishing, campaigns, reports, integrations, and system health through tenant-scoped APIs and a shared operations console.
A deterministic player core supports web and hardened Windows Electron runtimes, persistent offline manifests, last-known-good playback, preload readiness, telemetry queues, watchdogs, and staged release rollback. A Raspberry Pi systemd installer is implemented but still needs physical-device acceptance.
Production remains intentionally blocked until OIDC deployment, environment secrets, signed Windows distribution, representative hardware testing, notification providers, and deployed acceptance are complete.
My Contribution
Product and requirements
Defined and tracked the ten-phase delivery plan, acceptance contract, tenant model, player reliability rules, and production GO gates.
AWS architecture
Designed the Amplify Gen 2 backend across Cognito, Lambda, DynamoDB, S3, CloudFront, API Gateway, AppSync Events, SQS, AppConfig, and CloudWatch.
Console engineering
Built the React operations console for media, playlists, campaigns, publishing, reports, integrations, users, customization, and system health.
Player engineering
Built shared deterministic playback behavior for web and Windows, plus Raspberry Pi installation and controlled release paths.
Security and tenancy
Enforced trusted tenant boundaries, role checks, private media delivery, scoped device credentials, audit records, and fail-closed production behavior.
Quality and operations
Established strict validation, unit/integration/E2E coverage, dependency policy, canaries, alarms, cost controls, recovery runbooks, and honest production blockers.
Key Features
Screen fleet management
Central view and control over every registered screen.
Screen pairing
Onboarding flow for connecting a new screen to the platform.
Health monitoring
Live status for screens, including alerts when something goes offline.
Remote commands and screenshots
Operate and verify screens remotely without site visits.
Media, playlists, and campaigns
Organize content into playlists and time bound campaigns.
Deterministic scheduling and publishing
Resolves emergency, takeover, campaign, publication, default, and fallback priorities with recurrence and restoration.
Proof of play
Confirmation that scheduled content actually played as intended.
Player release management
Controlled rollout and rollback of the software running on screens.
Emergency broadcast and alerts
Override normal content to push urgent messages across the fleet.
Maintenance and version history
Track changes over time with the ability to roll back.
Staging and test screens
Validate content and configuration before it reaches production screens.
Content rules, variants, and expiration
Control what content is allowed to play, in what variant, and for how long.
Reports and safe export
Tenant-scoped saved reports and formula-safe CSV export support operational review.
Configuration and capability controls
Versioned overrides, feature modules, terminology, navigation, brand settings, and player capability reporting are centrally managed.
Service credentials, webhooks, and integrations
Scoped credentials, signed webhook delivery, retry queues, dead-letter handling, health status, and kill switches support external systems.
Dynamic widgets and QR campaigns
Interactive content elements beyond static media.
Offline-resilient players
Persistent manifests, preload packages, last-known-good playback, bounded telemetry, watchdogs, and staged rollback protect screen uptime.
White-label customization
Versioned configuration controls branding, themes, terminology, navigation, dashboard ordering, and feature modules.
Technology
Applications
AWS platform
Media and delivery
Operations
Architecture
Operations console
React + Vite
Tenant-scoped web workspace for fleet, content, publishing, campaigns, reports, integrations, and administration.
Identity and APIs
Cognito + Lambda + API Gateway
User identity, role boundaries, domain services, and device-authenticated player routes.
Operational data
Amazon DynamoDB
Access-pattern-driven tables store tenant, fleet, publishing, campaign, reporting, and audit state with PITR and deletion protection.
Private media
S3 + CloudFront
Encrypted versioned storage, immutable variants, OAC, and signed delivery protect media assets.
Playback delivery
AppSync Events + SQS + Scheduler
Preload notifications, fallback polling, queued telemetry, scheduled evaluation, and immutable manifests coordinate players.
Operations
AppConfig + CloudWatch
Kill switches, structured logs, dashboards, alarms, canaries, cost thresholds, and recovery controls support the platform.
Players
Web + Electron + Raspberry Pi
A shared deterministic playback core drives modern web, hardened Windows, and Linux kiosk paths.
The development environment is live in us-west-2. Operators authenticate through Cognito and use tenant-scoped Lambda APIs backed by protected DynamoDB tables. Private S3 media is processed into immutable variants and delivered through signed CloudFront access. Publishing generates immutable screen manifests, notifies players through AppSync Events, and retains polling and last-known-good fallbacks. AppConfig and CloudWatch provide controlled configuration, kill switches, health visibility, alarms, and canaries.
Product Gallery
These are early AI-generated product-direction concepts, not screenshots of the deployed development console. The verified implementation status and evidence are documented above.
Engineering Challenges
Designing for fleet scale from day one
A signage platform that only works for five screens does not hold up at fifty. Architecting fleet management, health monitoring, and configuration drift detection early on shapes everything else that gets built on top.
Separating the new build from the old reference system
The earlier Supabase based version captured useful workflow ideas but was not built for this platform's scale or AWS native direction. Keeping that system strictly as a read only reference, rather than migrating it, meant rebuilding the important workflows correctly from the ground up.
Designing reliable unattended playback
Screens must continue operating through network loss, bad manifests, failed updates, and partial content errors. Persistent caches, atomic switching, last-known-good recovery, bounded telemetry, and staged rollback were treated as core product behavior.
Keeping production gates honest
A successful development deployment is not production acceptance. Hardware codec behavior, Windows signing, production secrets, OIDC deployment, and real notification destinations remain explicit external blockers instead of being hidden behind a broad 'done' label.
Results and Evidence
- Completed all ten implementation phases and deployed the development backend, console, and player in us-west-2.
- 251 requirements pass; 19 externally dependent production or hardware requirements remain blocked.
- 149 unit, component, integration, and policy tests pass across 28 files.
- 25 functional E2E checks and six visual captures pass.
- All 61 development DynamoDB tables have point-in-time recovery and deletion protection enabled.
- Produced a hardened unsigned Windows NSIS player installer; production distribution remains blocked on Authenticode signing and physical acceptance.
What I Learned
Planning a configuration driven architecture up front, instead of hardcoding behavior per screen, has already changed how I think about designing systems that need to operate at scale.
Digital signage reliability is a distributed-systems problem: the player must make safe local decisions even when the cloud, network, or new content is unavailable.
Explicit production gates make progress more credible. Development can be complete and demonstrable while production remains a deliberate NO-GO until external evidence exists.
Related Credentials
AWS re/Start Graduate
Amazon Web Services
Issued Jul 24, 2026
AWS Skills Center Cloud Practitioner Foundations
Amazon Web Services
Issued Jun 12, 2026
See every credential on the Credentials and Learning page.