Scheduled re-recording

Your app changes every week; your demos shouldn't go stale. A schedule re-runs a take's steps when you say: every weekday morning, after each deploy, or both. DemoTake compares every scene with the last run, re-records only the scenes whose UI changed, keeps your edits (captions, zooms, redactions, music), exports, and can update the take's share links so every embed shows the new version. You get a message in Slack or by email with what changed.

Scheduled re-recording comes with the Team plan. The take must be in DemoTake Cloud: open it in DemoTake Web, or sync it from DemoTake for Mac.

#Create a schedule

In DemoTake Web, open the take and choose Re-record on a Schedule (the calendar button next to Share). In DemoTake for Mac, right-click the take and choose Re-record on a Schedule….

• When: weekdays, every day or every Monday at a time in your time zone, a custom cron expression (0 9 * * 1-5, in the time zone you pick), or only after deploys. On Team, runs are at least an hour apart; on Enterprise, at least 15 minutes.
• After each deploy: turns on the deploy webhook (see below).
• Re-record only scenes whose UI changed (on by default). Unchanged scenes keep their footage.
• Test only: run the steps and checks and compare the scenes, but record and publish nothing. A good way to start.
• Open this URL instead: point a web take at staging or a preview deploy.
• Export: the formats, languages and the interactive demo to produce.
• Share links: update them after approval (the default), automatically, or never. The schedule shows this setting as Publishes after approval, Publishes automatically or Links unchanged.
• Notify: Slack, a signed webhook, and email to workspace admins.

The take's own recorded steps are what runs. Agents and the CLI can also give a schedule a demotake.json.

#Who records: runners

A run needs a Mac to record on, called a runner. There are two kinds:

• This Mac. In DemoTake for Mac (the direct-download edition), turn on Settings › Account › Use this Mac as a runner. While DemoTake is open, the Mac picks up runs when they are due. A Mac mini that stays on is ideal. Keep it awake and signed in to the apps you record.
• CI on a Mac. In DemoTake Web, open Re-record on a Schedule › Runners › Add Runner, copy the runner token (shown once) into your CI secrets as DEMOTAKE_RUNNER_TOKEN, and run demotake runner on a macOS runner with DemoTake installed.

A runner keeps its own copy of each take in a Scheduled Runs project, records there, and sends the new recording back to DemoTake Cloud. The take you edit stays as it is until you open the new version.

Web takes can also be checked without any Mac: choose Cloud check under How. DemoTake's cloud browser runs the take's web steps and checks and tells you which scenes changed. It doesn't record; pair it with a runner schedule to re-record.

#Deploy webhooks

With After each deploy on, creating the schedule shows a trigger token and a hook URL once. Store them now; DemoTake keeps only a hash. Then:

• GitHub Actions: add the token as the DEMOTAKE_TRIGGER_TOKEN repository secret and add a step after your deploy:

      - name: Re-record the demo
        if: success()
        run: |
          curl -fsS -X POST "https://api.demotake.my/v1/schedules/sch_…/trigger" \
            -H "Authorization: Bearer ${{ secrets.DEMOTAKE_TRIGGER_TOKEN }}"

• GitHub deployments: add a repository webhook for Deployment statuses with the trigger URL and the token as the secret. Only successful deployments start a run.
• Vercel or Netlify: paste the hook URL as a deploy notification (it contains the token, so treat it like a password).
• Anything else: POST the trigger URL with Authorization: Bearer <token>, or sign the body (X-DemoTake-Signature, see the REST API).

A trigger while a run is still waiting doesn't start a second one. New Token replaces the token; the old one stops working at once.

If you run your own CI on a Mac anyway, the same job can trigger the run and serve it:

name: Re-record demos
on:
  deployment_status:
jobs:
  rerecord:
    if: github.event.deployment_status.state == 'success'
    runs-on: [self-hosted, macOS, demotake]
    steps:
      - run: |
          curl -fsS -X POST "https://api.demotake.my/v1/schedules/sch_…/trigger" \
            -H "Authorization: Bearer ${{ secrets.DEMOTAKE_TRIGGER_TOKEN }}"
      - run: demotake runner --once --wait 600
        env:
          DEMOTAKE_RUNNER_TOKEN: ${{ secrets.DEMOTAKE_RUNNER_TOKEN }}

#Review, approve and roll back

Each run shows its status, what triggered it (a deploy with its branch and commit, the schedule, or Run Now), which scenes changed and why, before and after pictures of each changed scene, the checks, and the exports. The pictures come from the edited take, so blurred and masked areas stay hidden.

• Needs approval: Approve and Publish switches the take's share links to the new exports. Reject keeps the current version (DemoTake asks first; a rejected run can't be published later).
• Published: the links show the new version with the same URL, embeds and analytics. Roll Back puts the previous version back on every link the run updated, right away (DemoTake asks first; the run can't be published again).

Only the schedule's creator and workspace admins can approve, reject, roll back or change a schedule; others see the runs and who to ask. Deleting a schedule, getting a new trigger token and removing a runner ask first too: the old token stops working at once, so CI that uses it fails until it's updated.

• Failed: a step or a check didn't pass. The links keep the version they had; a failed run never changes them.
• No changes: nothing changed, so nothing new was exported.

Links update when the run exported the same kind of file (video, GIF, Reviewer Pack or interactive demo) and, for videos, the closest aspect ratio. Each link keeps its last versions for rollback.

#Notifications

Choose when to hear about runs: changes, approvals and failures (the default), every run, failures only or never. Slack messages and emails say what changed, show pictures of the changed scenes and link to the run. The pictures' links stop working after 7 days.

A webhook gets a signed JSON body (X-DemoTake-Signature: t=…,v1=…, HMAC-SHA256 with the signing secret shown once). Verify it before you trust it.

#Limits

Team includes 300 runs a month per seat, shared by the team. Enterprise includes 2,000 runs a month. The schedule sheet shows what's used. Runs wait in a queue when a workspace already has several running. A run nobody picks up within a day expires, and you're told so. Run minutes are counted and shown; they run on your own Macs. Cloud checks use the workspace's cloud browser minutes.

#Privacy and security

• Raw recordings stay private to your workspace, like synced takes. Everything that can be public (share links, posters, link previews, embeds) comes from the rendered export, with your redactions.
• Runs never record the presenter camera or the microphone, even when the take was recorded with them. Scenes a run records again show no camera.
• Runner tokens and trigger tokens are shown once and stored as hashes. Slack and webhook URLs are stored encrypted.
• Secrets for secret_env steps never leave the runner: set them in the runner's environment. Cloud checks don't run steps that need secrets.
• Run logs are kept with the run, without email addresses, tokens or other secrets.