Edge Apps GitHub Actions release notes | Screenly

Edge Apps GitHub Actions 26.10.2: Checks, initialize, and update now come as reusable workflows

Mon, 26 Oct 2026 00:00:00 +0000

Until this release, every Edge App repo carried its own full copy of the example workflows: the triggers, the jobs for each environment, the production tag check, and the id expressions. Now those live in this repo as reusable workflows, and an app’s workflow file calls them:

name: Update Edge App

on:
 workflow_dispatch:
 push:
 branches: [main, master]
 tags: ['v[0-9]*']

permissions:
 contents: read

jobs:
 update:
 uses: Screenly/edge-apps-actions/.github/workflows/update.yml@v26.10.2
 secrets:
 SCREENLY_API_TOKEN: ${{ secrets.SCREENLY_API_TOKEN }}

When a later release changes how deploys work, bumping that pin is all it takes. Copy the 3 files in examples/ into your app’s .github/workflows/ to start.

Workflow	Inputs	Secrets
`checks.yml`	`bun-version` (default `latest`)	none
`initialize.yml`	`environment`, `edge_app_name`, `edge_app_title`	`SCREENLY_API_TOKEN`
`update.yml`	`delete_missing_settings` (default `true`)	`SCREENLY_API_TOKEN`

update.yml deploys to stage on a push or a manual run on the default branch, and other branches never deploy. It deploys to production when you push a v* tag whose commit is on the default branch, through the production environment and its reviewers. checks.yml cancels a check still running on a branch when a newer push to that branch arrives.

Setting up an app

Create the GitHub environments stage and production, and add SCREENLY_API_TOKEN to each as an environment secret. An environment secret only reaches jobs that run in that environment, so the production token stays behind production’s reviewers.
Run “Initialize Edge App” for stage. Once the run has finished successfully, set the repository variable STAGE_EDGE_APP_ID to the id in its job summary. Setting it earlier lets a deploy start while Initialize is still running.
Do the same for production and PRODUCTION_EDGE_APP_ID.

delete_missing_settings is true in update.yml, so the manifest decides which settings exist. The update action on its own still defaults to false. To keep settings that aren’t in your manifest, pass delete_missing_settings: false under with:.

The checks, initialize, and update actions are still there to use as steps in a workflow of your own.

Edge Apps GitHub Actions 26.10.2: Deploys to an environment run one at a time

Mon, 26 Oct 2026 00:00:00 +0000

Merge 3 pull requests into main in a row, and the update workflow deploys the first to stage while the second waits. When the third arrives, it takes the second’s place in line. Stage ends up on the newest commit after 2 deploys, and a running deploy is never cancelled to get there.

Production tags queue the same way, separately from stage. If an older production run is still waiting for a reviewer, reject it so the newest one goes next.

Initialize has a queue of its own, so a push can’t take the place of an Initialize run that’s waiting.

To redo a failed or cancelled production deploy, re-run that tag’s workflow run. You don’t need a new tag. If the earlier run stopped part-way, the re-run can report success while the app stays on its previous revision, so check the live revision in Screenly afterward. If it didn’t move, push a new tag with a change to the app’s files.

Edge Apps GitHub Actions 26.10.2: The initialize action won't create the same app twice, and other fixes

Mon, 26 Oct 2026 00:00:00 +0000

Fixes

If package.json can’t be parsed, initialize and update stop with an error instead of deploying the repo root.

Improvements

initialize stops if an Edge App with the same name already exists in that environment, so running it twice can’t create 2 apps. If it can’t get the list of Edge Apps to check, it stops without creating anything.

Edge Apps GitHub Actions 26.10.1: Initialize runs once per environment and shows the new id right away

Sat, 24 Oct 2026 00:00:00 +0000

initialize is for the first deploy to an environment, and it holds to that now. Pass it the environment’s id variable, and if the variable is set, the run stops with an error that points you to update:

- uses: Screenly/edge-apps-actions/initialize@v26.10.1
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 edge_app_name: ${{ inputs.edge_app_name }}
 edge_app_title: ${{ inputs.edge_app_title }}
 environment: ${{ inputs.environment }}
 edge_app_id: ${{ (inputs.environment == 'production' && vars.PRODUCTION_EDGE_APP_ID) || (inputs.environment == 'stage' && vars.STAGE_EDGE_APP_ID) || '' }}

The new app’s id shows up as soon as the app exists, before the build and deploy steps: as a notice in the log, and under “Edge App id” in the job summary, together with the name of the variable to set. If a later step fails, you still have the id.

To start an environment over, delete its Edge App in Screenly, clear the id variable, and run initialize again.

If this affects you: if a workflow runs initialize with edge_app_id set to deploy to an app that already exists, that run now fails. Move that job to the update action, which takes the same screenly_api_token, environment, and edge_app_id inputs.

Edge Apps GitHub Actions 26.10.1: Any app with a build script is built and deployed from dist

Sat, 24 Oct 2026 00:00:00 +0000

initialize and update build any app whose package.json has a build script, and deploy it from dist/, whether or not it depends on @screenly/edge-apps. Apps without a build script deploy from the repo root as they are.

Edge Apps GitHub Actions 26.10.0: The update action needs an edge_app_id on every deploy

Thu, 08 Oct 2026 00:00:00 +0000

update requires edge_app_id now. If it’s empty, or holds a leftover like false, null, or 0 from an expression that didn’t resolve to an id, the run stops in its first step and names the variable to set: STAGE_EDGE_APP_ID or PRODUCTION_EDGE_APP_ID.

Both initialize and update also stop before doing anything else when:

screenly_api_token is empty. The error asks you to add the SCREENLY_API_TOKEN secret for that environment, since stage and production each need one.
environment is anything other than stage or production.
Screenly rejects the token for that environment. initialize checks this now too, before it creates an app.

initialize treats the same leftovers (false, null, 0, and so on) as no id at all, so a first run creates the app as expected.

If this affects you: if any update step runs without edge_app_id, add the repository variables STAGE_EDGE_APP_ID and PRODUCTION_EDGE_APP_ID with each environment’s Edge App id, and pass edge_app_id: ${{ vars.STAGE_EDGE_APP_ID }} or ${{ vars.PRODUCTION_EDGE_APP_ID }} to each update step. Check that both environments have a SCREENLY_API_TOKEN secret before you bump your pin to v26.10.0.

Edge Apps GitHub Actions 26.9.1: Stage and production both deploy from screenly.yml

Mon, 21 Sep 2026 00:00:00 +0000

initialize and update read screenly.yml in stage and production alike. screenly_qc.yml isn’t read anymore, whether or not you pass edge_app_id.

That also means an app with only screenly.yml can run its first initialize in stage. Leave edge_app_id out for that first run, then set the environment’s variable to the id of the app it created. Every run after that passes the id:

- uses: Screenly/edge-apps-actions/update@v26.9.1
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 environment: stage
 edge_app_id: ${{ vars.STAGE_EDGE_APP_ID }}

The id you pass wins over any id in screenly.yml, so 1 manifest serves both environments.

If this affects you: if your repo has a screenly_qc.yml, move to 1 manifest before you bump your pin to v26.9.1. Copy anything that differs into screenly.yml and delete screenly_qc.yml. Add the repository variables STAGE_EDGE_APP_ID (the id from screenly_qc.yml) and PRODUCTION_EDGE_APP_ID (the id from screenly.yml), and pass edge_app_id: ${{ vars.STAGE_EDGE_APP_ID }} to your stage steps and edge_app_id: ${{ vars.PRODUCTION_EDGE_APP_ID }} to your production steps.

Edge Apps GitHub Actions 26.9.0: Each environment's Edge App id comes from a repository variable

Tue, 08 Sep 2026 00:00:00 +0000

An Edge App that runs in stage and production has 2 ids, and until now each one lived in its own manifest: screenly_qc.yml for stage and screenly.yml for production. A setting added to one file had to be added to the other.

With the new edge_app_id input, the id comes from the workflow instead. Keep each environment’s id in a repository variable and pass the matching one:

- uses: Screenly/edge-apps-actions/update@v26.9.0
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 environment: stage
 edge_app_id: ${{ vars.STAGE_EDGE_APP_ID }}

When edge_app_id is set, the action reads screenly.yml in both environments, and the id you pass wins over any id in the manifest. So 1 manifest serves stage and production, and only the variable changes between them.

Leave it out and nothing changes: stage still reads screenly_qc.yml, and production reads screenly.yml, each with its own id.

Edge Apps GitHub Actions 26.9.0: The actions' version numbers moved to CalVer

Tue, 08 Sep 2026 00:00:00 +0000

Releases of the Edge Apps GitHub Actions are numbered by year and month now, so the release after 1.3.0 is 26.9.0. That’s the same scheme Screenly, ScreenlyOS, the CLI, and the Edge Apps library use.

Each release is 1 fixed tag, such as v26.9.0, and there’s no moving tag that follows the latest release. v1 stays on 1.3.0 for good. A workflow that uses @v1 keeps running exactly what it ran before, and it won’t get anything released from here on.

Nothing about the actions’ behavior changes with the numbering.

If this affects you: a workflow that uses @v1 won’t pick up new releases. Replace @v1 with an exact tag, such as Screenly/edge-apps-actions/update@v26.9.0, and bump it when you want a newer release. Dependabot’s github-actions updates can open those bumps for you.

Edge Apps GitHub Actions 26.9.0: Builds work with the Edge Apps library in dependencies, and other improvements

Tue, 08 Sep 2026 00:00:00 +0000

Fixes

initialize and update build your app when @screenly/edge-apps is listed under dependencies, not only under devDependencies.

Improvements

initialize and update run Screenly CLI 26.9.0 instead of whichever CLI release is newest, so a new CLI release doesn’t change how your app deploys until you move to a newer version of the actions.

Edge Apps GitHub Actions 1.3.0: Settings deleted from the manifest are removed from Screenly too

Fri, 24 Apr 2026 00:00:00 +0000

A deploy adds and updates the settings in your manifest, and leaves alone any setting that’s in Screenly but no longer in the file. When the manifest is the only place you manage settings, set delete_missing_settings and those leftovers go too:

- uses: Screenly/edge-apps-actions/update@v1
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 environment: production
 delete_missing_settings: true

It’s false by default, so a deploy only deletes settings when you ask it to.

Edge Apps GitHub Actions 1.2.2: Deploy logs no longer list your other Edge Apps

Fri, 24 Apr 2026 00:00:00 +0000

Improvements

The update action no longer prints the names of every Edge App in your account to the deploy log. The log shows the app you’re deploying and nothing else.

Edge Apps GitHub Actions 1.2.1: The update action checks your API token before it builds

Fri, 24 Apr 2026 00:00:00 +0000

The update action checks screenly_api_token against Screenly before it builds anything. If Screenly rejects the token, the run stops right there and the log shows the HTTP status.

Edge Apps GitHub Actions 1.2.0: A new update action deploys an existing Edge App

Wed, 22 Apr 2026 00:00:00 +0000

Once initialize has created an Edge App, the update action ships each new version of it. Put it in a workflow that runs on push, and every merge reaches Screenly without anyone running the CLI by hand:

- uses: Screenly/edge-apps-actions/update@v1
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 environment: stage # optional, defaults to stage

It builds the same way initialize does. If package.json lists @screenly/edge-apps under devDependencies, it installs with Bun, runs bun run build, and deploys dist/. Otherwise it deploys the repo root as it is.

The app it deploys to is the one whose id is in the manifest: screenly_qc.yml for stage and screenly.yml for production.

Edge Apps GitHub Actions 1.1.0: A new initialize action creates an Edge App and its first instance

Wed, 22 Apr 2026 00:00:00 +0000

The initialize action takes an Edge App from a repo to a running instance in 1 workflow run. It creates the app in Screenly, deploys the code, and creates an instance:

- uses: Screenly/edge-apps-actions/initialize@v1
 with:
 screenly_api_token: ${{ secrets.SCREENLY_API_TOKEN }}
 edge_app_name: my-edge-app
 edge_app_title: My Edge App
 environment: stage # optional, defaults to stage

edge_app_name is the app’s name, and edge_app_title is the title its instance gets. environment is stage or production. Stage reads its manifest from screenly_qc.yml, and production reads screenly.yml.

If package.json lists @screenly/edge-apps under devDependencies, the action installs dependencies with Bun, runs bun run build, and deploys dist/. Any other app is deployed from the repo root as it is.

The job log ends with the manifest and instance.yml, so you can copy the new app’s id into the manifest in your repo for later deploys.

Edge Apps GitHub Actions 1.0.0: A checks action runs an Edge App's formatting, lint, build, and tests in 1 step

Mon, 20 Apr 2026 00:00:00 +0000

The checks action runs the usual CI steps for an Edge App as 1 step in your workflow. Add it after the checkout step:

- uses: Screenly/edge-apps-actions/checks@v1
 with:
 bun-version: latest # optional

It sets up Bun, installs dependencies with bun install --frozen-lockfile, and then runs these scripts from your package.json, stopping at the first one that fails:

format:check
lint
build
test

So the repo needs all 4 scripts and a committed Bun lockfile. bun-version picks the Bun release, and it’s latest when you leave it out.