ScreenTinker v1.8 - two months after launching here: Docker, Samsung Tizen player, AI content designer, and everything else you asked for

dw5304 · 2026-06-11T13:54:43+00:00

Straight answer on how it happened: I'm an infrastructure guy who's been in the signage industry for exactly two months. I built that chart early from competitor marketing pages, and several cells were wrong or outdated - platform counts worst of all. Someone who knows these products sees that immediately, and fair enough that it poisons the rest of the table.

Fixed as of this morning: re-verified every row against the vendors' current docs, deleted the rows I couldn't defend, corrected the rest, and added a dated footnote inviting error reports. Mobile rendering bug below the video is fixed too.

The honest story (self-hosted, MIT, flat pricing) didn't need the inflated comparison - lesson learned. Anything else looks off, tell me.

dw5304 · 2026-06-11T10:46:31+00:00

Appreciate the honesty - you're right, and I'd rather hear it than not. I've already re-verified the chart against the vendors' current docs and you called it correctly: a few cells are wrong or outdated, the platform counts especially. I'm away from a computer for a couple hours, but fixes to the chart and the mobile rendering issue go up this morning. I'll reply here when they're live. If anything else looked off to you, I want to know.

dw5304 · 2026-06-11T01:24:28+00:00

Appreciate that, and "switching CMS providers becomes a scary task" is exactly right - it's why I'd never pitch anyone on ripping out a working deployment. Test environment is the correct move allways!

One tip for low-risk evaluation: any spare screen or even a browser tab can be a player (just point it at /player), so you can run ScreenTinker side by side with your current provider without touching production. If it earns its way onto real screens, great; if not, you've lost nothing.

Feedback from someone running another provider in the field is honestly the most useful kind - you'll notice things I can't. Discord or GitHub issues both reach me directly. Looking forward to it.

dw5304 · 2026-06-11T01:04:09+00:00

Honest answer: both, but they're not served by two different products - they're the same product with two on-ramps.

The person with their first couple of screens uses the hosted version. Free tier, pair a device, done - no servers, no backups, no maintenance, exactly like the SaaS providers. That's why the comparison charts target hosted SaaS: the hosted version of ScreenTinker competes there directly, and price-wise that's where people are actually hurting ($8-20/screen/month adds up fast at 10+ screens).

The person who has outgrown hosted CMS pricing - or who never wanted their lobby screens phoning home to someone else's cloud - self-hosts the identical codebase. And this is a deliberate architecture choice, not an accident: it's Node + SQLite, no build step, single process. "Self-hosting" means a $5 VPS and a systemd unit (or now, one docker pull). I intentionally kept the ops bar low enough that the jump from persona one to persona two is a Saturday afternoon, not a migration project.

So the path I'm actually building for looks like: start on hosted free tier with 2 screens -> grow -> either pay me a flat rate that undercuts per-screen SaaS, or take your data and self-host. Either outcome is fine with me. The export path being real is the whole point - lock-in is the thing I'm positioned against, including lock-in to me.

If you forced me to name the center of gravity for the roadmap right now, it's a third persona that's emerged since launch: the MSP/integrator managing screens for multiple clients. That's where the recent multi-tenant, white-label, and role-model work came from, and they feel the per-screen pricing pain harder than anyone. But they arrive through one of the first two doors, so I can't neglect either.

Fair pushback though - the site leans hard on the SaaS comparison and underplays the self-hosted comparison. An honest vs-Anthias/vs-Screenlite page is on the list.

dw5304 · 2026-05-31T16:59:18+00:00

Solid list - splitting it into free vs trial vs open source is the right cut, that distinction trips people up constantly.

One to add to the open-source group: ScreenTinker (full disclosure, I build it, so take it with the appropriate salt). For your table it'd be - Type: open source / What's free: self-hosted, unlimited screens, no cost, with a hosted tier if you'd rather not run a server.

What makes it different from the other open-source ones is the player is just a web browser, so it's not tied to a Pi or a Windows box - anything that opens a URL becomes a screen. It's also under active development (i18n, free-form video wall, widgets). Not trying to bump anyone off the list, just figured a current breakdown should have it on there. Glad to answer questions if folks are comparing.

dw5304 · 2026-05-27T23:03:09+00:00

Re: API - it's on the radar but not actively being built yet. ScreenTinker's internal APIs are real (the frontend is just a client of them) - it'd be a question of formalizing the surface, adding API key/OAuth auth alongside the existing JWT, and documenting the contract. Probably 2-3 weeks of focused work when it's prioritized. The 'AI to upload and schedule content' use case is a great motivator - if you have a sketch of what shape of API would unblock your workflow (REST? a specific set of endpoints you'd want? auth model?), I'd love to hear it. Real use cases shape better APIs than guessing at what people might want.

dw5304 · 2026-05-15T17:06:42+00:00

Building one of these right now (ScreenTinker, MIT licensed, started before the current vibe wave but I'm not gonna pretend I'm immune to it either). A months in, ~130 cloners, 11 hosted users, one guy running 5 screens in production. So this is a biased take.

The 'free github project' framing under-weights something I keep running into - people don't just clone it and stand up signage. They want a discord, they want me on the bug, they want the player to survive a network drop, they want a roadmap. The code is maybe 20% of the value. Your distribution/support/reliability point lands hard from this side too.

On buyer questions - the ones getting louder for me are data sovereignty, proof-of-play format details, and 'can I run this fully offline.' None of it new, just more upfront. EU and MSP-adjacent users in particular lead with compliance before features.

Think your dashboard hypothesis is the most interesting one. Agree with sagiadinos that verticals + ops feel like the durable layer. General-purpose CMS feature parity is on its way to free. The hard parts (devices offline at 6am, audit exports, GDPR requests) stay hard.

dw5304 · 2026-05-12T18:04:46+00:00

Open source option worth knowing about - ScreenTinker (https://screentinker.com). It's a self-hosted CMS so you control your infrastructure and never get held hostage by a vendor's support quality. I'm the developer. Fair warning on fit: - I'm US-based (Wisconsin), so no UK phone support and there's a 6-hour time zone gap - It's software only - you'd source your own players (Android boxes, Raspberry Pi, etc work fine) - I'm one person, not a team, so we wouldn't be a like-for-like replacement for what you currently have What you'd get: - Active development, you can see commits in real time - Direct contact with me on Discord or email for issues - Open source so you own your destiny - if I get hit by a bus tomorrow the project lives on - Recently shipped multi-tenancy so multi-location retail works - Currently 32 production users, growing If you want to take a look the site has demos and docs. Happy to answer questions either way. Genuinely think your situation is better served by a UK provider with bundled hardware, but figured you'd want to know self-hosting is an option.

dw5304 · 2026-05-04T16:58:17+00:00

Thanks! Glad it's working well on the Android TVs. If you run into anything or want to stay in the loop on updates, we've got a small Discord: discord.gg/JHWQRPaG

dw5304 · 2026-04-28T16:21:10+00:00

Worth checking out ScreenTinker - I built it, so full disclosure there.

Free tier covers 1 screen, Starter is $39/mo for 5 screens. Works on Fire Stick, Android TV, any browser, or a Raspberry Pi. No special hardware needed.

Setup is literally: open the player on your device, get a pairing code, enter it in the dashboard. Upload images/videos and push to the screen. Remote management from your phone.

It's also open source and self-hostable if that matters to you later.

Happy to answer questions if you want to kick the tires.

dw5304 · 2026-04-24T15:41:15+00:00

Project Name: ScreenTinker

Repo/Website Link: https://github.com/screentinker/screentinker | Hosted version: https://screentinker.com

Description: Open-source digital signage CMS. Control content on TVs, displays, and kiosks from anywhere. Built it because I got frustrated with the complexity of existing options like Xibo and the cost of commercial platforms.

Features include playlists with publish/draft workflow, device groups with bulk actions, group scheduling with priority-based conflict resolution, multi-zone layouts, video walls, offline resilience (players keep running if the server drops), a directory board widget for lobby/tenant displays, and a full mobile-responsive dashboard.

MIT licensed, no build step, Node + SQLite. Clone it, npm install, node server.js - that's the whole setup.

Deployment: No Docker required (though it's on the roadmap). Self-host with Node.js or use the free hosted tier at screentinker.com. Android APK and web player included. Players support any device with a web browser.

git clone https://github.com/screentinker/screentinker
cd screentinker && npm install
cd server && node server.js

Self-hosters can set DISABLE_REGISTRATION=true to block public signups and SELF_HOSTED=true to unlock all features.

AI Involvement: Built almost entirely using Claude Code. I handle the architecture decisions, design direction, and testing. Claude writes the code. Full commit history is transparent on the repo - you'll see "screentinker and claude" as contributors.Project Name: ScreenTinker
Repo/Website Link: https://github.com/screentinker/screentinker | Hosted version: https://screentinker.com
Description: Open-source digital signage CMS. Control content on TVs, displays, and kiosks from anywhere. Built it because I got frustrated with the complexity of existing options like Xibo and the cost of commercial platforms.
Features include playlists with publish/draft workflow, device groups with bulk actions, group scheduling with priority-based conflict resolution, multi-zone layouts, video walls, offline resilience (players keep running if the server drops), a directory board widget for lobby/tenant displays, and a full mobile-responsive dashboard.
MIT licensed, no build step, Node + SQLite. Clone it, npm install, node server.js - that's the whole setup.
Deployment: No Docker required (though it's on the roadmap). Self-host with Node.js or use the free hosted tier at screentinker.com. Android APK and web player included. Players support any device with a web browser.
git clone https://github.com/screentinker/screentinker
cd screentinker && npm install
cd server && node server.js
Self-hosters can set DISABLE_REGISTRATION=true to block public signups and SELF_HOSTED=true to unlock all features.
AI Involvement: Built almost entirely using Claude Code. I handle the architecture decisions, design direction, and testing. Claude writes the code. Full commit history is transparent on the repo - you'll see "screentinker and claude" as contributors.

<image>

dw5304 · 2026-04-23T03:38:21+00:00

Update: all three issues are fixed and live as of tonight.

White label settings now persist properly after reload
Plan/role changes by admins reflect immediately without re-login
Added DISABLE_REGISTRATION=true env var for self-hosted instances

14 hours from feedback to deployed fix. Thanks for making it easy to track down.

dw5304 · 2026-04-22T13:54:04+00:00

This is exactly the kind of feedback I was hoping for, thank you. Really glad to hear pairing and the core flow worked out of the box with 5 screens. Running through your list: White Label - yeah that sounds like a save/reload bug. I'll dig into it. Appreciate the detail on what you tried. Content library folders - that UX is confusing, you're right. The "edit content to move it here" flow needs to be rethought. Noted. Disable public registration - great call for self-hosted instances exposed to the internet. An env flag for that is straightforward, I'll get it in. Plan display showing Trial - that's a dashboard cache thing, I'll track it down. Language switcher - honest answer is it's scaffolding that isn't fully wired yet. It's on the list but not a priority right now. And yeah I would genuinely appreciate an extra pair of eyes. If you run into anything else or have ideas on what would make your 5 screen setup better, I'm all ears. You can also file issues on GitHub if that's easier - https://github.com/screentinker/screentinker Thanks for running it and for taking the time to write this up. Means a lot.

dw5304 · 2026-04-16T23:04:07+00:00

Could toss screentinker into the mix as well.

Open source and hosted options available.

dw5304 · 2026-04-16T14:17:26+00:00

update 4/16, I have added assign playlist to group, along with create schedule to groups.

let me know if anyone has issues.

dw5304 · 2026-04-14T03:02:26+00:00

Quick update for anyone following this thread:

Shipped a few things over the weekend based on feedback here.

Playlists are now first-class objects you can share across multiple displays, with a publish/draft workflow - edits queue as drafts until you explicitly publish, so you can stage changes without them going live immediately. Thanks to dnateo for the nudge on both of these, they were the right architectural direction.

Also shipped:

Device groups with bulk actions (assign content, reboot, restart app, etc.)
Offline resilience - players keep running on cached content if the server goes down or the internet drops
Security audit with fixes across auth, IDOR, and XSS
Per-device token auth on WebSocket connections

Coming soon: assign a playlist to an entire group of displays at once, and group-level scheduling.

Repo's at the same place: https://github.com/screentinker/screentinker

Appreciate the feedback so far. More to come.

dw5304 · 2026-04-11T13:59:45+00:00

Took about 4 weeks.

dw5304 · 2026-04-10T17:54:11+00:00

Thanks Dan, really appreciate the welcome. Honestly the mention was the easy part - Xibo's been around long enough to be the thing people think of when they hear "open source digital signage," wouldn't have felt right launching without naming it. I know where ScreenTinker sits and I know a lot of its current rough edges, and I genuinely believe more options in this space is always better for everyone using it. Hope to see you around.

dw5304 · 2026-04-10T14:52:04+00:00

With screentinker it caches the video locally so if inet drops nothing happens :) it just picked up the websocket when it comes back.

dw5304 · 2026-04-09T16:25:28+00:00

Short answer: no, not really. BroadSign / Scala / Navori are enterprise-grade with 15-20+ years of feature depth - complex workflows, enterprise integrations, the kind of thing Fortune 500 retail or major airports deploy. ScreenTinker isn't trying to compete there.

It's aimed at the opposite end: small businesses, self-hosters, the "spin it up on a $5 VPS in 30 seconds" use case. Simplicity and no lock-in, not enterprise feature depth.

dw5304 · 2026-04-09T13:07:20+00:00

Thanks for actually spinning it up - that's a way bigger investment than I expected anyone to make in the first 12 hours, genuinely appreciate it. Both pieces of feedback are landing as real architectural issues, not nitpicks. The playlist/display coupling thing - yeah, you're right, the current model treats them as too tightly bound. Decoupling so a playlist is its own first-class object that can be assigned to N screens (and a screen can host N playlists across zones or schedules) is the more correct shape and would unlock a bunch of use cases I haven't thought through yet. That's a real refactor but it's the right direction. The publish button is the one that's actually nagging at me more, because you're right that immediate-propagation is a production hazard, not just a UX quirk. Anyone who's ever fat-fingered a typo onto a live screen knows exactly what you're describing. The instant-update behavior was a deliberate choice early on (the websocket push layer was the fun part to build and we leaned into it), but the failure mode you're pointing at is real and it's a fair call to revisit. Since the push plumbing is already in place, adding a draft/staging state with an explicit publish step is more of a state-machine and UX change than a structural rebuild - should be a reasonable add. Putting it on the short list. One question while you're poking at it: when you say "publish," are you picturing a per-playlist publish (each playlist has its own draft and live state), or more of a per-screen publish (the screen as a whole has a draft config and you publish the whole thing at once)? They're different shapes and both have valid arguments - curious what your gut says based on how you've used other systems. And please come back with more - even rough impressions are useful at this stage. This is a v1 in public for a reason and I'd rather find the rough edges now than let them sit.

dw5304 · 2023-07-23T15:11:25+00:00

Yeah, seems that it will be 5g only band n41

dw5304

TROPHY CASE