Play deployment

Deployment makes reviewed Play code available in a workspace. A Play revision records a version of the executable logic. The live revision is the version used by normal callers of that saved Play. Publishing code and running it are separate operations. A deployment changes which logic future callers use. A Play run executes that logic with an input. Deployment can also configure declared schedules, webhook bindings, and other supported triggers, so publishing has operational effects beyond saving a file.

​

Source, revisions, and live versions

An authored Play starts as a TypeScript file with its input, logic, description, and bindings. Source checks validate the supported authoring contract. A pilot tests the logic with representative input. Checks alone do not establish that the business result is correct. Registration creates a revision that can be inspected and run explicitly. Promotion makes a revision live. This separation lets a team review a candidate before changing the version its regular callers use. Provider connections and active declared secrets belong in the destination workspace. Deployment does not copy local credentials into Deepline. Workspaces and Secrets explain these boundaries.

​

Deployment methods

All methods need the intended workspace and required dependencies. Ordinary workspace members can author and publish Plays. Connecting the GitHub App and managing repository links requires owner or admin access, plus permission to install the App in GitHub.

​

Manual publication

Manual publication uses deepline plays publish for one source file. The CLI checks and registers the source, then publishes its live revision. This is useful when an agent creates a Play interactively and you review a small pilot before release. The CLI also supports directory deployment through deepline plays deploy. It builds the selected local files and records a deployment receipt. A directory deployment uses the files on disk. Repository and commit flags record provenance, rather than fetching that source. Build a Play covers checks, pilots, and publication. Deploy with GitHub Actions covers directory selection and deployment receipts.

​

GitHub App

Git deploys links a GitHub.com repository to a workspace, production branch, root directory, and manifest. It is a beta feature that requires workspace enablement. Linking a repository does not immediately deploy its existing commits. A ready pull request from the linked repository validates changed Plays and registers draft revisions. It leaves live versions unchanged. Draft and fork pull requests do not build. Production-branch pushes validate and promote changed Plays. Unchanged content is skipped. Anyone who can push to that production branch can change the workspace’s deployed logic. The App uses its installation authorization. You do not add a Deepline API key or Actions workflow to GitHub for this method. Managed build compute is metered. The App can also deploy selected Monitor files. Pull requests validate those definitions. Production deployment applies them through Monitor Jobs. Monitor provider effects are separate from Play promotion and are not rolled back by a later deployment failure. Stopped Monitors remain stopped, and removing a file does not delete an existing Monitor. Deploy from GitHub explains setup, file discovery, permissions, deployment outcomes, and repository controls.

​

GitHub Actions

Actions checks out source and runs the CLI on your runner. A typical workflow checks pull requests in a non-production workspace, then deploys the reviewed directory to a protected production environment after merge. Your workflow owns the source commit, CLI version, workspace keys, and release approval. Directory deployment has no branch-head guard: the caller decides which checkout to deploy. It validates and registers changed Plays before promoting their live versions together. Directory deployment cannot apply Monitor files. This method builds on your runner rather than Deepline’s managed build service. Play execution and other applicable Deepline usage remain separate. The Actions guide provides the complete workflow and credential boundaries.

​

Ownership and recovery

Use the deployment receipt to inspect the selected source, workspace, outcomes, and warnings. A successful command alone does not establish that the intended revision became live. Read the saved Play’s live version after publication. A manual or directory deployment can replace a Play owned by a linked repository. Deepline reports that difference. The next production push from the owning link replaces the manual version. Choose the deployment owner before mixing methods. Restoring a previous live revision changes the code used for future work. It does not reverse provider writes or other external effects from earlier runs. For Git deploys, revert or repair the source and inspect the new deployment. For a manual restoration, align the repository afterward so the next deployment does not replace the restored logic unexpectedly. Pausing or unlinking a repository stops new Git deployments. Existing live Plays and Monitors continue. Removing a source file also leaves its live Play available. Retire schedules, webhooks, callers, and Monitors explicitly when decommissioning a workflow.