If you’ve read anything we’ve published in the last couple of years, you already know how we feel about security. We won’t repeat the speech. What we will say is that when we built Tailscale support, the same thinking applied: minimum required access, nothing stored that doesn’t need to be, no new surface area created just for convenience.

The result: workspace-wide Tailscale integration is now available for Screenly players. The workspace settings are available today, and the ScreenlyOS update that enables it on your players is rolling out now.

This is also a good moment to introduce a name we’ve been meaning to put to something that already exists: ScreenlyOS. It’s what we’re calling the firmware that runs on Screenly players (Raspberry Pi, x86, and DIY Raspberry Pi setups). Same thing it’s always been, just with a proper name now.

Why this matters

A lot of the content digital signage displays isn’t public. Internal dashboards, intranet pages, data feeds from systems that only exist inside a corporate network. If your Screenly players can’t reach those resources, you’re limited to what lives on the open internet.

The traditional workarounds aren’t pretty. Exposing an internal service through a reverse proxy just for signage. Whitelisting device IPs in firewall rules that change every time a player moves locations. It works, technically, but it’s the kind of infrastructure that quietly accumulates toil.

Tailscale removes all of that. Once a Screenly player is on your Tailnet, it can reach anything else on that network: internal URLs, private APIs, self-hosted data sources. No firewall rules, no per-device configuration, no exposed services. The kind of content that makes signage actually useful, with none of the plumbing that usually comes with it.

All your players, connected in a few clicks

What makes this integration useful beyond just “Tailscale works on the player” is that it operates at the workspace level. You connect once, and every Screenly player in your workspace joins your Tailnet automatically. No touching each player individually, no pushing config files manually.

You connect your Tailscale account via OAuth from workspace settings, and Screenly issues a reusable auth key that gets delivered to all players in your workspace automatically.

The OAuth client only needs one scope: auth key creation. Screenly requests nothing else. If you’re creating the OAuth client in Tailscale and notice it has broader permissions than that, it’s worth creating a new one with just the auth keys scope to keep things tight.

One thing worth knowing about device approval

By default, Screenly players will join your Tailnet automatically when the integration is active. If you want to review and approve each player before it can connect, that’s a Tailscale-side setting: device approval can be enabled from the Device management page in the Tailscale admin console.

When device approval is enabled on your tailnet, the non-preauthorized keys that Screenly issues mean players will show up as pending and wait for an admin to approve them before joining. If device approval is not enabled, players join automatically. Either way, the behavior is controlled from your Tailscale settings, not from Screenly.

A note on ACL tags

Screenly uses ACL tags to identify devices on your Tailnet. One thing worth knowing before you start: the tag needs to exist in your Tailscale ACL policy before you create the OAuth client, and tags can’t be added to an existing client after the fact. Worth sorting out upfront to avoid having to redo the setup.

Where to find it

Go to Workspace settings > Security. The section is labeled “Tailscale on screens” and walks you through connecting your Tailscale account via OAuth. Once that’s done, the integration is active for the whole workspace. Any setup errors (missing OAuth scopes, tags not defined in your ACL policy, invalid credentials) surface as specific messages that tell you exactly what to fix.

Per-device auth key configuration is not in this release. Workspace-level is the scope for now, and we want to make sure that’s solid before layering anything on top.

If you’ve been holding off on deploying Screenly players in certain environments because of network constraints, this should open some doors. Give it a try and reach out to support if you run into anything.