Deployments are part of the deliverable

For an agency, every new client means another deployment to build. Without a shared approach, each one starts as a copy of the last project's scripts and drifts from there. After a few years, nobody knows which client runs which version of the script.

Jaws Deploy keeps the deployment logic in step templates and projects your team can reuse, and keeps each client's machines, secrets and history separate.

How the pieces fit

Workspace Holds projects, environments, machines, variables, step templates, script modules and deployment history. Deployments in one workspace can't use another workspace's variables or secrets.
Step templates Your own templates, such as Run migration or Deploy API, with input fields and versions. The built-in templates are available in every workspace.
Projects and folders One project per deployable service, grouped in folders. Clone a project to start a new one from a working setup.
Access Give users and teams roles on a whole workspace, a single project or a single environment.

Two ways to organise clients

Step templates and script modules belong to a workspace. That decides how you share them, so choose the layout before you onboard the second client.

One workspace per client

Each client's machines, variables and history sit in their own workspace. Build your templates in one workspace, export them as JSON and import them into each client's workspace. An imported template is a copy, so import it again after you change the original. This suits clients with strict separation requirements or very different infrastructure.

One workspace with a folder per client

All clients share one workspace, with a project folder for each. Step templates and script modules are shared directly, and roles scoped to projects or environments control who can deploy where. Keep client secrets in project variables rather than workspace variables. This suits clients with similar setups.

Onboarding a new client

With your templates in place, a new client needs a workspace or folder, projects built from your templates, the agent on the client's servers, and the client's own variables. After that, the client's CI pipeline creates and deploys releases.

From signed contract to first deployment

Steps 1 to 4 are done once in the Jaws Deploy UI. Step 5 runs in the client's CI pipeline after every build.

# 1. Create a workspace for the new client
# 2. Add the projects, built from the agency's step templates
# 3. Install the agent on the client's machines and tag them
# 4. Fill in the client-specific variables

# 5. Release and deploy from the client's CI pipeline
#    JAWS_API_LOGIN / JAWS_API_PASSWORD: a service account in the client's workspace
Import-Module ./JawsDeploySdk.psm1   # github.com/JawsDeploy/powershell-sdk

$result = Invoke-ReleaseAndDeployProject `
    -projectId       "<project id>" `
    -version         "1.0.$env:BUILD_NUMBER" `
    -environmentName "Staging"

Test-JawsDeploymentResult $result

Reporting to clients

Every deployment records who started it, the release, the environment, its start and end times and the full log. When a client asks whether a fix reached Production before a deadline, the release's deployment history answers it.

For status reports, the List deployments endpoint returns the same records, scoped to a workspace, a project or a release.