# Where an app runs


> On ScreenlyOS an app runs on the device. On Screenly Anywhere it renders on our servers, so no credential ever reaches the screen.
Most of the time this does not matter. When an app behaves differently on one screen than another, this is usually why.

## On the device

On ScreenlyOS the app runs on the player itself: real code in a real browser engine, refreshing on its own schedule, reacting to whatever it is showing.

## On our servers

On Screenly Anywhere, the app runs on our infrastructure and the screen is sent an image of the result.

That is a security decision rather than a capability one. Anywhere runs as a web application on an operating system we do not control, and anything a browser tab holds is readable by whoever has the device. So the playlist an Anywhere screen receives carries **no secrets at all**: the app runs where its credential can be used without being exposed, and the screen gets a picture.

The screen still shows the right thing and it still stays current. What it never receives is the token that produced it.

[Secrets and where code runs](/docs/apps/overview/secrets-and-where-code-runs/) explains the mechanism, and why client certificates and private network access follow the same rule.

## What this means in practice

A dashboard, a calendar, a news feed, a menu board all look the same either way, because they are pictures of data that changes every few minutes.

An app with motion in it, or one that reacts to the second, wants a device that runs it locally. See [Supported platforms](/docs/anywhere/overview/supported-platforms/) for what each platform does.