Skip to main content
Use GitHub as the source of truth for Deepline Play code. Pull requests validate changes, and merges to main publish them to Deepline. These instructions work for a human or coding agent.

1. Add Play source to the repository

Commit each Deepline Play as a *.play.ts file. Each file must contain one default-exported definePlay. Do not put multiple deployable Plays in one file. The files can live anywhere in the repository. Keep code and non-secret configuration in GitHub. Store provider credentials in Deepline. Do not commit customer data, credentials, or live provider responses.

2. Pin the Deepline CLI

Choose a tested version:
Set DEEPLINE_CLI_VERSION as a GitHub Actions repository variable. Pinning the CLI prevents an unreviewed release from changing deployment behavior.

3. Configure Deepline credentials

Add these GitHub Actions secrets: Restrict the production environment to main. Add required reviewers if publication needs a separate approval. Each key must identify one Deepline workspace. Do not use a production key for pull-request validation or choose the target workspace from pull-request input. Configure each workspace with the provider credentials its Plays use and active Play secrets for every name those Plays declare. Use non-production credentials in the validation workspace and production credentials in the production workspace. This workflow supports pull requests whose branches live in the same repository. GitHub withholds repository secrets from forked pull requests. To validate a fork, move the reviewed commit to a maintainer-controlled branch; do not expose secrets with pull_request_target.

4. Add the workflow

Create .github/workflows/deepline.yml:
The workflow checks every tracked *.play.ts file. After a merge or manual run, it republishes every tracked Play so changes to imported helpers and configuration are included. --expected-artifact prevents publication if a file differs from the artifact that was just checked.

5. Test and operate the workflow

Open a pull request that changes a Play and confirm Validate Plays passes. Merge it, then confirm Publish Plays succeeds in GitHub Actions. Verify the live revision:
For later changes, repeat the same pull request, validation, merge, and verification flow. Test changed runtime behavior with approved synthetic input in an internal or test workspace. Do not publish production Plays from a workstation during normal development. To roll back, promote the previous known-good immutable revision:
Then revert or fix the GitHub source so the repository and live revision agree again.
Keep production credentials out of pull-request jobs. Deleting a *.play.ts file does not disable the live Play; decommission its schedules, webhooks, and callers separately.

Play SDK quickstart

Create, check, and run a custom Play.

Production integration

Integrate published Plays into a production application.