Screenly CLI 26.9.0: Your CI decides which Edge App a deploy goes to, not screenly.yml

Thu, 03 Sep 2026 00:00:00 +0000

Every Edge App in your Screenly account has an ID, and it’s how the CLI knows which app to publish to when you run screenly edge-app deploy. Until now that ID lived in the id field of screenly.yml, next to your code. The CLI now looks for it in the EDGE_APP_ID environment variable first, so whatever runs the deploy decides where it goes: a secret in your GitHub Actions workflow, or a variable in your own shell.

That matters as soon as more than one person or more than one account deploys the same code. An ID in screenly.yml belongs to one account but gets committed to a repository other people clone, so teams end up deploying over each other’s app or editing the file back and forth. With the ID in the environment, the manifest is the same for everybody, and the GitHub Actions take it as an input for the same reason.

The id field in screenly.yml still works when EDGE_APP_ID isn’t set, but the CLI prints a deprecation warning each time it falls back to it, and it will go away.

screenly edge-app create respects the variable too, including --in-place. With EDGE_APP_ID set, create checks that the app exists and targets it rather than making a new one, and writes nothing into screenly.yml.

If you script create with a name: the name no longer decides which app you get while EDGE_APP_ID is set. The deploy that follows republishes over the app the variable names, so a new name gives you a new revision of the existing app rather than a new app. Unset the variable where you actually want a new one.

Screenly CLI 26.9.0 | Screenly

Screenly CLI 26.9.0: Your CI decides which Edge App a deploy goes to, not screenly.yml