Getting started with Jaws

Jaws Deploy is your go-to platform for streamlining continuous deployments, making it easy to orchestrate releases across environments without the hassle of complex setups. Whether you're handling on-prem servers or cloud targets, Jaws focuses on the essentials: reliable automation, reusable logic, and seamless CI/CD integration—all at a fraction of the cost of heavier tools.

If you're coming from a CI tool like TeamCity or Jenkins, Jaws picks up where they leave off, handling the "deploy" part with features like variable scoping and lifecycle progression. Let's get you up and running quickly.

Step 1: Create Your Account and Workspace

Head to https://app.jawsdeploy.net/signup to sign up—it's free to start with the Starter plan. Once logged in, you'll land in your default "Main" workspace. This is your isolated space for grouping projects, machines, and variables. If you need more workspaces (e.g., for different teams), create them under Settings.

This shows the main dashboard with projects listed, recent deployments, and activity trends. Use the search bar to filter projects quickly.

Step 2: Set Up Environments

Environments represent your deployment stages, like "Staging" and "Production." From the left menu, go to Environments and add them. Assign machines or cloud targets to these later for targeted deploys.

Tip: Start simple with two environments to test progression rules via lifecycles.

Step 3: Add a Machine or Cloud Target

• For on-prem or VM targets: Install the Jaws Deploy Agent (a lightweight service) on your server. Download the install script from the Machines page, run it with admin privileges, and accept the handshake in the app. Supported on Windows (as a service) and Linux (via systemd).
• For cloud: Add targets like Azure Web Apps under Cloud Targets. Link your Azure credentials via Cloud Accounts first.

Here, you'll see active machines with connection status, OS, agent version, environments, and tags. Check for updates or delete unused ones from this view.

Step 4: Create Your First Project

From the Projects page, click "Add new project." Name it (e.g., "Demo App"), add a description, and define steps—like "Run Script" for a PowerShell hello world or "Deploy Package" for uploading a .zip.

Upload a sample package to the Package Store (e.g., a demo .zip) and reference it in your step.

This displays all projects with IDs, descriptions, and quick links to steps, variables, releases, and deployments.

Step 5: Define Variables and Deploy

Add a project variable (e.g., "AppPath") scoped to environments for custom paths. Create a release (SemVer versioned), then deploy to "Staging." Monitor live logs and status on the Deployments tab.

View version info, creation time, lifecycle, and deployment history with statuses, durations, and triggers.

‍

Success! Your first deployment is live. For troubleshooting, check the logs. Next, explore integrations to automate from your CI tool.

Jaws Deploy vs. Traditional Deployment Tools

Why Modern CD Beats Legacy Approaches

In the world of software delivery, deployment tools have evolved from rudimentary scripts and manual processes to sophisticated platforms that automate and orchestrate releases. Traditional tools—like CI servers (e.g., Jenkins, TeamCity), custom Bash or PowerShell scripts, or even basic file transfer methods (FTP, SCP)—have served teams well for years. However, as applications grow in complexity with multi-environment setups, cloud integrations, and compliance needs, these legacy methods often fall short.

Jaws Deploy emerges as a modern continuous deployment (CD) solution, bridging the gap between simple CI outputs and reliable, scalable deliveries. In this guide, we'll compare Jaws Deploy to traditional tools, highlighting key differences, advantages, and when it makes sense to switch. We'll draw on real-world scenarios to show how Jaws simplifies what used to be painstaking work, all while keeping costs low and usability high.

What Are Traditional Deployment Tools?

Traditional deployment tools typically refer to:

• CI Servers as Deployment Hacks: Tools like Jenkins, GitHub Actions, or TeamCity, originally designed for building and testing, often get extended with plugins or scripts to handle deployments. For example, a Jenkins pipeline might use SSH to copy files to a server.
• Script-Based Approaches: Custom scripts in Bash, PowerShell, or Python that automate file copies, service restarts, or config updates. These are lightweight but require manual maintenance.
• Manual or Basic Utilities: Tools like FTP clients, rsync, or cloud CLIs (e.g., AWS CLI, Azure CLI) for pushing artifacts directly to targets.

These methods are free or low-cost to start but scale poorly. They lack built-in features for environment management, auditing, or rollback, leading to brittle processes prone to human error.

Key Pain Points with Traditional Tools

While traditional tools get the job done for small projects, they introduce challenges as teams grow:

• Lack of Centralized Management: Deployments are often siloed in scripts or pipeline configs, making it hard to visualize progress or history across environments. Debugging a failed deploy might involve sifting through console logs.
• Manual Environment Handling: Switching configs between dev, staging, and production requires custom logic in scripts, increasing the risk of leaks (e.g., prod secrets in staging).
• Limited Reusability: Scripts are duplicated across projects, leading to inconsistencies. Updating a common step (like installing a cert) means editing multiple files.
• Security and Compliance Gaps: Exposing credentials in scripts or pipelines is risky, and auditing who deployed what is manual.
• Scalability Issues: As targets multiply (e.g., multiple VMs, cloud apps), orchestration becomes chaotic without native support for parallelism or dependencies.
• No Built-in Monitoring: You rely on external tools for deployment trends, error tracking, or alerts.

These issues can lead to longer release cycles, higher downtime, and frustrated teams.

How Jaws Deploy Addresses These Challenges

Jaws Deploy is built for modern CD, focusing on automation, visibility, and reuse without the overhead of enterprise bloat. Unlike traditional tools, it provides a unified UI and API for managing the full deployment lifecycle. Here's a side-by-side comparison:

Aspect	Traditional Tools (e.g., Jenkins/Scripts)	Jaws Deploy
Setup and Learning Curve	Steep for custom scripting; requires DevOps expertise to configure pipelines or agents.	Quick start with a web-based UI. Install the lightweight Jaws Agent on targets in minutes. Guides like our Getting Started walk you through your first deploy.
Environment Management	Manual via if-else in scripts or env vars in CI. No progression rules.	Built-in environments (e.g., Staging, Production) with lifecycles for automated promotion. Scope variables and steps to prevent config leaks.
Reusability	Copy-paste scripts; version control helps but lacks templates.	Step templates and script modules for reusable logic (e.g., PowerShell-based cert installation). Share across projects via workspace variables. See our guide on Code Reuse with Script Modules.
Visibility and Auditing	Limited to log files or CI dashboards; no unified history.	Real-time dashboards with deployment history, durations, errors, and trends. Filter by project or environment.
Security	Credentials often hardcoded or in env vars; easy to expose.	Secure variables (secrets) with scoping; service accounts for API access. Integrates with Azure Key Vault for external storage.
Integrations	Plugin-heavy (e.g., Jenkins plugins); custom webhooks.	Seamless with CI tools like TeamCity (native integration), GitHub Actions, or Jenkins via REST API. Automate releases post-build. Check our CI/CD Integration Guide.
Scalability	Handles basics but chokes on complex topologies without add-ons.	Tags for targeting groups of machines/cloud apps; parallel deploys out-of-the-box. Supports Windows/Linux agents and Azure Web Apps.
Cost	Free tools but high maintenance time; paid plugins add up.	Transparent pricing starting free; no per-user fees. Far more affordable than over-engineered alternatives.
API and Automation	Varies; scripts are automatable but fragmented.	Full REST API for everything — create releases, trigger deploys, query status. No CLI yet, but PowerShell SDK fills the gap.

Jaws shines in scenarios where traditional tools falter, like deploying a .NET app to Azure Web Apps. Instead of scripting Azure CLI commands, define a project step, upload a package to the store, and deploy with one click or API call. Manage versions securely without external feeds if needed.

‍

Real-World Examples: Jaws in Action

• From Jenkins to Jaws: A team using Jenkins for builds but manual SSH for deploys switched to Jaws. They integrated via API, using lifecycles to auto-promote from Staging to Production after approvals. Result: 50% faster releases, with full audit trails.
• Script Overhaul: A solo dev with PowerShell scripts for VM updates adopted Jaws' script modules. Reusable "Run Script" steps eliminated duplication, and variable expressions handled env-specific paths dynamically.
• Cloud Migration: Teams on Azure CLI scripts benefited from Jaws' native Azure integrations, scoping secrets to cloud targets for secure, repeatable deploys.

These examples highlight Jaws' focus on developer-friendly features, like expression-based variables (#{VAR.myVar}) and agent auto-updates, which reduce toil compared to maintaining traditional setups.

When to Choose Jaws Deploy Over Traditional Tools

Stick with traditional tools for ultra-simple, one-off deploys or if you're already deeply invested in a CI ecosystem without CD needs. But if you're dealing with:

• Multiple environments or targets.
• Need for auditing and visualization.
• Desire to reuse logic without code duplication.
• Integration with modern CI/CD pipelines.

Jaws Deploy is a no-brainer upgrade. It's especially appealing for small-to-medium teams seeking Octopus-like power without the price tag—our migration guide from tools like Octopus shows how seamless the switch can be.

Conclusion

Traditional deployment tools laid the foundation for automation, but in 2025, with hybrid clouds and rapid iterations, you need more. Jaws Deploy modernizes CD by combining intuitive UI, robust APIs, and cost-efficiency, letting you focus on shipping features, not fighting tools.

Ready to try? Sign up at jawsdeploy.net and deploy your first project today. For questions, hit our Contact Us page or dive into guides for hands-on tips. If you're migrating, check How Jaws Compares to Octopus Deploy for tailored advice.

‍

What is Jaws Deploy?

A Modern Platform for Streamlined Continuous Deployments

In today's fast-paced software world, getting your code from development to production reliably and quickly is crucial. That's where Jaws Deploy comes in—a powerful, user-friendly continuous deployment (CD) platform designed for agile DevOps teams. Whether you're managing on-prem servers, cloud services, or hybrid setups, Jaws Deploy simplifies the complexities of deployment automation, letting you focus on building great software rather than wrestling with pipelines.

Founded in 2023 by a team of experienced software and DevOps engineers, Jaws Deploy was created as an accessible alternative to tools like Octopus Deploy. As long-time users of Octopus, the founders appreciated its capabilities but found its pricing and complexity challenging. Jaws Deploy aims to deliver similar power with greater simplicity, affordability, and focus on real-world needs—handling about 80% of common deployment scenarios without unnecessary bloat.

In this article, we'll break down what Jaws Deploy is, its key features, how it works, and why it might be the right fit for your team. Let's dive in.

The Core Purpose of Jaws Deploy

At its heart, Jaws Deploy is an automated deployment platform that orchestrates releases across multiple environments. It wraps up the intricacies of continuous delivery (CD), providing a clear path from your CI tools (like TeamCity or Jenkins) to live production systems. As described on the Jaws homepage: "Use Jaws Deploy to orchestrate multi-environment deployments with configuration management, reusable workflows and seamless integration into your CI/CD pipelines."

It's built for teams of all sizes— from solo developers to enterprise groups—handling everything from simple web apps to complex microservices. By modeling your infrastructure, defining reusable steps, and integrating with your existing toolchain, Jaws ensures deployments are consistent, auditable, and scalable.

Key benefits include:

• Speed and Efficiency: Automate repetitive tasks to reduce manual errors and accelerate releases.
• Visibility: Real-time insights into deployment progress, history, and trends.
• Security and Control: Scoped variables and role-based access to protect sensitive data.
• Cost-Effectiveness: Transparent pricing starting at free, without per-user fees or hidden costs.

Key Features of Jaws Deploy

Jaws Deploy packs a robust set of features tailored for modern CD workflows. Here's a breakdown of the standout ones, categorized for clarity:

Deployment Automation

• Step-Based Pipelines: Build deployment flows using ordered steps in projects. Use built-in templates for tasks like "Deploy Package" or "Run Script," or create custom PowerShell-based steps. Steps can be scoped to specific environments or targets for precision.
• Lifecycles and Channels: Define progression rules with lifecycles (e.g., auto-promote from Staging to Production after approvals). Channels allow variant flows, like hotfixes bypassing full testing.
• Live Previews and Logs: Monitor deployments in real-time via the UI or API, with structured logs grouped by steps and targets. Adjust parallelism to speed things up.
• History and Insights: Every release snapshots the state for easy review. Track durations, errors, and trends over time.

This view shows version info, creation times, statuses, and running durations, helping you diagnose issues quickly.

‍

Infrastructure Management

• Environments and Topology: Model your setup with environments (e.g., Dev, Staging, Prod) that group machines or cloud targets. Machines run the lightweight Jaws Agent (Windows/Linux compatible), while cloud targets like Azure Web Apps are managed natively.
• Tagging System: Apply custom tags to organize targets by role, region, or specs—perfect for targeted deploys without overcomplicating logic.
• Cross-Platform Support: Built on .NET 8 and PowerShell 7, with future expansions to bash and Python scripting planned for 2025.

See active machines with connection status, OS details, agent versions, assigned environments, and tags for easy management.

Configuration and Reusability

• Variables: Multi-valued and scoped (by environment, machine, or tag) for dynamic customization. Reference other variables with expressions like #{VAR.myVar}, and use them for config transforms (JSON/XML), step properties, or script logic.
• Script Modules: Reusable PowerShell modules (.psm1) with utility functions, shareable across projects to avoid duplication.
• Step Templates: Pre-built or custom templates with JSON-defined UIs for inputs, enabling reusable patterns like installing services or applying SSL certs.

Manage text, secret, or structured variables with scoping options, values, and history tracking.

Packages and Integrations

• Package Stores and Feeds: Built-in feeds per workspace for .zip, .tar.gz, or NuGet packages. Upload manually via UI/API or connect external feeds from CI tools.
• CI/CD Connections: Integrate seamlessly with GitHub Actions, GitLab, Jenkins, TeamCity, and more using REST API or the PowerShell SDK. Automate release creation post-build.

View package IDs, versions, sizes, and upload dates, with options to add new versions or inspect details.

API and Administration

• REST API: Automate everything from release creation to deployment triggers. Authenticate with service accounts and API keys—no CLI yet, but the PowerShell SDK wraps key endpoints.
• RBAC (Roles and Permissions): Built-in roles like Workspace Admin or Project Deployer control access, scoped to workspaces or projects.
• Self-Hosting Option: Use the Jaws Deploy Stack for on-prem installs, with guides for proxy setup and OIDC integration.

How Jaws Deploy Works: A Simple Workflow

1. Setup: Create an organization and workspace. Add environments, machines (install agents), or cloud targets.
2. Define Projects: Build steps, variables, and lifecycles in a project.
3. Create Releases: Version your project state (SemVer 2.0) and associate with a channel.
4. Deploy: Push to environments, monitor live, and review history.

List all projects with IDs, descriptions, and links to steps, variables, releases, and deployments.

Jaws Deploy vs. Competitors Like Octopus Deploy

Jaws Deploy shares many similarities with Octopus Deploy, such as workspaces, projects, environments, variables, lifecycles, and step templates. Both handle multi-environment deploys, tagging, and config transforms effectively.

However, Jaws stands out with:

• Simpler Onboarding: Easier configuration and a more intuitive UI for faster adoption.
• Lower Costs: Starter plan is free forever; Professional at $90/mo + add-ons like $4/machine—far more affordable than Octopus's model based on targets, storage, and parallels.
• Focused Scope: Prioritizes essential features without extras like Runbooks (coming to Jaws in 2025), making it lighter for most teams.

If you're migrating from Octopus or traditional tools, Jaws offers guides to ease the transition, emphasizing its clarity and control.

Pricing and Getting Started

Jaws Deploy keeps things straightforward:

• Starter: Free forever—1 workspace, 1 user, limited targets/projects/storage.
• Professional: $90/mo base + scalable add-ons; 30-day trial.
• Custom: On-prem or tailored plans—contact for quotes.

No credit card needed to start. Sign up at https://app.jawsdeploy.net/signup, and check the Getting Started guide for your first deploy.

Why Choose Jaws Deploy?

If you're tired of brittle scripts, siloed CI tools, or overpriced platforms, Jaws Deploy offers a balanced, modern alternative. It's built by DevOps pros for real teams, with ongoing improvements based on user feedback. Whether deploying .NET apps to Azure or custom services to VMs, Jaws makes CD approachable and efficient.

Have questions? Visit Contact Us or explore features and guides for more. Ready to simplify your deployments? Give Jaws a try today!

The Role of Jaws Deploy in CI/CD Workflows

Continuous Integration and Continuous Deployment (CI/CD) have become the backbone of modern software development, enabling teams to build, test, and release code faster and more reliably. While CI focuses on automating builds and tests (often handled by tools like Jenkins, GitHub Actions, or TeamCity), CD takes over to orchestrate deployments to various environments. This is where Jaws Deploy shines—as a dedicated CD platform that bridges the gap between your CI outputs and production reality.

Jaws Deploy acts as the deployment orchestrator in your CI/CD pipeline, handling complex topologies, configuration management, and automated releases with ease. It's designed to integrate seamlessly with existing CI tools, providing a centralized hub for deployment logic that's reusable, auditable, and scalable. Whether you're deploying to on-prem machines, Azure Web Apps, or hybrid setups, Jaws ensures consistency without forcing you to reinvent the wheel in scripts or pipelines.

In this guide, we'll explore Jaws Deploy's role in CI/CD workflows, how it integrates, typical setups, and the value it adds to your DevOps processes.

Understanding CI/CD and Where Jaws Fits

A standard CI/CD workflow looks like this:

1. Code Commit: Developers push changes to a repo (e.g., GitHub).
2. CI Phase: A CI tool builds the code, runs tests, and produces artifacts (e.g., packages like .zip or NuGet).
3. CD Phase: Artifacts are deployed to environments like Staging or Production, with config transforms, scripting, and monitoring.

Traditional setups often overload CI tools with deployment duties, leading to brittle scripts and limited visibility. Jaws Deploy specializes in the CD part, taking artifacts from CI and managing their rollout. It models your infrastructure (environments, machines, tags) and automates progression via lifecycles, making it ideal for multi-stage pipelines.

Unlike all-in-one tools, Jaws focuses on simplicity: Use your favorite CI for builds, then hand off to Jaws for deployments. This separation keeps pipelines lean and leverages Jaws' strengths in variable scoping, step reusability, and live previews.

How Jaws Deploy Integrates with CI Tools

Jaws Deploy integrates via its REST API and PowerShell SDK, allowing automation from any CI platform. No native plugins needed— just API calls or scripts post-build.

Supported Integration Methods

• REST API: Call endpoints directly to create releases, trigger deployments, or query status. Authenticate with service accounts (API keys) for secure, headless access.
• PowerShell SDK: A lightweight wrapper (zero dependencies) over the REST API, available on GitHub. Import it in your CI scripts for commands like Invoke-ReleaseAndDeployProject.

Compatible CI Tools

While Jaws works with any tool supporting HTTP calls or PowerShell, common integrations include:

• TeamCity: Native guide for pushing packages and triggering deploys.
• Jenkins, GitHub Actions, GitLab CI: Use webhooks or script steps to call the API/SDK.
• Azure DevOps: Connect NuGet feeds for automatic package detection.

Setup is straightforward: Create a service account in Jaws, store credentials securely (e.g., as CI secrets), and invoke from your pipeline.

Store API keys as secrets here, scoped to your CI environment for added security.

A Typical CI/CD Workflow with Jaws Deploy

Here's how Jaws fits into a end-to-end workflow:

1. Build in CI: Your CI tool compiles code and uploads artifacts to Jaws' package store (via API) or an external NuGet feed.
2. Create Release in Jaws: Post-build, call the API/SDK to version a release (SemVer) and associate packages.
3. Deploy Automatically: Use lifecycles to auto-deploy to initial environments (e.g., Staging). Promote manually or via approvals to Production.
4. Monitor and Feedback: Jaws provides live logs and history; integrate back to CI for notifications.

Example with PowerShell SDK in a CI script:

# Set credentials
$env:JAWS_API_LOGIN = "your_service_account_id"
$env:JAWS_API_PASSWORD = "your_api_key"

# Import SDK
Import-Module -Name JawsDeploySdk.psm1

# Trigger release and deploy
$response = Invoke-ReleaseAndDeployProject -projectId "abc123" -version "1.2.3" -environmentName "Staging"
Write-Output $response

This deploys to Staging instantly after CI success.

For advanced setups, use variables for dynamic configs (e.g., #{VAR.connectionString}) and tags to target specific machine groups.

Track the workflow here, with statuses, triggers, and durations from CI-initiated deploys.

Benefits of Using Jaws in Your CI/CD Pipeline

Incorporating Jaws Deploy elevates your workflows:

• Reusability and Consistency: Step templates and script modules (PowerShell, with bash/Python support rolling out in 2025) reduce duplication across projects.
• Enhanced Visibility: Dashboards show trends, errors, and activity—far beyond CI logs.
• Security: Scoped secrets and RBAC prevent leaks; integrate with Azure Key Vault.
• Scalability: Handle complex topologies without pipeline bloat; parallel deploys speed things up.
• Cost Savings: Affordable plans mean no overpaying for unused features, unlike bulkier tools.

Teams report faster releases and fewer incidents by offloading CD to Jaws.

Real-World Examples

• Web App Deployment: After GitHub Actions builds a .NET app, Jaws deploys to Azure Web Apps using a "Deploy Package" step, transforming configs via variables.
• Microservices Rollout: TeamCity builds containers; Jaws orchestrates tagged deploys to Kubernetes nodes (via custom scripts), with lifecycle phases for canary testing.
• Legacy System Updates: Jenkins handles builds for on-prem Windows services; Jaws uses machine agents for installs, with history for compliance audits.

See how CI-triggered deploys appear in activity graphs for quick insights.

Looking Ahead: Jaws in Evolving CI/CD

With 2025 updates like expanded scripting (bash/Python) and a Step Template Library for AWS/Docker, Jaws is poised to handle even more diverse workflows. Future enhancements will deepen integrations, making Jaws an even stronger CD partner.

Conclusion

Jaws Deploy plays a pivotal role in CI/CD by owning the deployment orchestration, freeing your CI tools to do what they do best. Its API-driven approach, reusable components, and intuitive UI make it a natural fit for teams seeking reliable, low-maintenance CD.

To integrate Jaws into your pipeline, start with the CI/CD Integration Guide or try a free account at jawsdeploy.net. If you're migrating, check our comparison to Octopus Deploy for tips. Simplify your deployments—get started today!

Integrating GitHub Actions

GitHub Actions is a popular CI/CD platform built right into GitHub, allowing you to automate workflows for building, testing, and deploying code. While it's great for the "CI" part—handling builds and tests—it can get cumbersome for complex deployments involving multiple environments, configurations, and targets. That's where Jaws Deploy comes in: it takes over the "CD" orchestration, providing reusable steps, variable scoping, and live monitoring.

By integrating Jaws Deploy with GitHub Actions, you can automate release creation and deployments post-build, ensuring consistent rollouts to staging, production, or custom environments. This guide walks you through the process using Jaws' REST API or the lightweight PowerShell SDK. No native GitHub Action exists yet, but the API-driven approach is flexible and easy to set up.

We'll cover prerequisites, setup steps, an example workflow, and tips for success. Let's get your pipeline flowing smoothly.

Why Integrate Jaws Deploy with GitHub Actions?

• Seamless Handover: GitHub Actions handles builds; Jaws manages deployments with features like lifecycles for progression and tags for targeting.
• Automation Without Scripts: Avoid custom deployment scripts in your Actions workflow—let Jaws handle the logic via API calls.
• Security and Reusability: Use service accounts for auth, and scope variables in Jaws for env-specific configs.
• Visibility: Post-deployment, check status in Jaws' dashboard for logs, history, and trends.

This integration is ideal for .NET, web apps, or any project where you build artifacts (e.g., .zip packages) in Actions and deploy them via Jaws.

Prerequisites

Before starting:

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup if needed).
• A GitHub repository with Actions enabled.
• A Jaws project set up with steps, environments (e.g., Staging, Production), and optionally a package store for artifacts.
• Familiarity with YAML for GitHub workflows.
• GitHub Secrets for storing sensitive info (we'll use these for Jaws credentials).

Ensure your Jaws project is ready here, with defined steps and variables.

Step 1: Create a Service Account in Jaws Deploy

Service accounts provide secure, API-only access without tying to a user login. They're perfect for CI/CD automation.

1. In Jaws Deploy, go to Settings > Service Accounts (or via Admin if self-hosted).
2. Click "Add Service Account."
3. Name it (e.g., "GitHubActionsDeployer") and assign permissions (e.g., read/write on specific projects/workspaces).
4. Generate and copy the API key—treat it like a password.

Store the service account ID and API key as GitHub Secrets:

• JAWS_API_LOGIN = service account ID
• JAWS_API_PASSWORD = API key

This keeps credentials secure and out of your workflow YAML.

For more on service accounts, see our Service Accounts and Automation Guide.

Step 2: Choose Your Integration Method

Jaws supports two main ways to integrate:

• REST API: Direct HTTP calls using curl or similar in your Actions workflow. Great for non-PowerShell environments.
• PowerShell SDK: A zero-dependency wrapper (available on GitHub at https://github.com/JawsDeploy/powershell-sdk). Ideal if your workflow can run PowerShell.

We'll use the PowerShell SDK in our example for simplicity, but REST alternatives are noted.

Step 3: Set Up Your GitHub Actions Workflow

Create a .github/workflows/deploy.yml file in your repo. This example assumes a .NET app build that produces a .zip package.

Basic Workflow Structure

name: Build and Deploy to Jaws

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - name: Build
        run: dotnet build --configuration Release
      - name: Package
        run: dotnet publish -c Release -o out
      - name: Zip Artifact
        run: zip -r app.zip out/
      - name: Upload to Jaws Package Store
        run: |
          curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
            -H "Authorization: Basic $(echo -n ${{ secrets.JAWS_API_LOGIN }}:${{ secrets.JAWS_API_PASSWORD }} | base64)" \\
            -F "file=@app.zip" \\
            -F "packageId=my-app" \\
            -F "version=${{ github.run_number }}.0.0"  # Use run number or git tag for versioning

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via PowerShell SDK
        uses: actions/setup-powershell@v1  # If needed for PowerShell support
        with:
          shell: pwsh
      - name: Download and Import SDK
        run: |
          Invoke-WebRequest -Uri "<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>" -OutFile "JawsDeploySdk.psm1"
          Import-Module ./JawsDeploySdk.psm1
      - name: Create Release and Deploy
        env:
          JAWS_API_LOGIN: ${{ secrets.JAWS_API_LOGIN }}
          JAWS_API_PASSWORD: ${{ secrets.JAWS_API_PASSWORD }}
        run: |
          $projectId = "your-project-id"  # From Jaws Projects page
          $version = "${{ github.run_number }}.0.0"
          $resp = Invoke-ReleaseAndDeployProject -projectId $projectId -version $version -environmentName "Staging"
          Write-Output $resp

Key Explanations

• Build Job: Builds your app, creates a package, and uploads it to Jaws' package store via REST API (adapt the endpoint from /api-reference).
• Deploy Job: Downloads the SDK, sets env vars from secrets, and calls Invoke-ReleaseAndDeployProject to create a release and deploy to Staging.
• Versioning: Use SemVer like ${{ github.run_number }}.0.0 or git tags for traceability.

For pure REST (no SDK):Replace the deploy step with curl calls:

• POST to /api/release to create a release.
• POST to /api/release/deploy to trigger deployment.

Example curl for release creation:

curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
  -H "Authorization: Basic $(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)" \\
  -H "Content-Type: application/json" \\
  -d '{"projectId": "your-project-id", "version": "1.2.3", "packageVersions": {"my-app": "1.2.3"}}'

Step 4: Test and Monitor

1. Push to your branch to trigger the workflow.
2. Check GitHub Actions logs for output.
3. In Jaws Deploy, go to the project's Deployments tab to view live progress, logs, and status.

Monitor the GitHub-triggered deploy here, with creation time, status, and errors.

If issues arise, enable debug mode in Jaws by setting a __debug variable to true in your project.

Best Practices

• Secure Secrets: Always use GitHub Secrets for credentials—never commit them.
• Conditional Deploys: Add if conditions in steps, e.g., deploy to Production only on tags (if: startsWith(github.ref, 'refs/tags/')).
• Package Management: Upload artifacts to Jaws' store for versioned deploys; reference them in steps.
• Error Handling: In your workflow, check API responses and notify via Slack/email on failure.
• Scalability: For multiple projects, parameterize the workflow with inputs.
• Updates: Keep the SDK up-to-date; pin to a release if needed.

For advanced scripting (now including bash/Python support as of 2025), extend with custom steps.

Troubleshooting Common Issues

• Auth Errors: Double-check service account permissions and base64 encoding in headers.
• Package Not Found: Ensure upload succeeds and versions match in release creation.
• Timeout: Increase parallelism in Jaws steps or optimize your build.
• Logs: Use Jaws' dashboard for detailed step outputs.

If stuck, visit our API Reference or Contact Us.

Conclusion

Integrating Jaws Deploy with GitHub Actions supercharges your CD process, combining Actions' flexibility with Jaws' deployment smarts. This setup reduces manual work, boosts reliability, and scales with your team.

For more integrations, see our CI/CD Integration Guide. Ready to automate? Update your workflow and deploy with confidence! If you're new, start with Getting Started.

‍

Integrating Jenkins

Jenkins is a widely used open-source automation server for continuous integration (CI), excelling at building, testing, and packaging code. However, when it comes to orchestrating complex deployments across multiple environments, configurations, and targets, it can become unwieldy with custom scripts and plugins. Jaws Deploy complements Jenkins by handling the continuous deployment (CD) side, managing releases, lifecycles, variables, and monitoring in a dedicated platform.

In this integration, Jenkins focuses on the build process (e.g., compiling code and creating artifacts like .zip packages), while Jaws Deploy takes over for release creation and deployment. We'll use Jaws' REST API or the PowerShell SDK for seamless handover. No dedicated Jenkins plugin is required—leverage built-in shell or PowerShell steps in your pipelines.

This guide covers prerequisites, setup, an example Jenkins pipeline, and best practices to automate your workflow.

Why Integrate Jenkins with Jaws Deploy?

• Clear Separation of Concerns: Jenkins handles CI efficiently; Jaws specializes in CD with features like environment scoping, tags, and reusable steps.
• Automation and Reliability: Trigger Jaws releases automatically post-build, reducing manual intervention and errors.
• Enhanced Features: Gain Jaws' dashboard for deployment visibility, history, and trends—beyond Jenkins' console logs.
• Flexibility: Works with freestyle jobs or declarative pipelines; supports Windows/Linux agents.

This setup is perfect for .NET apps, web services, or any project where Jenkins builds artifacts and Jaws deploys them to machines or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• Jenkins installed with the PowerShell Plugin (for SDK usage) or basic shell support.
• A Jenkins pipeline project (declarative or scripted).
• A Jaws project configured with steps, environments (e.g., Staging, Production), and a package store if needed.
• Familiarity with Jenkinsfile (Groovy-based) for pipelines.

Verify your Jaws project setup here, including steps and variables.

Step 1: Create a Service Account in Jaws Deploy

For secure API access from Jenkins:

1. In Jaws, navigate to Settings > Service Accounts.
2. Add a new account (e.g., "JenkinsDeployer") with appropriate permissions (e.g., release creation and deployment on specific projects).
3. Copy the service account ID and API key.

Store these in Jenkins as credentials:

• Go to Jenkins > Manage Jenkins > Credentials > System > Global credentials.
• Add a "Username with password" credential: Username = service account ID, Password = API key.
• ID it as "jaws-api-creds" for reference in pipelines.

See the Service Accounts and Automation Guide for details.

Step 2: Choose Your Integration Method

• REST API: Use curl in shell steps for direct HTTP calls. Simple for Linux agents.
• PowerShell SDK: Run PowerShell scripts in Jenkins to import the SDK and invoke commands like Invoke-ReleaseAndDeployProject. Ideal for Windows agents or cross-platform with PowerShell Core.

We'll demonstrate both in the example, focusing on the SDK for its simplicity.

Step 3: Set Up Your Jenkins Pipeline

Create a new Pipeline project in Jenkins and define a Jenkinsfile in your repo (or inline). This example assumes a .NET build producing a .zip artifact.

Example Jenkinsfile (Declarative Pipeline)

pipeline {
    agent any
    environment {
        JAWS_CREDS = credentials('jaws-api-creds')  // References your stored creds
    }
    stages {
        stage('Build') {
            steps {
                // Build your app (e.g., .NET example)
                sh 'dotnet build --configuration Release'
                sh 'dotnet publish -c Release -o out'
                sh 'zip -r app.zip out/'

                // Upload package to Jaws via REST API (using curl)
                sh """
                curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
                  -H "Authorization: Basic \\$(echo -n \\$JAWS_CREDS_USR:\\$JAWS_CREDS_PSW | base64)" \\
                  -F "file=@app.zip" \\
                  -F "packageId=my-app" \\
                  -F "version=${BUILD_NUMBER}.0.0"  // Use Jenkins build number for versioning
                """
            }
        }
        stage('Deploy via Jaws SDK') {
            steps {
                // Use PowerShell step (requires PowerShell Plugin)
                powershell '''
                # Download and import SDK (one-time or cache it)
                Invoke-WebRequest -Uri "<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>" -OutFile "JawsDeploySdk.psm1"
                Import-Module ./JawsDeploySdk.psm1

                # Set credentials from env (passed via Jenkins creds)
                $env:JAWS_API_LOGIN = $env:JAWS_CREDS_USR
                $env:JAWS_API_PASSWORD = $env:JAWS_CREDS_PSW

                # Create release and deploy
                $projectId = "your-project-id"  # From Jaws Projects page
                $version = "${env:BUILD_NUMBER}.0.0"
                $response = Invoke-ReleaseAndDeployProject -projectId $projectId -version $version -environmentName "Staging"
                Write-Output $response
                '''
            }
        }
    }
    post {
        always {
            cleanWs()  // Clean up workspace
        }
    }
}

Key Explanations

• Build Stage: Compiles, publishes, and zips the artifact. Uploads to Jaws' package store using curl with Basic Auth from credentials.
• Deploy Stage: Uses powershell step to run a script that imports the SDK, sets creds, and calls Invoke-ReleaseAndDeployProject for release creation and deployment to Staging.
• Credentials: Securely injected via credentials() binding—avoids hardcoding.
• Versioning: Leverages Jenkins' BUILD_NUMBER for SemVer traceability.

For pure REST (no SDK), replace the PowerShell step with a sh or bat step using curl:

sh """
curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
  -H "Authorization: Basic \\$(echo -n \\$JAWS_CREDS_USR:\\$JAWS_CREDS_PSW | base64)" \\
  -H "Content-Type: application/json" \\
  -d '{"projectId": "your-project-id", "version": "${BUILD_NUMBER}.0.0", "packageVersions": {"my-app": "${BUILD_NUMBER}.0.0"}}'
"""
// Follow with another curl for /api/release/deploy

Adapt endpoints from the API Reference.

Step 4: Test and Monitor

1. Commit your Jenkinsfile and trigger a build.
2. Watch Jenkins console for output.
3. In Jaws, check the project's Deployments tab for progress, logs, and status.

View Jenkins-triggered deploys here, including triggers and durations.

Enable Jaws debug mode with a __debug variable if needed.

Best Practices

• Credential Security: Use Jenkins' Credential Provider; never expose keys in scripts.
• Conditional Logic: Add gates, e.g., deploy to Production only on main branch or with approvals (use Jenkins input steps).
• Artifact Management: Archive builds in Jenkins and reference in Jaws for rollbacks.
• Error Handling: In PowerShell, use try-catch; in Groovy, wrap steps with catchError.
• Agent Specificity: Use labels (e.g., agent { label 'windows' }) for PowerShell on Windows nodes.
• Updates: Pin SDK versions or cache downloads to avoid network issues.

For multi-project setups, parameterize the pipeline.

Troubleshooting Common Issues

• Auth Failures: Verify service account scopes and Base64 encoding in headers.
• Package Upload Errors: Check file paths and versions match.
• PowerShell Not Found: Ensure the PowerShell Plugin is installed; use pwsh on Linux agents.
• Pipeline Hangs: Add exit codes in scripts (e.g., exit 1 on failure) to propagate errors.
• Logs: Use Jaws' UI for detailed outputs; enable verbose in SDK calls.

Refer to Jenkins docs or API Reference for more.

Conclusion

Integrating Jenkins with Jaws Deploy streamlines your CI/CD pipeline, letting each tool play to its strengths. This API-driven approach minimizes custom code while maximizing automation and visibility.

For broader CI/CD tips, see the CI/CD Integration Guide. Start building—configure your pipeline today! If new to Jaws, try the Getting Started guide.

‍

Integrating GitLab

GitLab CI/CD is a robust, built-in pipeline tool for continuous integration and delivery, integrated directly with your GitLab repositories. It excels at automating builds, tests, and artifact creation but can become complex when managing multi-environment deployments, configurations, and orchestrations. Jaws Deploy steps in as the dedicated CD platform, handling releases, lifecycles, variable scoping, and monitoring to ensure reliable rollouts.

In this integration, GitLab focuses on the CI phase (building and packaging), while Jaws Deploy manages the CD phase (release creation and deployment). Leverage Jaws' REST API or PowerShell SDK for automation—no native GitLab plugin is needed; use script stages in your pipelines.

This guide outlines prerequisites, setup, an example GitLab CI/CD pipeline, and tips for a smooth workflow.

Why Integrate GitLab with Jaws Deploy?

• Efficient Division of Labor: GitLab handles builds efficiently; Jaws takes care of deployments with advanced features like tags for targeting and lifecycles for progression.
• Automated Handover: Trigger Jaws releases automatically after successful builds, streamlining the pipeline.
• Improved Visibility and Control: Access Jaws' dashboards for deployment logs, history, and trends, complementing GitLab's job outputs.
• Security Focus: Use service accounts for API access, keeping credentials secure in GitLab variables.

This setup suits projects like web apps or microservices where GitLab builds artifacts (e.g., .zip or Docker images) and Jaws deploys them to on-prem machines or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A GitLab repository with CI/CD enabled (requires a GitLab Runner).
• A Jaws project set up with steps, environments (e.g., Staging, Production), and optionally a package store.
• GitLab Variables for storing secrets (we'll use these for Jaws credentials).
• A Runner with shell access; for PowerShell SDK, ensure PowerShell Core is installed (common on Linux/Windows Runners).

Confirm your Jaws project is configured here, with steps, variables, and environments.

‍

Step 1: Create a Service Account in Jaws Deploy

For secure, automated access:

1. In Jaws, go to Settings > Service Accounts.
2. Create a new account (e.g., "GitLabDeployer") with permissions for release creation and deployment on relevant projects/workspaces.
3. Note the service account ID and API key.

In GitLab:

• Navigate to your project > Settings > CI/CD > Variables.
• Add two masked, protected variables:
  • JAWS_API_LOGIN = service account ID
  • JAWS_API_PASSWORD = API key

This ensures credentials are secure and only available in protected branches/pipelines.

Refer to the Service Accounts and Automation Guide for more.

‍

Step 2: Choose Your Integration Method

• REST API: Make HTTP calls with curl in script stages. Straightforward for any Runner.
• PowerShell SDK: Execute PowerShell scripts to import the SDK and use commands like Invoke-ReleaseAndDeployProject. Requires PowerShell on the Runner (install via apt install powershell on Ubuntu-based images if needed).

We'll use the SDK in the example, with REST alternatives provided.

Step 3: Set Up Your GitLab CI/CD Pipeline

Create a .gitlab-ci.yml file in your repo root. This example builds a .NET app, packages it, uploads to Jaws, and deploys.

Example .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/sdk:8.0  # Or your preferred image with dotnet and curl

variables:
  PACKAGE_ID: "my-app"
  PROJECT_ID: "your-project-id"  # From Jaws Projects page

stages:
  - build
  - deploy

build:
  stage: build
  script:
    - dotnet build --configuration Release
    - dotnet publish -c Release -o out
    - zip -r app.zip out/
    # Upload package to Jaws via REST API
    - |
      curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
        -H "Authorization: Basic $(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)" \\
        -F "file=@app.zip" \\
        -F "packageId=$PACKAGE_ID" \\
        -F "version=$CI_PIPELINE_ID.0.0"  # Use pipeline ID or git tag for versioning
  artifacts:
    paths:
      - app.zip  # Optional, for archiving

deploy_to_staging:
  stage: deploy
  script:
    # Download and import PowerShell SDK
    - pwsh -Command "Invoke-WebRequest -Uri '<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>' -OutFile 'JawsDeploySdk.psm1'"
    - pwsh -Command "Import-Module ./JawsDeploySdk.psm1"
    # Create release and deploy
    - |
      pwsh -Command "
      \\$env:JAWS_API_LOGIN = '$JAWS_API_LOGIN'
      \\$env:JAWS_API_PASSWORD = '$JAWS_API_PASSWORD'
      \\$version = '$CI_PIPELINE_ID.0.0'
      \\$response = Invoke-ReleaseAndDeployProject -projectId '$PROJECT_ID' -version \\$version -environmentName 'Staging'
      Write-Output \\$response
      "
  when: on_success  # Run only if build succeeds
  environment: Staging  # GitLab environment tracking

Key Explanations

• Build Stage: Compiles, publishes, zips the artifact, and uploads to Jaws' package store using curl with Basic Auth from variables.
• Deploy Stage: Uses pwsh (PowerShell Core) to download/import the SDK, set creds, and invoke Invoke-ReleaseAndDeployProject for release and deployment to Staging.
• Versioning: Employs GitLab's $CI_PIPELINE_ID for SemVer consistency.
• Image: Choose one with dotnet, curl, and pwsh (pre-install if necessary).

For pure REST (no SDK), replace the deploy script with curl calls:

script:
  - |
    curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
      -H "Authorization: Basic $(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)" \\
      -H "Content-Type: application/json" \\
      -d "{\\"projectId\\": \\"$PROJECT_ID\\", \\"version\\": \\"$CI_PIPELINE_ID.0.0\\", \\"packageVersions\\": {\\"$PACKAGE_ID\\": \\"$CI_PIPELINE_ID.0.0\\"}}"
  # Then curl to /api/release/deploy with the release ID from response

Check the API Reference for exact endpoints.

Step 4: Test and Monitor

1. Commit your .gitlab-ci.yml and push to trigger the pipeline.
2. Monitor GitLab CI/CD logs for execution.
3. In Jaws, view the Deployments tab for real-time progress and logs.

Inspect GitLab-initiated deploys here, with statuses, triggers, and running times.

If debugging, set a __debug variable to true in your Jaws project for detailed logs.

Best Practices

• Variable Protection: Mark credentials as "protected" and "masked" in GitLab to limit exposure.
• Conditional Deploys: Use rules or only/except to deploy to Production only on tags or merges (e.g., rules: - if: '$CI_COMMIT_TAG').
• Artifact Handling: Store packages in GitLab artifacts for backups; reference versions in Jaws.
• Error Management: Add retry logic or notifications (e.g., via GitLab integrations) on failure.
• Runner Optimization: Use shared Runners with pre-installed PowerShell to speed up jobs.
• Multi-Environment: Add stages for Production with manual triggers (when: manual).

For larger setups, use GitLab's include/templates for reusable configs.

Troubleshooting Common Issues

• Auth Problems: Ensure variables are available in the job (check scopes) and Base64 is correctly encoded.
• Package Issues: Verify upload paths and version matching.
• PowerShell Missing: Install via script (apt update && apt install -y powershell) or switch to a custom Docker image.
• Pipeline Failures: Use set -e in shells for error propagation; check Jaws logs for deployment-specific errors.
• Timeouts: Optimize builds or increase Jaws parallelism in steps.

Consult GitLab docs or our API Reference.

Conclusion

Integrating GitLab with Jaws Deploy enhances your CI/CD pipeline by delegating deployment orchestration to a specialized tool, improving efficiency and reliability.

For more on integrations, explore the CI/CD Integration Guide. Configure your pipeline now and automate away! New to Jaws? Begin with the Getting Started guide.

‍

Integrating Azure Pipelines

Azure Pipelines, part of Azure DevOps, is a versatile CI/CD service for building, testing, and deploying code across platforms. It's excellent for the continuous integration (CI) phase but can become script-heavy for intricate deployments involving multiple environments, configurations, and targets. Jaws Deploy enhances this by specializing in continuous deployment (CD), managing releases, lifecycles, variable scoping, and real-time monitoring.

In this integration, Azure Pipelines handles builds and artifact creation (e.g., .zip packages), while Jaws Deploy orchestrates the release and deployment. Use Jaws' REST API or PowerShell SDK for automation—no native Azure extension is required; incorporate script tasks in your pipelines.

This guide details prerequisites, setup, an example pipeline, and tips for effective integration.

Why Integrate Azure Pipelines with Jaws Deploy?

• Optimized Workflow: Azure Pipelines excels at CI; Jaws focuses on CD with features like tags for precise targeting and lifecycles for automated progression.
• End-to-End Automation: Automatically create and deploy releases after successful builds, minimizing manual steps.
• Advanced Visibility: Leverage Jaws' dashboards for deployment history, trends, and logs, extending Azure's task outputs.
• Native Azure Synergy: Seamlessly deploy to Azure Web Apps or VMs, with shared Azure credentials for simplicity.

This combination is ideal for .NET, cloud-native apps, or hybrid setups where Azure builds artifacts and Jaws deploys them reliably.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• An Azure DevOps organization and project with Pipelines enabled.
• A Jaws project configured with steps, environments (e.g., Staging, Production), and a package store if using packages.
• Azure Pipelines variables or variable groups for secrets.
• A self-hosted or Microsoft-hosted agent with PowerShell (default on most agents) or curl for REST.

Ensure your Jaws project is ready here, including steps, variables, and environments.

Step 1: Create a Service Account in Jaws Deploy

Service accounts enable secure API access from pipelines.

1. In Jaws, head to Settings > Service Accounts.
2. Add a new account (e.g., "AzurePipelinesDeployer") with permissions for release and deployment actions on specific projects/workspaces.
3. Copy the service account ID and API key.

In Azure DevOps:

• Go to your project > Pipelines > Library > Variable groups (or use pipeline variables).
• Create a group (e.g., "JawsCreds") with:
  • JAWS_API_LOGIN = service account ID (secret).
  • JAWS_API_PASSWORD = API key (secret).

Link this group to your pipeline for secure access.

For details, see the Service Accounts and Automation Guide.

Step 2: Choose Your Integration Method

• REST API: Direct HTTP requests via curl in bash or PowerShell tasks. Versatile for any agent.
• PowerShell SDK: Import the SDK in scripts for simplified commands like Invoke-ReleaseAndDeployProject. Suited for Windows agents or cross-platform with PowerShell Core.

The example uses the SDK, with REST notes provided.

Step 3: Set Up Your Azure Pipeline

Create a YAML pipeline in Azure DevOps (e.g., azure-pipelines.yml in your repo). This example builds a .NET app, packages it, uploads to Jaws, and deploys.

Example azure-pipelines.yml

trigger:
- main

pool:
  vmImage: 'windows-latest'  # Or ubuntu-latest for Linux

variables:
- group: JawsCreds  # Your variable group with creds

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: '**/*.csproj'
        arguments: '--configuration Release'
    - task: DotNetCoreCLI@2
      inputs:
        command: 'publish'
        publishWebProjects: false
        projects: '**/*.csproj'
        arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)/out'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/out'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/app.zip'
    # Upload package to Jaws via REST (PowerShell task with curl)
    - task: PowerShell@2
      inputs:
        targetType: 'inline'
        script: |
          $auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$env:JAWS_API_LOGIN:$env:JAWS_API_PASSWORD"))
          curl.exe -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" `
            -H "Authorization: Basic $auth" `
            -F "file=@$(Build.ArtifactStagingDirectory)/app.zip" `
            -F "packageId=my-app" `
            -F "version=$(Build.BuildNumber).0.0"  # Use build number for SemVer

- stage: Deploy
  dependsOn: Build
  jobs:
  - job: DeployJob
    steps:
    # Deploy via PowerShell SDK
    - task: PowerShell@2
      inputs:
        targetType: 'inline'
        script: |
          # Download and import SDK
          Invoke-WebRequest -Uri "<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>" -OutFile "JawsDeploySdk.psm1"
          Import-Module ./JawsDeploySdk.psm1

          # Set credentials
          $env:JAWS_API_LOGIN = $env:JAWS_API_LOGIN
          $env:JAWS_API_PASSWORD = $env:JAWS_API_PASSWORD

          # Create release and deploy
          $projectId = "your-project-id"  # From Jaws Projects page
          $version = "$(Build.BuildNumber).0.0"
          $response = Invoke-ReleaseAndDeployProject -projectId $projectId -version $version -environmentName "Staging"
          Write-Output $response

Key Explanations

• Build Stage: Builds, publishes, zips the artifact, and uploads to Jaws' package store using curl in a PowerShell task with Basic Auth from variables.
• Deploy Stage: Downloads/imports the SDK, sets creds, and calls Invoke-ReleaseAndDeployProject to create a release and deploy to Staging.
• Versioning: Uses Azure's $(Build.BuildNumber) for traceable SemVer.
• Agent: Windows-latest includes PowerShell and curl; adapt for Ubuntu if needed.

For pure REST, replace the deploy script with curl commands:

$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$env:JAWS_API_LOGIN:$env:JAWS_API_PASSWORD"))
curl.exe -X POST "<https://app.jawsdeploy.net/api/release>" `
  -H "Authorization: Basic $auth" `
  -H "Content-Type: application/json" `
  -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$(Build.BuildNumber).0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$(Build.BuildNumber).0.0\\"}}"
# Follow with curl for /api/release/deploy

‍

Reference the API Reference for endpoints.

Step 4: Test and Monitor

1. Commit your YAML and queue a build in Azure Pipelines.
2. Review task logs in Azure.
3. In Jaws, check the Deployments tab for live status and logs.

Monitor Azure-triggered deploys here, with creation times, statuses, and durations.

For debugging, add a __debug variable set to true in your Jaws project to expand logs with full context.

Best Practices

• Secret Management: Use variable groups with secrets; enable approvals for Production stages.
• Conditional Execution: Add gates or environments in Azure for Production deploys (e.g., manual approval tasks).
• Artifact Publishing: Publish artifacts in Azure for backups; sync versions with Jaws.
• Error Propagation: Use errorActionPreference: 'Stop' in PowerShell for better handling.
• Agent Selection: Choose agents matching your build (e.g., windows for .NET).
• Scaling: Parameterize pipelines for multiple projects; use templates for reuse.

Troubleshooting Common Issues

• Authentication Errors: Confirm variable scopes and Base64 encoding.
• Package Upload Fails: Verify file paths and API parameters.
• SDK Import Issues: Ensure network access; cache the SDK if possible.
• Pipeline Timeouts: Break into smaller tasks or optimize steps.
• Logs: Use Jaws' UI for detailed insights; enable verbose output in scripts.

Check Azure docs or our API Reference.

Conclusion

Integrating Azure Pipelines with Jaws Deploy creates a powerful, Azure-centric CI/CD flow, where builds transition seamlessly to orchestrated deployments.

For additional integrations, see the CI/CD Integration Guide. Set up your pipeline today! If you're starting out, explore the Getting Started guide.

Integrating BuildKite

BuildKite is a flexible CI/CD platform that allows teams to run pipelines on their own infrastructure, offering scalable agents and easy YAML-based configuration. It's strong for continuous integration (CI) tasks like building and testing but can require custom scripting for advanced deployment orchestration. Jaws Deploy fills this gap by handling continuous deployment (CD), including release management, environment progression via lifecycles, variable scoping, and detailed monitoring.

In this integration, BuildKite manages the build process (e.g., compiling code and creating artifacts like .zip packages), while Jaws Deploy takes care of release creation and deployment. Use Jaws' REST API or PowerShell SDK for the handover—no native BuildKite plugin is needed; incorporate commands or scripts in your pipeline steps.

This guide covers prerequisites, setup, an example pipeline, and tips for optimization.

Why Integrate BuildKite with Jaws Deploy?

• Role Specialization: BuildKite excels at CI on custom agents; Jaws handles CD with reusable steps, tags, and automated promotions.
• Automated Flow: Trigger Jaws releases directly after builds, streamlining the pipeline without complex plugins.
• Better Insights: Access Jaws' dashboards for deployment trends, logs, and history, enhancing BuildKite's job outputs.
• Customizability: Leverage BuildKite's agent queues for targeted runs, combined with Jaws' security features like scoped secrets.

This setup works well for .NET apps, containerized services, or any workflow where BuildKite builds artifacts and Jaws deploys to on-prem or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A BuildKite organization and pipeline set up with agents (self-hosted or cloud).
• A Jaws project with defined steps, environments (e.g., Staging, Production), and optionally a package store.
• BuildKite environment variables or hooks for secrets.
• Agents with curl (for REST) or PowerShell Core (for SDK; install via package manager if needed).

Verify your Jaws project configuration here, including steps and variables.

Step 1: Create a Service Account in Jaws Deploy

For secure API interactions:

1. In Jaws, navigate to Settings > Service Accounts.
2. Create an account (e.g., "BuildKiteDeployer") with permissions for release creation and deployment on specific projects/workspaces.
3. Copy the service account ID and API key.

In BuildKite:

• Go to Pipeline Settings > Environment Variables.
• Add protected variables:
  • JAWS_API_LOGIN = service account ID.
  • JAWS_API_PASSWORD = API key (mark as secret).

This keeps credentials secure and accessible in steps.

See the Service Accounts and Automation Guide for more.

Step 2: Choose Your Integration Method

• REST API: Execute curl commands in bash steps for HTTP calls. Suitable for any agent.
• PowerShell SDK: Run PowerShell scripts to import the SDK and use functions like Invoke-ReleaseAndDeployProject. Requires PowerShell on the agent (common on Windows; install pwsh on Linux).

The example uses the SDK, with REST alternatives.

Step 3: Set Up Your BuildKite Pipeline

Define your pipeline in BuildKite's YAML editor or use an in-repo pipeline.yml (uploaded via buildkite-agent pipeline upload). This example assumes a .NET build, with build and deploy steps.

Example pipeline.yml

steps:
  - label: ":hammer: Build"
    command:
      - dotnet build --configuration Release
      - dotnet publish -c Release -o out
      - zip -r app.zip out/
      # Upload package to Jaws via REST API (using curl)
      - |
        auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
        curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
          -H "Authorization: Basic $auth" \\
          -F "file=@app.zip" \\
          -F "packageId=my-app" \\
          -F "version=$BUILDKITE_BUILD_NUMBER.0.0"  # Use build number for SemVer
    env:
      JAWS_API_LOGIN: $JAWS_API_LOGIN
      JAWS_API_PASSWORD: $JAWS_API_PASSWORD
    artifact_paths: "app.zip"  # Archive for reference

  - wait

  - label: ":cloud: Deploy to Staging"
    command:
      # Download and import PowerShell SDK (using pwsh)
      - pwsh -Command "Invoke-WebRequest -Uri '<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>' -OutFile 'JawsDeploySdk.psm1'"
      - pwsh -Command "Import-Module ./JawsDeploySdk.psm1"
      # Create release and deploy
      - |
        pwsh -Command "
        \\$env:JAWS_API_LOGIN = '$JAWS_API_LOGIN'
        \\$env:JAWS_API_PASSWORD = '$JAWS_API_PASSWORD'
        \\$projectId = 'your-project-id'  # From Jaws Projects page
        \\$version = '$BUILDKITE_BUILD_NUMBER.0.0'
        \\$response = Invoke-ReleaseAndDeployProject -projectId \\$projectId -version \\$version -environmentName 'Staging'
        Write-Output \\$response
        "
    env:
      JAWS_API_LOGIN: $JAWS_API_LOGIN
      JAWS_API_PASSWORD: $JAWS_API_PASSWORD
    agents:
      queue: deploy  # Target deploy-specific agents
    branches: "main"

Key Explanations

• Build Step: Builds, publishes, zips the artifact, and uploads to Jaws' package store using curl with Basic Auth from env vars.
• Deploy Step: Downloads/imports the SDK with pwsh, sets creds, and invokes Invoke-ReleaseAndDeployProject for release and deployment to Staging.
• Versioning: Uses BuildKite's $BUILDKITE_BUILD_NUMBER for traceable versions.
• Agents and Env: Targets a "deploy" queue; passes secure env vars.

For pure REST, replace the deploy command with curl:

- |
  auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
  curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
    -H "Authorization: Basic $auth" \\
    -H "Content-Type: application/json" \\
    -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$BUILDKITE_BUILD_NUMBER.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$BUILDKITE_BUILD_NUMBER.0.0\\"}}"
# Add another curl for /api/release/deploy

‍

Refer to the API Reference for details.

Step 4: Test and Monitor

1. Trigger a build in BuildKite (e.g., via push or manual).
2. Check step logs in BuildKite.
3. In Jaws, monitor the Deployments tab for progress and outputs.

View BuildKite-triggered deploys here, with statuses, triggers, and timings.

Enable debug in Jaws by setting __debug to true for expanded logs.

Best Practices

• Secret Handling: Use BuildKite's environment variables or hooks for secrets; avoid committing them.
• Conditional Steps: Use branches or if conditions for Production deploys (e.g., on tags).
• Artifacts: Upload logs or responses as artifacts for auditing.
• Error Handling: Add exit codes in scripts to fail steps on issues.
• Agent Queues: Route deploy steps to specialized agents with required tools (e.g., pwsh).
• Reusability: Use dynamic pipelines or templates for multi-project support.

Troubleshooting Common Issues

• Auth Failures: Verify env var availability and Base64 encoding.
• Upload Errors: Check file paths and API params.
• PowerShell Unavailable: Install pwsh on agents or use bash/curl alternatives.
• Step Timeouts: Optimize commands or increase agent resources.
• Logs: Use Jaws' UI for detailed deployment info.

Consult BuildKite docs or our API Reference.

Conclusion

Integrating BuildKite with Jaws Deploy creates a scalable CI/CD pipeline, combining BuildKite's agent flexibility with Jaws' deployment expertise.

For more integrations, check the CI/CD Integration Guide. Configure your pipeline now! New users: Start with the Getting Started guide.

Integrating TeamCity

TeamCity is a powerful continuous integration (CI) server from JetBrains, known for its flexibility in building, testing, and artifact management. While it can handle basic deployments via plugins or scripts, complex multi-environment orchestration often requires a dedicated tool. Jaws Deploy integrates natively with TeamCity to manage the continuous deployment (CD) phase, handling releases, promotions, variable scoping, and monitoring.

This integration lets TeamCity focus on builds (e.g., compiling code and creating packages), while Jaws Deploy orchestrates deployments. Jaws provides a first-class TeamCity plugin, PowerShell SDK, or REST API options. A dedicated guide exists for this setup, making it straightforward for .NET teams or those with Windows/Linux agents.

Why Integrate TeamCity with Jaws Deploy?

• Native Support: Use the official plugin for seamless build steps, or SDK/API for custom logic.
• Automated Releases: Create and deploy releases automatically post-build, with options for promotion.
• Enhanced CD Features: Leverage Jaws' lifecycles, tags, and dashboards for progression and visibility.
• Efficiency: Reduce script maintenance in TeamCity; centralize deployment logic in Jaws.

Ideal for scenarios like deploying .NET apps to Azure or on-prem servers after TeamCity builds.

Prerequisites

• Administrative access to TeamCity (version 2021.2+; 2022.10+ recommended).
• Access to a Jaws Deploy instance (cloud or self-hosted).
• A Jaws project with steps, environments (e.g., Staging, Production), and optionally a package store.
• TeamCity agents with PowerShell (for SDK) or curl (for REST).

Set up your Jaws project here before integrating.

Step 1: Create a Service Account in Jaws Deploy

For secure automation:

1. In Jaws, go to Settings > Service Accounts.
2. Add a new account (e.g., "TeamCityDeployer") with permissions for release creation, deployment, and promotion on relevant projects/workspaces.
3. Copy the Service Account ID and API Key.

In TeamCity:

• Use build parameters (e.g., %JawsDeployLogin% for ID, %JawsDeployApiKey% for key) stored securely via configuration parameters or encrypted values.

Step 2: Choose Your Integration Method

• TeamCity Plugin: Easiest for standard workflows; adds Jaws-specific build steps.
• PowerShell SDK: For scripted flexibility; zero-dependency module with high-level commands.
• REST API: For raw control; use HTTP calls in any runner (bash, PowerShell, etc.).

We'll cover the plugin and SDK primarily, as they're recommended.

Step 3: Set Up the Integration in TeamCity

Using the TeamCity Plugin

1. Download the plugin ZIP from https://github.com/JawsDeploy/jawsdeploy-teamcity-plugin.
2. In TeamCity: Administration > Plugins > Upload plugin zip, then enable it.
3. In your build configuration, add a new build step and select "Jaws Deploy."
4. Configure:
   • API Base URL: https://app.jawsdeploy.net (or your instance).
   • Login: %JawsDeployLogin% (Service Account ID).
   • API Key: %JawsDeployApiKey%.
   • Operation: "Create & Deploy" or "Promote."
   • Project ID: Your Jaws project ID (from the app UI).
   • Version: SemVer (e.g., %build.number%); auto-generates if blank.
   • Channel name: Optional for lifecycle.
   • Environments: Comma-separated (e.g., "Staging").
   • Release notes: Optional text.
   • Redownload packages: True to force re-download.
   • Exclude step names: Comma-separated steps to skip.

Example configuration for "Create & Deploy":

• Operation: Create & Deploy
• Project ID: abc123
• Version: %build.number%
• Environments: Staging

Run the build; logs show deployment progress.

Using the PowerShell SDK

1. Add a VCS root in TeamCity to https://github.com/JawsDeploy/powershell-sdk (checkout the .psm1 file).
2. Use checkout rules like +:JawsDeploySdk.psm1 => ./_teamcity to place it neatly.
3. Add a PowerShell build step with script like:

# Set env vars (or use parameters)
$env:JAWS_API_BASE_URL = "%JawsDeployApiUrl%"
$env:JAWS_API_LOGIN = "%JawsDeployLogin%"
$env:JAWS_API_PASSWORD = "%JawsDeployApiKey%"

# Import SDK
Import-Module -Name (Join-Path "." _teamcity JawsDeploySdk.psm1)

# Create and deploy release
$projectId = "%MyApp_ProjectId%"
$jawsEnv = "%DeploymentEnvironment%"
$resp = Invoke-ReleaseAndDeployProject -projectId $projectId -version "%build.number%" -environmentName $jawsEnv
Write-Host $resp

# Or promote latest release
$resp = Invoke-PromoteRelease -projectId $projectId -environmentName $jawsEnv
Write-Host $resp

# Promote specific version
$resp = Invoke-PromoteRelease -projectId $projectId -environmentName $jawsEnv -version "%build.number%"
Write-Host $resp

Adapt for your build (e.g., after artifact creation and upload via API).

Using REST API (Alternative)

In a Command Line or PowerShell step, use curl or Invoke-WebRequest for endpoints like /api/release and /api/release/deploy. Base auth with encoded credentials.

Step 4: Test and Monitor

1. Queue a TeamCity build.
2. Check build logs for Jaws outputs.
3. In Jaws, view the Deployments tab for details.

Track TeamCity-initiated deploys here, with triggers like "TeamCity."

Set __debug to true in Jaws variables for verbose logs.

Best Practices

• Use TeamCity parameters for all configurable values (e.g., project ID, environments) to make builds flexible.
• Store credentials as encrypted parameters to avoid exposure.
• Chain builds: Use one for CI, trigger another for CD with artifacts.
• For promotions, use "Promote" operation after manual reviews.
• Test in a non-prod environment first; monitor agent compatibility (e.g., PowerShell on Windows agents).

Troubleshooting Common Issues

• Plugin Not Loading: Ensure TeamCity version compatibility; restart server.
• Auth Errors: Verify service account scopes and parameter resolution.
• SDK Import Fails: Check VCS checkout; use full paths.
• Deployment Fails: Review Jaws logs for step-specific issues.
• Version Conflicts: Use unique SemVer; enable auto-generation if needed.

Conclusion

Integrating Jaws Deploy with TeamCity creates a robust CI/CD pipeline, leveraging TeamCity's build power and Jaws' deployment orchestration.

For details, see the official Integrate Jaws Deploy with TeamCity guide. Explore more in the CI/CD Integration Guide. Set it up and automate your releases! New to Jaws? Try Getting Started.

‍

Integrating CircleCI

CircleCI is a cloud-based CI/CD platform that automates building, testing, and deploying code with YAML-configured pipelines. It's efficient for continuous integration (CI) but can benefit from a dedicated tool for handling complex deployments. Jaws Deploy integrates with CircleCI to manage the continuous deployment (CD) phase, overseeing releases, environment progressions via lifecycles, variable management, and deployment monitoring.

In this setup, CircleCI handles builds and artifact creation (e.g., .zip packages), while Jaws Deploy manages release creation and deployment. Use Jaws' REST API or PowerShell SDK for automation—no native CircleCI orb exists; incorporate scripts in your config.yml.

This guide covers prerequisites, setup, an example pipeline, and tips for success.

Why Integrate CircleCI with Jaws Deploy?

• Complementary Strengths: CircleCI shines in CI workflows; Jaws excels in CD with features like scoped variables, tags for targeting, and automated lifecycles.
• Seamless Automation: Trigger Jaws releases post-build, reducing manual effort and errors.
• Visibility Boost: Gain access to Jaws' dashboards for trends, logs, and history, extending CircleCI's job artifacts.
• Flexibility: Supports CircleCI's orbs and executors, combined with Jaws' security for API-driven deploys.

This integration suits web apps, .NET projects, or containerized services where CircleCI builds artifacts and Jaws deploys to on-prem or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A CircleCI project connected to your repo (GitHub/Bitbucket).
• A Jaws project with steps, environments (e.g., Staging, Production), and optionally a package store.
• CircleCI context or project variables for secrets.
• Executors with curl (for REST) or PowerShell (for SDK; use Windows executors or install pwsh on Linux).

Configure your Jaws project here before starting.

Step 1: Create a Service Account in Jaws Deploy

For secure pipeline access:

1. In Jaws, go to Settings > Service Accounts.
2. Create an account (e.g., "CircleCIDeployer") with permissions for release creation and deployment on specific projects/workspaces.
3. Copy the service account ID and API key.

In CircleCI:

• Go to Organization Settings > Contexts (or project settings for variables).
• Create/add to a context (e.g., "jaws-deploy") with:
  • JAWS_API_LOGIN = service account ID.
  • JAWS_API_PASSWORD = API key (as secure env vars).

Reference this context in your config.yml.

See the Service Accounts and Automation Guide for details.

Step 2: Choose Your Integration Method

• REST API: Use curl in bash commands for HTTP calls. Simple for Linux executors.
• PowerShell SDK: Run scripts to import the SDK and use commands like Invoke-ReleaseAndDeployProject. Requires PowerShell on the executor (pre-installed on Windows; add setup on others).

The example uses the SDK, with REST notes.

Step 4: Set Up Your CircleCI Pipeline

Create a .circleci/config.yml in your repo. This example builds a .NET app, packages it, uploads to Jaws, and deploys.

Example config.yml

version: 2.1

orbs:
  win: circleci/windows@5.0.0  # For PowerShell on Windows executor

jobs:
  build:
    executor: win/default  # Or linux for bash/curl
    steps:
      - checkout
      - run:
          name: Build and Package
          command: |
            dotnet build --configuration Release
            dotnet publish -c Release -o out
            Compress-Archive -Path out/* -DestinationPath app.zip
      - run:
          name: Upload Package to Jaws (REST)
          command: |
            $auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$env:JAWS_API_LOGIN:$env:JAWS_API_PASSWORD"))
            curl.exe -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" `
              -H "Authorization: Basic $auth" `
              -F "file=@app.zip" `
              -F "packageId=my-app" `
              -F "version=$CIRCLE_BUILD_NUM.0.0"  # Use build number for SemVer
      - persist_to_workspace:
          root: .
          paths:
            - app.zip  # Optional for archiving

  deploy:
    executor: win/default
    steps:
      - attach_workspace:
          at: .
      - run:
          name: Deploy via PowerShell SDK
          command: |
            Invoke-WebRequest -Uri "<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>" -OutFile "JawsDeploySdk.psm1"
            Import-Module ./JawsDeploySdk.psm1

            $env:JAWS_API_LOGIN = $env:JAWS_API_LOGIN
            $env:JAWS_API_PASSWORD = $env:JAWS_API_PASSWORD

            $projectId = "your-project-id"  # From Jaws Projects page
            $version = "$env:CIRCLE_BUILD_NUM.0.0"
            $response = Invoke-ReleaseAndDeployProject -projectId $projectId -version $version -environmentName "Staging"
            Write-Output $response

workflows:
  build-deploy:
    jobs:
      - build
      - deploy:
          requires:
            - build
          context:
            - jaws-deploy  # Your context with creds

Key Explanations

• Build Job: Builds, publishes, zips, and uploads to Jaws' package store using curl in PowerShell with Basic Auth.
• Deploy Job: Imports the SDK, sets creds, and calls Invoke-ReleaseAndDeployProject for release and deployment to Staging.
• Versioning: Uses CircleCI's $CIRCLE_BUILD_NUM for SemVer.
• Executor: Windows for native PowerShell; for Linux, use bash and pwsh installation steps (e.g., apt install powershell).

For pure REST on Linux:Replace deploy command with bash curl:

run:
  name: Create Release (REST)
  shell: bash
  command: |
    auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
    curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
      -H "Authorization: Basic $auth" \\
      -H "Content-Type: application/json" \\
      -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$CIRCLE_BUILD_NUM.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$CIRCLE_BUILD_NUM.0.0\\"}}"
    # Add curl for /api/release/deploy

Check the API Reference for endpoints.

Step 4: Test and Monitor

1. Push changes to trigger the workflow.
2. View job logs in CircleCI.
3. In Jaws, check the Deployments tab for progress.

Monitor CircleCI-triggered deploys here, with statuses and durations.

For debugging, set a __debug variable to true in your Jaws project for detailed logs.

Best Practices

• Secure Vars: Use contexts for secrets; restrict to branches.
• Conditional Workflows: Add filters (e.g., filters: branches: only: main) for Production.
• Artifacts: Store in CircleCI for backups; align versions with Jaws.
• Error Handling: Use set -e in bash or try-catch in PowerShell.
• Executors: Match to your stack (e.g., machine executor for custom images).
• Orbs: Combine with other orbs for enhanced builds.

Troubleshooting Common Issues

• Auth Failures: Ensure context vars are linked and encoded correctly.
• Package Errors: Verify paths and versions.
• SDK Issues: Confirm executor has PowerShell; test downloads.
• Timeouts: Optimize steps or use faster executors.
• Logs: Use Jaws' UI for in-depth analysis.

Refer to CircleCI docs or our API Reference.

Conclusion

Integrating Jaws Deploy with CircleCI streamlines your CI/CD, letting CircleCI build efficiently while Jaws deploys reliably.

For more, see the CI/CD Integration Guide. Set up your config now! New to Jaws? Start with Getting Started.

Integrating Travis CI

Travis CI is a popular continuous integration (CI) platform, especially for open-source projects on GitHub, automating builds, tests, and artifact generation. While it supports basic deployments through scripts, managing intricate multi-environment rollouts can lead to maintenance overhead. Jaws Deploy complements Travis CI by taking on the continuous deployment (CD) responsibilities, including release orchestration, lifecycle progression, variable scoping, and comprehensive monitoring.

In this integration, Travis CI handles the build phase (e.g., compiling code and creating .zip packages), while Jaws Deploy manages release creation and deployment. Use Jaws' REST API or PowerShell SDK for the connection—no native Travis plugin is required; embed scripts in your .travis.yml.

Note: As of April 1, 2025, Travis CI has discontinued macOS builds due to VMWare EOL, so focus on Linux or Windows executors for new setups.

This guide outlines prerequisites, setup, an example configuration, and best practices.

Why Integrate Travis CI with Jaws Deploy?

• Focused Expertise: Travis CI optimizes CI on GitHub-integrated workflows; Jaws specializes in CD with tags for targeting, reusable steps, and automated promotions.
• Streamlined Automation: Automatically trigger Jaws releases after builds, enhancing pipeline efficiency.
• Advanced Monitoring: Utilize Jaws' dashboards for deployment trends, logs, and history, beyond Travis' build outputs.
• Security and Scalability: Secure API access via service accounts, ideal for OSS or enterprise projects.

This pairing is great for .NET apps or web services where Travis builds artifacts and Jaws deploys to machines or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A Travis CI account linked to your GitHub repo (free for public repos; paid for private).
• A Jaws project with steps, environments (e.g., Staging, Production), and optionally a package store.
• Travis repository settings for environment variables (secure ones encrypted).
• Travis executors with curl (standard on Linux) or PowerShell (on Windows or installed on Linux).

Prepare your Jaws project here, defining steps and variables.

Step 1: Create a Service Account in Jaws Deploy

For secure, scripted access:

1. In Jaws, navigate to Settings > Service Accounts.
2. Add a new account (e.g., "TravisDeployer") with permissions for release creation and deployment on relevant projects/workspaces.
3. Copy the service account ID and API key.

In Travis CI:

• Go to your repository > Settings > Environment Variables.
• Add:
  • JAWS_API_LOGIN = service account ID (not encrypted if public).
  • JAWS_API_PASSWORD = API key (use encrypted variables for security via travis encrypt CLI).

For encrypted vars: Run travis encrypt JAWS_API_PASSWORD=your_key --add env in your local CLI.

Refer to the Service Accounts and Automation Guide.

Step 2: Choose Your Integration Method

• REST API: Issue curl commands in bash scripts. Ideal for Linux executors.
• PowerShell SDK: Import the SDK in scripts for commands like Invoke-ReleaseAndDeployProject. Use Windows executors or install pwsh on Linux (via sudo apt install -y powershell).

We'll demonstrate REST with curl for simplicity, common in Travis setups.

Step 3: Set Up Your Travis CI Configuration

Create a .travis.yml in your repo root. This example builds a .NET app (using dotnet), packages it, uploads to Jaws, and deploys via REST.

Example .travis.yml

language: csharp  # Or node_js, python, etc., for your stack
dist: focal  # Ubuntu 20.04; use windows for PowerShell-native

env:
  global:
    secure: "your_encrypted_JAWS_API_PASSWORD"  # From travis encrypt

script:
  - dotnet build --configuration Release
  - dotnet publish -c Release -o out
  - zip -r app.zip out/

after_success:
  # Upload package to Jaws via REST (curl)
  - |
    auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
    curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
      -H "Authorization: Basic $auth" \\
      -F "file=@app.zip" \\
      -F "packageId=my-app" \\
      -F "version=$TRAVIS_BUILD_NUMBER.0.0"  # Use build number for SemVer

deploy:
  provider: script
  script: bash -c "
    auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
    curl -X POST \\"<https://app.jawsdeploy.net/api/release\\>" \\
      -H \\"Authorization: Basic $auth\\" \\
      -H \\"Content-Type: application/json\\" \\
      -d '{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$TRAVIS_BUILD_NUMBER.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$TRAVIS_BUILD_NUMBER.0.0\\"}}'
    # Extract releaseId from response if needed, then:
    curl -X POST \\"<https://app.jawsdeploy.net/api/release/deploy\\>" \\
      -H \\"Authorization: Basic $auth\\" \\
      -H \\"Content-Type: application/json\\" \\
      -d '{\\"releaseId\\": \\"extracted-release-id\\", \\"environments\\": [\\"Staging\\"]}'
    "
  on:
    branch: main

Key Explanations

• Script Section: Builds, publishes, and zips the artifact.
• After Success: Uploads to Jaws' package store using curl with Basic Auth.
• Deploy Section: Custom script provider to create a release and deploy to Staging via sequential curl calls. Parse the release creation response (e.g., with jq if installed) to get releaseId.
• Versioning: Leverages $TRAVIS_BUILD_NUMBER for traceability.
• Secure Vars: Access encrypted password via $JAWS_API_PASSWORD.

For PowerShell SDK (on Windows executor):Add os: windows to yml, and use a PowerShell script step:

script:
  - pwsh -Command "Invoke-WebRequest -Uri '<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>' -OutFile 'JawsDeploySdk.psm1'"
  - pwsh -Command "Import-Module ./JawsDeploySdk.psm1; Invoke-ReleaseAndDeployProject -projectId 'your-project-id' -version '$TRAVIS_BUILD_NUMBER.0.0' -environmentName 'Staging'"

Adapt endpoints from the API Reference.

Step 4: Test and Monitor

1. Commit your .travis.yml and push to trigger a build.
2. Monitor Travis logs for execution.
3. In Jaws, check the Deployments tab for status and logs.

View Travis-triggered deploys here, with creation times, statuses, and errors.

Enable debug mode in Jaws by setting __debug to true for detailed variable and step context.

Best Practices

• Encryption: Always encrypt sensitive vars with travis encrypt to prevent exposure in public repos.
• Branch Filtering: Use on: branch: main for Production deploys; add conditions for tags.
• Artifacts: Upload to Travis artifacts for backups; ensure versions sync with Jaws.
• Error Handling: Add checks in scripts (e.g., set -e in bash) to fail on issues.
• Executors: Use os: windows for PowerShell-heavy setups; install dependencies as needed.
• Testing: Run local with travis lint and simulate builds.

Troubleshooting Common Issues

• Auth Problems: Confirm encrypted vars decrypt correctly; test Base64 in isolation.
• Package Failures: Verify file paths and API parameters.
• PowerShell Missing: Install via script on Linux (apt update && apt install -y powershell).
• Build Timeouts: Split steps or optimize for faster execution.
• Logs: Use Jaws' UI for deployment-specific details.

Consult Travis docs or our API Reference.

Conclusion

Integrating Jaws Deploy with Travis CI enhances your CI/CD pipeline, combining Travis' GitHub-friendly builds with Jaws' robust deployments.

For broader integrations, see the CI/CD Integration Guide. Configure your .travis.yml today! If new to Jaws, begin with the Getting Started guide.

Integrating Bitbucket Pipelines

Bitbucket Pipelines is Atlassian's integrated CI/CD solution for Bitbucket repositories, enabling automated builds, tests, and deployments through YAML-defined pipelines. It's effective for continuous integration (CI) but can require additional scripting for sophisticated deployment orchestration. Jaws Deploy pairs with Bitbucket Pipelines to handle the continuous deployment (CD) aspect, managing releases, lifecycle progressions, variable scoping, and detailed monitoring.

In this integration, Bitbucket Pipelines focuses on builds (e.g., compiling code and generating .zip packages), while Jaws Deploy oversees release creation and deployment. Leverage Jaws' REST API or PowerShell SDK—no native Bitbucket step exists; use script commands in your pipelines.

This guide details prerequisites, setup, an example pipeline, and tips for a seamless workflow.

Why Integrate Bitbucket Pipelines with Jaws Deploy?

• Role Optimization: Bitbucket excels at CI within Atlassian ecosystems; Jaws handles CD with features like environment-specific scoping, tags for targeting, and reusable script modules.
• Automated Transitions: Trigger Jaws releases automatically after builds, streamlining end-to-end delivery.
• Enhanced Oversight: Access Jaws' dashboards for deployment activity, errors, and trends, complementing Bitbucket's logs.
• Atlassian Synergy: Ideal for teams using Jira or Confluence, with secure integrations for hybrid setups.

This combination suits .NET apps, web services, or containerized workflows where Bitbucket builds artifacts and Jaws deploys to on-prem machines or cloud targets like Azure Web Apps.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A Bitbucket repository with Pipelines enabled (requires a paid plan for private repos).
• A Jaws project configured with steps, environments (e.g., Staging, Production), and optionally a package store.
• Bitbucket repository variables for secrets.
• Pipelines with access to curl (default) or PowerShell (install via scripts on Ubuntu-based images).

Set up your Jaws project here, including steps and variables.

Step 1: Create a Service Account in Jaws Deploy

For secure API calls:

1. In Jaws, go to Settings > Service Accounts.
2. Create a new account (e.g., "BitbucketDeployer") with permissions for release creation and deployment on specific projects/workspaces.
3. Copy the service account ID and API key.

In Bitbucket:

• Navigate to Repository settings > Pipelines > Repository variables.
• Add:
  • JAWS_API_LOGIN = service account ID.
  • JAWS_API_PASSWORD = API key (mark as secured to hide in logs).

See the Service Accounts and Automation Guide for more.

Step 2: Choose Your Integration Method

• REST API: Use curl in bash scripts for HTTP requests. Straightforward for standard Bitbucket images.
• PowerShell SDK: Execute scripts to import the SDK and use commands like Invoke-ReleaseAndDeployProject. Install PowerShell if needed (e.g., on atlassian/default-image:3).

The example uses REST for broad compatibility.

Step 3: Set Up Your Bitbucket Pipeline

Create a bitbucket-pipelines.yml in your repo root. This example builds a .NET app, packages it, uploads to Jaws, and deploys via REST.

Example bitbucket-pipelines.yml

image: mcr.microsoft.com/dotnet/sdk:8.0  # Or your base image

pipelines:
  default:
    - step:
        name: Build and Upload Package
        script:
          - dotnet build --configuration Release
          - dotnet publish -c Release -o out
          - zip -r app.zip out/
          # Upload to Jaws via REST (curl)
          - |
            auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
            curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
              -H "Authorization: Basic $auth" \\
              -F "file=@app.zip" \\
              -F "packageId=my-app" \\
              -F "version=$BITBUCKET_BUILD_NUMBER.0.0"  # Use build number for SemVer
        artifacts:
          - app.zip  # Optional for archiving

    - step:
        name: Create Release and Deploy
        script:
          # Create release via REST
          - |
            auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
            response=$(curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
              -H "Authorization: Basic $auth" \\
              -H "Content-Type: application/json" \\
              -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$BITBUCKET_BUILD_NUMBER.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$BITBUCKET_BUILD_NUMBER.0.0\\"}}" \\
              --write-out "%{http_code}" --silent --output /dev/null)
            # Parse response for releaseId if needed (use jq if installed: apt install jq)
            # For simplicity, assume success and proceed to deploy (use actual releaseId extraction)
            curl -X POST "<https://app.jawsdeploy.net/api/release/deploy>" \\
              -H "Authorization: Basic $auth" \\
              -H "Content-Type: application/json" \\
              -d "{\\"releaseId\\": \\"extracted-release-id\\", \\"environments\\": [\\"Staging\\"]}"

Key Explanations

• First Step: Builds, publishes, zips, and uploads to Jaws' package store using curl with Basic Auth.
• Second Step: Creates a release and deploys to Staging via curl. Extract releaseId from the first response (add jq: apt-get update && apt-get install -y jq at step start for parsing).
• Versioning: Uses Bitbucket's $BITBUCKET_BUILD_NUMBER for consistency.
• Image: Dotnet SDK for .NET; adapt for your language.

For PowerShell SDK:Add installation: apt-get update && apt-get install -y powershell, then use pwsh commands similar to other guides.

Reference the API Reference for exact endpoints.

Step 4: Test and Monitor

1. Commit your yml and push to trigger the pipeline.
2. Check Bitbucket Pipelines logs.
3. In Jaws, view the Deployments tab for real-time status.

Monitor Bitbucket-triggered deploys here, with triggers, statuses, and durations.

For debugging, set __debug to true in your Jaws project variables for expanded logs.

Best Practices

• Secured Vars: Mark sensitive variables as secured to mask in logs.
• Branch Triggers: Use branches: main under pipelines for Production controls.
• Artifacts: Download and reference in deploy steps if needed.
• Error Handling: Add checks like if [ $response -ne 200 ]; then exit 1; fi in scripts.
• Custom Images: Use cached images with pre-installed tools for speed.
• Parallel Steps: Run tests in parallel before deploy.

Troubleshooting Common Issues

• Auth Errors: Ensure vars are set and Base64 correct; test with echo (non-sensitive).
• Upload Fails: Verify file existence and params.
• PowerShell Install Issues: Use compatible images; handle apt dependencies.
• Pipeline Timeouts: Increase limits or optimize scripts.
• Logs: Use Jaws' UI for detailed outputs.

Consult Bitbucket docs or our API Reference.

Conclusion

Integrating Bitbucket Pipelines with Jaws Deploy creates an efficient Atlassian-aligned CI/CD flow, where builds lead seamlessly to orchestrated deployments.

For more integrations, explore the CI/CD Integration Guide. Configure your pipeline today! New to Jaws? Start with the Getting Started guide.

Integrating AWS Code Pipeline

AWS Code Pipeline is Amazon's fully managed CI/CD service, orchestrating workflows for building, testing, and deploying code across AWS resources. It's powerful for AWS-native pipelines but can be extended for hybrid or multi-cloud scenarios. Jaws Deploy integrates with CodePipeline to handle the deployment handover, focusing on CD orchestration like releases, lifecycles, and variable management—especially useful for deploying to non-AWS targets like Azure Web Apps, on-prem servers, or mixed environments.

In this setup, CodePipeline manages the CI phase (e.g., source from CodeCommit/S3, build with CodeBuild), then hands off to Jaws Deploy via API calls for hybrid/multi-cloud deploys. Use Jaws' REST API or PowerShell SDK, invoked through a CodeBuild action or Lambda in your pipeline. This enables seamless multi-cloud strategies, where AWS handles builds and Jaws deploys across providers.

This guide covers prerequisites, setup, an example pipeline, and tips, emphasizing hybrid/multi-cloud benefits.

Why Integrate AWS CodePipeline with Jaws Deploy?

• Hybrid/Multi-Cloud Flexibility: CodePipeline excels in AWS ecosystems (e.g., building for ECS/EC2); Jaws extends to Azure, GCP, or on-prem, enabling unified deploys without vendor lock-in.
• Efficient Handover: Automate release creation in Jaws post-build, using lifecycles for progression across clouds (e.g., test in AWS Staging, promote to Azure Production).
• Advanced CD Capabilities: Gain Jaws' scoping, tags, and dashboards for monitoring multi-cloud deploys, beyond CodePipeline's native actions.
• Cost and Simplicity: Avoid complex Lambda scripts; Jaws' API simplifies orchestration for distributed teams.

This integration shines in scenarios like deploying a .NET app built in AWS to Azure Web Apps, or hybrid setups with on-prem validation.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• An AWS account with CodePipeline, CodeBuild, and optionally Lambda/IAM roles.
• A Jaws project with steps, environments (e.g., AWS-Staging, Azure-Prod), and a package store for artifacts.
• AWS CLI or console access for setup.
• Familiarity with YAML/JSON for pipeline definitions.

Configure your Jaws project here, scoping variables for multi-cloud targets.

Step 1: Create a Service Account in Jaws Deploy

For secure API invocation from AWS:

1. In Jaws, go to Settings > Service Accounts.
2. Add a new account (e.g., "AWSCodePipelineDeployer") with permissions for release creation and deployment on relevant projects/workspaces.
3. Copy the service account ID and API key.

In AWS:

• Use SSM Parameter Store or Secrets Manager to store credentials securely.
• Create an IAM role for CodeBuild/Lambda with access to these secrets.

See the Service Accounts and Automation Guide.

Step 2: Choose Your Integration Method

• REST API: Call endpoints directly via curl in CodeBuild scripts. Simple for bash-based actions.
• PowerShell SDK: Use in CodeBuild (Windows runtime) or Lambda for wrapped commands like Invoke-ReleaseAndDeployProject.
• Lambda Invoke: For complex logic, create a Lambda function to handle API calls.

We'll use CodeBuild with REST for the example, ideal for hybrid handoffs.

Step 3: Set Up Your AWS CodePipeline

Create a pipeline in AWS CodePipeline (console or CDK/Terraform). Add a "Deploy" stage after Build that uses CodeBuild to call Jaws API.

Example Pipeline Setup (via AWS Console or YAML)

1. Source Stage: From CodeCommit/S3/GitHub.
2. Build Stage: Use CodeBuild to compile (e.g., .NET app) and zip artifacts.
3. Deploy Stage: Add a CodeBuild action with a buildspec.yml that uploads packages and triggers Jaws.

Sample buildspec.yml for Deploy Stage (CodeBuild Project)

version: 0.2

phases:
  install:
    runtime-versions:
      dotnet: 8.0  # Or your runtime
  pre_build:
    commands:
      - echo Fetching credentials from SSM...
      - JAWS_API_LOGIN=$(aws ssm get-parameter --name "/jaws/login" --query "Parameter.Value" --output text)
      - JAWS_API_PASSWORD=$(aws ssm get-parameter --name "/jaws/password" --with-decryption --query "Parameter.Value" --output text)
  build:
    commands:
      # Assume artifact (app.zip) from previous stage; upload to Jaws package store
      - auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
      - curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
          -H "Authorization: Basic $auth" \\
          -F "file=@app.zip" \\
          -F "packageId=my-app" \\
          -F "version=$CODEPIPELINE_BUILD_ID.0.0"  # Use pipeline ID for SemVer
      # Create release
      - release_response=$(curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
          -H "Authorization: Basic $auth" \\
          -H "Content-Type: application/json" \\
          -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$CODEPIPELINE_BUILD_ID.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"$CODEPIPELINE_BUILD_ID.0.0\\"}}")
      # Extract releaseId (using jq; install if needed: apt install jq)
      - release_id=$(echo $release_response | jq -r '.releaseId')
      # Deploy to Staging (or multi-cloud env)
      - curl -X POST "<https://app.jawsdeploy.net/api/release/deploy>" \\
          -H "Authorization: Basic $auth" \\
          -H "Content-Type: application/json" \\
          -d "{\\"releaseId\\": \\"$release_id\\", \\"environments\\": [\\"Staging\\"]}"
  post_build:
    commands:
      - echo Deployment triggered to Jaws for hybrid/multi-cloud rollout.

Key Explanations

• Pre-Build: Retrieves secrets from SSM.
• Build: Uploads package, creates release, extracts ID, and deploys. Adapt for multi-cloud by scoping Jaws environments to Azure/on-prem.
• Versioning: Uses pipeline ID for traceability.
• IAM: Ensure CodeBuild role has ssm:GetParameter and internet access.

For PowerShell SDK in CodeBuild (Windows runtime):Replace commands with pwsh scripts to import SDK and call Invoke-ReleaseAndDeployProject.

For Lambda: Create a function invoked by CodePipeline, passing artifacts and calling API.

Reference the API Reference for endpoints.

Step 4: Test and Monitor

1. Trigger the pipeline via commit or manual start.
2. Check CodePipeline/CodeBuild logs.
3. In Jaws, monitor the Deployments tab for cross-cloud progress.

View AWS-handed deploys here, with statuses across hybrid environments.

Set __debug to true in Jaws for detailed logs.

Best Practices

• Secure Secrets: Use SSM/Secrets Manager; least-privilege IAM roles.
• Multi-Cloud Scoping: Define Jaws environments/tags for AWS/Azure separation; use variables for provider-specific configs.
• Approvals: Add manual approval actions in CodePipeline before Jaws handover.
• Error Handling: Use try-catch in scripts; notify via SNS on failures.
• Scaling: Use CodePipeline branches for env-specific deploys (e.g., dev to AWS, prod to Azure).
• Updates: Monitor AWS quotas; test hybrid flows end-to-end.

Troubleshooting Common Issues

• Auth Failures: Verify SSM access and Base64 encoding.
• Package Errors: Ensure artifact paths from previous stages.
• API Timeouts: Increase CodeBuild timeouts or optimize calls.
• Multi-Cloud Gaps: Check Jaws cloud accounts for Azure integration.
• Logs: Use Jaws' UI for deployment details; CloudWatch for AWS.

Consult AWS docs or our API Reference.

Conclusion

Integrating AWS CodePipeline with Jaws Deploy enables robust hybrid/multi-cloud deploys, where AWS builds feed into Jaws' orchestration for seamless cross-provider rollouts.

For more, see the CI/CD Integration Guide. Build your pipeline today! New to Jaws? Try the Getting Started guide.

Integrating Google Cloud Build

Google Cloud Build (GCB) is Google's serverless platform for automating builds, tests, and artifact creation, particularly excelling in containerized workflows like Docker image builds and pushes to Container Registry or Artifact Registry. While GCB handles CI effectively, extending to complex CD across hybrid environments can involve custom steps. Jaws Deploy integrates with GCB to manage releases and deployments, leveraging API triggers for seamless handoffs—ideal for triggering Jaws releases post-build in containerized setups.

In this integration, GCB focuses on containerized builds (e.g., building and pushing Docker images), while Jaws Deploy orchestrates the CD phase via API triggers, handling multi-environment rollouts, lifecycles, and variable scoping. This enables efficient container deployments to Kubernetes, VMs, or multi-cloud targets.

This guide covers prerequisites, setup, an example workflow, and tips, with emphasis on containerized processes and API-driven triggers.

Why Integrate Google Cloud Build with Jaws Deploy?

• Containerized Focus: GCB's strength in building/pushing containers (e.g., Docker) pairs with Jaws' deployment steps for container orchestration, like running scripts to deploy images to GKE or hybrid clusters.
• API Triggers for Releases: Use GCB's post-build triggers or steps to call Jaws' REST API, automating release creation and deployment—perfect for event-driven workflows.
• Hybrid Scalability: Extend GCB's GCP-centric builds to multi-cloud deploys via Jaws, with lifecycles promoting containers across environments.
• Streamlined Automation: Reduce custom YAML in GCB; let Jaws handle CD logic, monitoring, and rollbacks.

This setup is suited for microservices or apps where GCB builds containers, and Jaws triggers releases for deployment to diverse targets.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup).
• A Google Cloud project with Cloud Build enabled and a repository (e.g., GitHub connected via triggers).
• A Jaws project with container-focused steps (e.g., "Run Script" for kubectl apply), environments, and a package store if using non-container artifacts.
• GCP service account with Cloud Build Editor role for API calls.
• Familiarity with cloudbuild.yaml for GCB configs.

Configure your Jaws project here, adding steps for container pulls/deploys.

Step 1: Create a Service Account in Jaws Deploy

For secure API triggers from GCB:

1. In Jaws, go to Settings > Service Accounts.
2. Create an account (e.g., "GCBDeployer") with permissions for release creation and deployment on specific projects/workspaces.
3. Copy the service account ID and API key.

In GCP:

• Store keys in Secret Manager (e.g., secrets "jaws-login" and "jaws-password").
• Grant your Cloud Build service account access to Secret Manager (roles/secretmanager.secretAccessor).

See the Service Accounts and Automation Guide.

Step 2: Choose Your Integration Method

• REST API: Call endpoints via curl in GCB steps for direct triggers. Great for simple container handoffs.
• PowerShell SDK: Use in GCB (with Windows machine type or pwsh installation) for wrapped commands like Invoke-ReleaseAndDeployProject.

Emphasize REST for container workflows, as it's lightweight and integrates easily with Docker-based builds.

Step 3: Set Up Your Google Cloud Build Pipeline

Create a cloudbuild.yaml in your repo. This example builds a Docker container, pushes to Artifact Registry, then triggers a Jaws release via API for deployment.

Example cloudbuild.yaml

steps:
  # Build and push container
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$BUILD_ID', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$BUILD_ID']

  # Trigger Jaws release via REST API (fetch secrets and call)
  - name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        # Fetch secrets
        JAWS_API_LOGIN=$(gcloud secrets versions access latest --secret="jaws-login")
        JAWS_API_PASSWORD=$(gcloud secrets versions access latest --secret="jaws-password")

        # Create release (pass container tag as variable or note)
        auth=$(echo -n $JAWS_API_LOGIN:$JAWS_API_PASSWORD | base64)
        curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
          -H "Authorization: Basic $auth" \\
          -H "Content-Type: application/json" \\
          -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"$BUILD_ID.0.0\\", \\"notes\\": \\"Container: us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$BUILD_ID\\"}"

        # Deploy release (extract releaseId from response; use jq)
        apt-get update && apt-get install -y jq
        release_response=$(curl ... )  # Repeat create call with --output -
        release_id=$(echo $release_response | jq -r '.releaseId')
        curl -X POST "<https://app.jawsdeploy.net/api/release/deploy>" \\
          -H "Authorization: Basic $auth" \\
          -H "Content-Type: application/json" \\
          -d "{\\"releaseId\\": \\"$release_id\\", \\"environments\\": [\\"Staging\\"]}"

options:
  logging: CLOUD_LOGGING_ONLY

Key Explanations

• Container Build: Builds and pushes Docker image—emphasizing GCB's container workflow strengths.
• API Trigger: Fetches secrets, creates a Jaws release (noting container tag for pull in steps), and deploys. Use Jaws steps to pull/deploy the image (e.g., via script: docker pull $#{VAR.containerTag}).
• Versioning: Uses GCB's $BUILD_ID for SemVer.
• Triggers: Set up GCB triggers on push/tag for automated runs.

For PowerShell SDK: Use a Windows machine type (machineType: E2_HIGHCPU_8) and pwsh commands to import/call SDK.

Reference the API Reference for endpoints.

Step 4: Test and Monitor

1. Push code to trigger GCB.
2. View build logs in GCP console.
3. In Jaws, check Deployments for container rollout progress.

Monitor GCB-triggered releases here, verifying container deploys.

Set __debug to true in Jaws for detailed logs.

Best Practices

• Container Security: Use GCB's vulnerability scanning; pass secure tags to Jaws variables.
• API Triggers: Use webhooks in GCB for async Jaws calls if needed.
• Multi-Cloud: Scope Jaws environments to GCP/Azure; use variables for registry URLs.
• Error Handling: Add retries in scripts; notify via Pub/Sub.
• Optimization: Cache layers in GCB for faster container builds.
• Compliance: Log API calls for audits in multi-cloud setups.

Troubleshooting Common Issues

• Auth Errors: Check Secret Manager access and Base64.
• Container Push Fails: Verify registry permissions.
• API Response Parsing: Install jq reliably.
• Timeouts: Increase GCB timeouts for large containers.
• Logs: Use Jaws' UI for deployment insights; Stackdriver for GCB.

Consult GCP docs or our API Reference.

Conclusion

Integrating Google Cloud Build with Jaws Deploy leverages GCB's containerized workflows and API triggers for efficient, multi-cloud releases—perfect for hybrid environments.

For more, see the CI/CD Integration Guide. Set up your build today! New to Jaws? Start with Getting Started.

Integrating Bamboo

Bamboo is Atlassian's on-premises CI/CD server, renowned for its robust build plans, agent management, and seamless integration with Jira for enterprise-grade workflows. It's a staple in large organizations handling complex builds and tests, but as teams scale, the deployment side can become burdensome with custom scripts and maintenance. Jaws Deploy integrates with Bamboo to offload the continuous deployment (CD) orchestration, managing releases, lifecycles, variables, and multi-environment rollouts—making it an ideal partner for enterprises migrating from heavy on-prem tools to a more agile, cost-effective solution.

This integration allows Bamboo to focus on CI (e.g., building artifacts), while Jaws handles CD via API calls or SDK. For enterprise setups, this is particularly useful during migrations: Jaws' simplicity reduces operational overhead, lowers licensing costs compared to Bamboo's per-agent model, and preserves Jira ties through shared Atlassian ecosystems. Teams can gradually shift deployment logic to Jaws without disrupting existing Bamboo plans, enabling hybrid operations during transition.

This guide covers prerequisites, setup, an example configuration, and migration-focused tips.

Why Integrate Bamboo with Jaws Deploy for Enterprise Migrations?

• Migration Efficiency: Enterprises often outgrow Bamboo's deployment capabilities, facing scalability issues or high maintenance. Jaws eases the shift by importing similar concepts (e.g., plans to projects, variables to scoped vars), allowing phased migrations—start with new projects in Jaws while running legacy in Bamboo.
• Cost and Simplicity: Jaws' transparent pricing (free Starter plan, affordable Professional) contrasts with Bamboo's agent-based costs. Migrate to reduce infra management, especially in hybrid/on-prem setups.
• Enterprise Features: Retain Jira integration for issue tracking; Jaws adds RBAC, audit logs, and self-hosting (Jaws Stack) for compliance-heavy environments.
• Hybrid Support: Deploy from Bamboo-built artifacts to multi-cloud/on-prem targets via Jaws, smoothing transitions to cloud-native.
• Reusability Boost: Move reusable scripts to Jaws' modules/templates, cutting duplication across enterprise teams.

This setup benefits large orgs migrating for agility, like moving from monoliths to microservices.

Prerequisites

• A Jaws Deploy account (sign up at https://app.jawsdeploy.net/signup; consider self-hosted for enterprises).
• Bamboo Server/Data Center (version 7+ recommended) with admin access.
• A Jaws project mirroring your Bamboo plan, with steps, environments (e.g., Staging, Production), and a package store.
• Bamboo agents with curl (for REST) or PowerShell (for SDK).
• Optional: Jira integration for linking builds/deploys.

Mirror your Bamboo plans here as Jaws projects for smooth migration.

Step 1: Create a Service Account in Jaws Deploy

Service accounts enable secure, non-user API access—crucial for enterprise automation.

1. In Jaws, go to Settings > Service Accounts.
2. Create an account (e.g., "BambooMigrator") with scoped permissions (e.g., deploy to specific workspaces for compliance).
3. Copy the ID and API key.

In Bamboo:

• Go to Administration > Overview > Security > Global variables (or plan variables).
• Add secured vars: JAWS_API_LOGIN = ID, JAWS_API_PASSWORD = key (encrypt if sensitive).

See the Service Accounts and Automation Guide for enterprise RBAC tips.

Step 2: Choose Your Integration Method

• REST API: Use curl in Bamboo script tasks for HTTP calls. Simple for cross-platform agents.
• PowerShell SDK: Ideal for Windows agents; import and call high-level functions like Invoke-ReleaseAndDeployProject.

Focus on REST for migrations, as it's quick to prototype without dependencies.

Step 3: Set Up the Integration in Bamboo

In Bamboo, add a script task to your deployment plan's job (or build plan's final stage) to call Jaws API. This example assumes a .NET build producing a .zip, uploaded then deployed via REST.

Example Bamboo Configuration

1. In your Bamboo plan, add a stage/job for "Handover to Jaws" after artifact creation.
2. Add a Script task (inline or file-based) with bash/PowerShell.

Sample Inline Script Task (Bash for REST)

# Fetch vars (Bamboo injects as env)
auth=$(echo -n ${bamboo_JAWS_API_LOGIN}:${bamboo_JAWS_API_PASSWORD} | base64)

# Upload artifact to Jaws package store (assume artifact shared as app.zip)
curl -X POST "<https://app.jawsdeploy.net/api/packagestore/package>" \\
  -H "Authorization: Basic $auth" \\
  -F "file=@app.zip" \\
  -F "packageId=my-app" \\
  -F "version=${bamboo.buildNumber}.0.0"  # Use Bamboo build number

# Create release
curl -X POST "<https://app.jawsdeploy.net/api/release>" \\
  -H "Authorization: Basic $auth" \\
  -H "Content-Type: application/json" \\
  -d "{\\"projectId\\": \\"your-project-id\\", \\"version\\": \\"${bamboo.buildNumber}.0.0\\", \\"packageVersions\\": {\\"my-app\\": \\"${bamboo.buildNumber}.0.0\\"}}"

# Deploy (extract releaseId from prior response; use jq if installed)
# For simplicity, chain or parse in script

For PowerShell SDK (on Windows agents):

# Download/import SDK
Invoke-WebRequest -Uri "<https://github.com/JawsDeploy/powershell-sdk/raw/main/JawsDeploySdk.psm1>" -OutFile "JawsDeploySdk.psm1"
Import-Module ./JawsDeploySdk.psm1

$env:JAWS_API_LOGIN = "${bamboo_JAWS_API_LOGIN}"
$env:JAWS_API_PASSWORD = "${bamboo_JAWS_API_PASSWORD}"

Invoke-ReleaseAndDeployProject -projectId "your-project-id" -version "${bamboo.buildNumber}.0.0" -environmentName "Staging"

During migration, start with a parallel Bamboo-Jaws plan: Run legacy deploys in Bamboo while testing new in Jaws.

Reference the API Reference for endpoints.

Step 4: Test and Monitor

1. Trigger a Bamboo build/deployment.
2. Check task logs in Bamboo.
3. In Jaws, view the Deployments tab for progress—use this for enterprise auditing.

Track migrated deploys here, comparing to Bamboo history.

For debugging, set __debug to true in Jaws variables during migration testing.

Best Practices for Enterprise Migrations

• Phased Approach: Migrate one plan at a time; use Jaws' import tools or guides for Bamboo-like structures.
• Jira Alignment: Link Jaws deploys to Jira issues via notes/API for traceability.
• Security: Scope service accounts to workspaces; integrate with enterprise SSO (OIDC in Jaws Stack).
• Scalability: Use Bamboo agents for builds, Jaws for parallel deploys—reduces agent needs over time.
• Cost Tracking: Monitor savings post-migration; Jaws' model avoids Bamboo's per-agent fees.
• Rollback: Leverage Jaws' release history for easy reversions during transition.

Troubleshooting Common Issues

• Auth Failures: Verify Bamboo var injection and Base64.
• Artifact Issues: Ensure shared artifacts accessible in tasks.
• SDK Errors: Check agent PowerShell version; fallback to REST.
• Migration Gaps: Compare logs; use Jaws' migration guide for concept mapping.
• Enterprise Scale: For large deploys, increase Bamboo timeouts.

Conclusion

Integrating Bamboo with Jaws Deploy is a strategic move for enterprises migrating to modern CD, offering simplicity, cost savings, and hybrid flexibility while maintaining Atlassian integrations.

For tailored migration advice, see Migrating from Octopus Deploy (adaptable to Bamboo). Explore the CI/CD Integration Guide. Start your migration—contact us for enterprise support! New to Jaws? Begin with Getting Started.

Projects and Deployment Logic

In Jaws Deploy, projects serve as the central hub for defining and managing your deployment workflows. They're designed to encapsulate the logic needed to deploy a specific application, service, or component—whether it's a web app, database schema, or background worker. This keeps things organized, reusable, and scalable, especially as your team grows or your infrastructure evolves.

Think of a project as a blueprint: It outlines the steps to execute, variables to customize behavior, and rules for progressing through environments. Unlike traditional CI tools where deployment logic is scattered in scripts, Jaws centralizes it in an intuitive UI with API support for automation. This article covers how to set up projects, build deployment logic with steps, leverage templates and modules for reuse, and handle configurations—drawing from real-world enterprise needs like migrations from tools like Bamboo or Octopus.

Understanding Projects

A project in Jaws Deploy represents a deployable unit, such as "Web API" or "Database Migrations." Each project includes:

• Deployment Steps: The sequence of actions to perform during a release.
• Variables: Dynamic values scoped to environments, machines, or tags for customization.
• Releases and Deployments: Versioned snapshots deployed to environments via lifecycles.
• Channels: Optional paths for variant deployments (e.g., feature branches).

Projects are grouped within workspaces for team isolation, and you can tag them for quick filtering. This structure is lightweight yet powerful, avoiding the bloat of heavier tools while supporting enterprise-scale operations.

This lists all projects with IDs, descriptions, and quick actions like creating releases or viewing deployments. Use the "Add new project" button to start.

Creating and Managing Projects

Getting a project up and running is straightforward:

1. Add a New Project: From the Projects page, click "Add new project." Provide a name (e.g., "Customer Portal"), description, and optional tags for categorization.
2. Define Basics: Set up environments (via the Environments menu) and link them if needed. Assign lifecycles to control progression (e.g., require approvals before Production).
3. Organize with Workspaces: For enterprises, use multiple workspaces to separate teams or business units—migrate by importing projects one-by-one.
4. Manage Permissions: Use service accounts or RBAC to control access, ideal during migrations where legacy Bamboo users need read-only views.

During enterprise migrations, start by replicating a Bamboo plan in Jaws: Map tasks to steps, variables to scoped vars, and use the API to trigger from Bamboo for hybrid testing.

Tip: For large orgs, tag projects (e.g., "app-web", "region-eu") to filter dashboards and target deploys efficiently.

Defining Deployment Logic with Steps

The core of a project is its steps—the ordered actions that run during a deployment. Steps can be parallel or sequential, scoped to specific environments or machines, and customized with conditions.

Adding and Editing Steps

• From the project overview, go to the "Steps" tab.
• Click "Add step" and choose from built-in types like "Deploy Package" (for .zip/.tar.gz uploads), "Run Script" (PowerShell by default, with bash/Python support in 2025), or "Install Service."
• Edit steps via the UI: Set names, conditions (e.g., run only if variable #{VAR.isProd} is true), and parallelism (e.g., deploy to 5 machines at once).
• Order steps with drag-and-drop; add outputs to pass data between them (e.g., capture a generated ID).

Steps execute on targets (machines or cloud apps), pulling packages from the store or external feeds. For containerized workflows, use "Run Script" to pull/deploy Docker images.

Browse and add reusable templates here, like "Install SSL Certificate" or "Run PowerShell Script."

Using Built-in and Custom Step Templates

Step templates promote reuse across projects—perfect for enterprises standardizing processes.

• Built-in Templates: Include actions like "Azure Key Vault" integration, "Deploy Package," or "Install Windows Service." These come with pre-defined PowerShell logic and UI fields for inputs.
• Custom Templates: Create your own via the Step Templates menu. Define JSON for UI (e.g., dropdowns for params), and embed PowerShell code. Export/import for sharing between workspaces.
• During migrations, convert Bamboo tasks to templates: E.g., a Bamboo "SSH Task" becomes a Jaws "Run Script" template.

Example: Add a "Deploy Package" step, select your package ID/version from the store, and scope to "Production" for env-specific paths.

Code Reuse with Script Modules

For advanced logic, script modules let you share PowerShell functions (.psm1 files) across steps and projects—reducing duplication in enterprises with standardized scripts.

• Upload modules via the Script Modules menu or API.
• Reference in steps: Import-Module MyUtils; Invoke-MyFunction -Param #{VAR.myVar}.
• Benefits for migrations: Extract common Bamboo scripts (e.g., config checks) into modules, then phase out Bamboo dependencies.
• Future-proof: 2025 updates add bash/Python module support for diverse teams.

Not shown in provided images, but similar to Step Templates—list modules with edit/export options.

Configuration Transforms

Jaws supports transforming configs during deployment, ensuring env-specific settings without manual edits.

• JSON/XML Transforms: In a "Deploy Package" step, enable transforms—Jaws applies rules like replacing placeholders with variables (e.g., #{VAR.connectionString} in appsettings.json).
• Scoped Overrides: Use variables for dynamic transforms, scoped to environments (e.g., dev uses local DB, prod uses Azure).
• Enterprise Tip: During Bamboo migrations, map artifact transforms to Jaws steps—test with debug mode (__debug = true) to verify resolutions.

Best Practices for Enterprise Setups

• Start Small: Migrate a pilot project from Bamboo to Jaws, using API triggers for hybrid runs.
• Audit and Compliance: Jaws' deployment history and logs provide traceability; integrate with Jira for tickets.
• Performance: For large deploys, use tags to target subsets; monitor durations in dashboards.
• Migration Path: Use Jaws' self-hosted Stack for on-prem parity with Bamboo; follow our migration guides (adapt for Bamboo).

Conclusion

Projects and deployment logic in Jaws Deploy empower you to build reliable, reusable workflows with minimal fuss. Whether starting fresh or migrating enterprise setups from tools like Bamboo, the focus on steps, templates, and modules streamlines CD while cutting costs.

Ready to build? Create your first project and explore Variables for deeper customization. For enterprise migrations, check How Jaws Compares to Octopus Deploy or Contact Us for tailored advice.

‍

Project Steps Explained

Project steps in Jaws Deploy are the core building blocks of your deployment workflows, defining the specific actions and logic that get executed when a release is deployed to targets. They encapsulate everything from simple script runs to complex operations like package deployments or service installations, making your projects flexible and powerful. Steps are what turn your high-level plans into actionable tasks, running on machines or cloud targets with support for scoping, conditions, and reusability.

Whether you're building a basic web app deployment or orchestrating enterprise-scale microservices, understanding steps helps you create efficient, maintainable logic. In migrations from tools like Bamboo or Octopus, steps map closely to tasks or stages, allowing you to replicate and optimize existing workflows. As of September 22, 2025, steps now include enhanced support for bash and Python alongside PowerShell, broadening language options.

This article explains what steps are, types available, how to define and order them, reusability via templates and modules, scoping/conditions, and best practices.

What Are Project Steps?

Steps are individual, configurable units within a project that contain the deployment logic to be executed. They specify actions like fetching secrets, installing services, or running custom code, and are executed in sequence or parallel during a deployment.

• Purpose: Steps focus on the "how" of deployment—e.g., deploying a package and adjusting configs—while projects group them into recipes.
• Execution: Steps run on assigned targets (machines or cloud apps), pulling artifacts from feeds and resolving variables at runtime.
• Flexibility: They can be scoped to specific environments, machines, or tags, ensuring logic only applies where needed.

In enterprise contexts, steps reduce script duplication from tools like Bamboo by centralizing reusable actions.

Types of Steps

Steps are based on templates, which provide pre-defined logic. Common types include:

• Run Script: The simplest and most versatile—execute custom PowerShell (default), with bash/Python support for cross-platform needs. Ideal for arbitrary tasks like database migrations or config tweaks.
• Deploy Package: Pull and extract packages (.zip, .tar.gz, .nupkg) from feeds, apply transforms (JSON/XML), and install to paths.
• Install Windows Service: Set up services with parameters like start mode or credentials.
• Azure-Specific: E.g., Azure Key Vault for secrets, or actions tied to Azure Web Apps.
• Certificate Management: Apply SSL certs from Windows Cert Store to IIS bindings, or install into certificate stores.
• Custom: Any logic encapsulated in templates or modules.

All steps are machine-oriented and PowerShell-based by default, but customizable.

For migrations, map Bamboo tasks (e.g., SSH/Command) to "Run Script" steps for quick adaptation.

Defining and Ordering Steps

1. Add a Step: In your project > Steps tab > Add step. Select a template (e.g., "Run a PowerShell script") and configure properties like name, script body, or parameters.
2. Ordering: Steps execute in the order listed—use drag-and-drop to rearrange. Sequential by default, but enable parallelism for independent steps.
3. Configuration: Set inputs via UI fields (from templates), reference variables (#{VAR.name}), or outputs from prior steps.

Example: A web app project might have:

1. Fetch secrets from Azure Key Vault.
2. Deploy package to path.
3. Run script to restart IIS.

In large setups, define steps to minimize dependencies for faster deploys.

Reusability with Step Templates and Script Modules

Steps promote reuse to avoid duplication across projects.

Step Templates

• What They Are: Reusable blueprints for steps, shared within workspaces.
• Built-in Templates: Include "Run Script," "Deploy Package," "Install Windows Service," "Azure Key Vault," "Apply SSL Cert to IIS," etc.—all PowerShell-based with UI for params.
• Custom Templates: Create in Step Templates menu; define JSON for UI (e.g., fields for inputs) and embed PowerShell code. Export/import for sharing.
• Usage: Select a template when adding a step; it populates the logic.

For enterprises, build custom templates for standardized processes (e.g., compliance checks), easing migrations by replicating Bamboo task libraries.

This lists templates with names, supported modes (Machine), languages (PowerShell), and actions like Edit/Export/Delete. Use "Add new step template" for customs.

Script Modules

• What They Are: PowerShell modules (.psm1 files) with utility functions/commandlets for reuse in steps.
• Setup: Upload via Script Modules menu or API; enable per-project in the project's Script Modules tab (toggle "Import").
• Referencing: In a step's script: Import-Module MyModule; Invoke-MyFunction -Param #{VAR.value}.
• Benefits: Share code across projects/steps; modules download once per machine and import on run.
• Examples: A module with functions for logging, config parsing, or API calls—reduces boilerplate.

During Bamboo migrations, extract common scripts into modules for centralized maintenance.

Scoping and Conditions for Steps

• Scoping: Limit steps to specific environments, machines, or cloud targets—e.g., run a Prod-only compliance check. Use tags for dynamic groups (e.g., execute on "region-us" machines).
• Conditions: Skip steps based on config (e.g., variable checks like if #{VAR.isEnabled} eq true). Add in step properties for runtime decisions.

This ensures precision, e.g., env-specific transforms or OS-targeted scripts.

Best Practices

• Keep It Simple: Start with built-in templates; add customs only for unique needs.
• Reuse Aggressively: Leverage templates/modules to avoid copy-paste—boosts maintainability in enterprises.
• Test Incrementally: Add steps one-by-one; use debug mode (__debug = true) to verify logic.
• Migration from Bamboo: Map tasks 1:1 to steps; automate via API for hybrid runs.
• Performance: Parallelize independent steps; monitor durations in dashboards.
• Security: Scope sensitive steps to trusted targets; audit via logs.

Conclusion

Project steps in Jaws Deploy empower you to build tailored, reusable deployment logic, streamlining workflows and easing enterprise migrations from tools like Bamboo.

For more, see Code Reuse with Script Modules or Step Templates. Create your first step—dive into a project now! New to Jaws? Start with Getting Started.

Step Templates in Action

Step templates in Jaws Deploy are reusable blueprints for common deployment actions, allowing you to standardize and share logic across projects without duplication. They turn frequently used tasks—like installing certificates, deploying packages, or running scripts—into plug-and-play components, complete with customizable UI fields for inputs. This "in action" guide shows how to create, apply, and optimize templates, with real-world examples to demonstrate their power in building efficient workflows.

Templates are especially valuable in enterprise settings, where teams need consistency across multiple projects or during migrations from tools like Bamboo. By encapsulating PowerShell-based logic (with bash/Python support coming in late 2025), templates reduce errors and speed up onboarding. Let's put them into action.

Getting Started with Step Templates

Step templates are managed globally in your workspace but applied per-project. They define the "what" (action) and "how" (code), with a JSON schema for the configuration UI.

Viewing and Adding Templates

1. Navigate to the left menu > Step Templates.
2. Browse built-in templates like "Run Script," "Deploy Package," "Install Windows Service," "Azure Key Vault," or "Apply SSL Cert to IIS Binding."
3. Add a new one: Click "Add new step template," name it (e.g., "Database Backup"), select run mode (Machine), language (PowerShell), and define the script body.
4. Customize UI: Use JSON to add fields (e.g., text inputs for params like backup path).

Built-in templates provide ready-to-use actions; customs extend them for your needs.

This lists templates with names, supported modes, languages, and IDs. Edit or export built-ins as starting points for customs.

Creating a Custom Step Template

Let's create a template for backing up a SQL database—useful in database projects.

1. Basic Setup: Name: "SQL Database Backup," Mode: Machine, Language: PowerShell.
2. Script Body: Add PowerShell code:

param (
    [string]$ServerName = "#{VAR.ServerName}",
    [string]$DatabaseName = "#{VAR.DatabaseName}",
    [string]$BackupPath = "#{VAR.BackupPath}"
)

# Import SQL module if needed
Import-Module SqlServer -ErrorAction Stop

# Backup command
Backup-SqlDatabase -ServerInstance $ServerName -Database $DatabaseName -BackupFile "$BackupPath\\$DatabaseName.bak"
Write-Host "Backup completed to $BackupPath\\$DatabaseName.bak"

{
  "fields": [
    {"name": "ServerName", "type": "text", "label": "SQL Server Name"},
    {"name": "DatabaseName", "type": "text", "label": "Database Name"},
    {"name": "BackupPath", "type": "text", "label": "Backup Directory"}
  ]
}

In action: This template ensures backups are consistent, with vars for env-specific paths (e.g., Prod backups to secure storage).

For migrations, convert Bamboo script tasks to templates—e.g., a "Deploy WAR" Bamboo task becomes a Jaws template for Tomcat installs.

Applying Step Templates in Projects

Once created, templates become available when adding steps.

1. In a project > Steps > Add step > Select your template (e.g., "SQL Database Backup").
2. Configure via the generated UI: Enter values or reference vars (e.g., #{VAR.DbServer}).
3. Scope/Conditions: Limit to environments (e.g., run only in "Production") or add conditions (e.g., if #{VAR.BackupEnabled} eq true).

Example Workflow: In a "[070] Database" project:

• Step 1: "Azure Key Vault" template to fetch DB creds.
• Step 2: Custom "SQL Database Backup" template.
• Step 3: "Run Script" to notify on completion.

In action: Deploying a release runs the backup on database machines tagged "db-tier," outputting the file path for auditing.

While adding steps isn't shown, this lists projects like [070] Database where templates are applied.

Reusing and Sharing Templates

• Workspace Sharing: Templates are available across projects in the same workspace—ideal for team standards.
• Export/Import: Download as JSON; import to other workspaces or share with teams.
• Versioning: Update templates; existing steps in projects retain the old version until refreshed.

In enterprise action: Create a "Compliance Check" template with scripts for security scans; share via export during Bamboo migrations to standardize post-deploy validations.

Advanced Features

• Output Variables: Templates can set outputs (e.g., Set-JawsOutputValue -Name "BackupFile" -Value $backupPath) for use in later steps.
• Conditions and Scoping: Apply at template level or per-step for dynamic behavior.
• Debugging: Test with __debug = true to log resolved params and script outputs.
• Future Enhancements: 2025 adds bash/Python templates for non-PowerShell logic.

Best Practices

• Standardize: Build templates for common tasks to enforce best practices.
• Parametrize: Use UI fields for flexibility; default to vars for automation.
• Version Control: Name templates with versions (e.g., "Backup v1.1") if updating logic.
• Migration from Bamboo: Extract Bamboo task scripts into templates; automate via API for hybrid deploys.
• Performance: Keep scripts efficient; monitor run times in deployments.
• Security: Avoid hardcoding secrets; use scoped vars.

Conclusion

Step templates in action transform repetitive tasks into efficient, shareable components, accelerating development and easing enterprise migrations from tools like Bamboo.

For hands-on, try Code Reuse with Script Modules. Create your first template—go to Step Templates! New to Jaws? Start with Getting Started.

Custom Script Modules in Jaws Deploy

Custom script modules in Jaws Deploy are reusable PowerShell files (.psm1) that contain functions, cmdlets, or utilities you can import into project steps for shared logic. They enable code reuse beyond individual steps, allowing you to build libraries of common operations—like logging, config parsing, or API wrappers—that can be referenced anywhere in your workflows. This is a step up from inline scripts, promoting modularity and maintainability without external dependencies.

For enterprise teams, custom modules are invaluable during migrations from tools like Bamboo, where you can extract scattered scripts into centralized modules for easier management and versioning. As of September 23, 2025, modules remain PowerShell-focused, but upcoming bash and Python support will expand options for diverse environments.

This article covers creating, uploading, using, and optimizing custom script modules, with examples to get you started.

What Are Custom Script Modules?

Script modules are .psm1 files uploaded to Jaws, containing exportable PowerShell code. Once enabled in a project, they're downloaded to targets during deployment and imported in steps.

• Key Benefits: Share code across steps/projects; avoid duplication; version modules independently.
• How They Work: Modules are workspace-level but enabled per-project. On deploy, agents cache them; steps use Import-Module MyModule to access functions.
• Vs. Step Templates: Templates define full steps with UI; modules are code libraries for use within steps—combine them for powerful reusability.

In migrations, convert Bamboo shared scripts to modules; test in Jaws for seamless integration.

Creating a Custom Script Module

Build modules in PowerShell ISE or VS Code, then upload.

1. Write the Code: Create a .psm1 file with functions. Example Utils.psm1 for logging:

function Write-Log {
    param (
        [string]$Message,
        [string]$Level = "Info"
    )
    Write-Host "[$Level] $Message"
    # Add file logging if needed
}

function Get-ConfigValue {
    param (
        [string]$Key
    )
    # Logic to fetch from file or var
    return $Jaws.Parameters[$Key].Value
}

Export-ModuleMember -Function Write-Log, Get-ConfigValue

For enterprises, include error handling and params for flexibility.

Uploading and Managing Modules

1. Access the Menu: Left menu > Script Modules > Add new script module.
2. Fill Details: Name (e.g., "Utils"), Description, Language (powershell), Script body (paste or upload .psm1 content).
3. Save: Jaws validates and adds to the list.
4. Manage: Edit, delete, or view usage. No versioning yet—use names like "Utils v1.1" for changes.

The page shows "No script modules found" initially; after adding, list with names, descriptions, and edit actions.

For migrations, upload Bamboo-equivalent scripts in batch via API if needed.

Enabling and Using in Projects

1. Enable per Project: In project > Script Modules tab > Toggle "Import" for the module.
2. Reference in Steps: In a "Run Script" step:

Import-Module Utils
$value = Get-ConfigValue -Key "MyKey"
Write-Log -Message "Fetched value: $value" -Level "Debug"

Example Action: In a deployment, use the module to log steps and fetch env-specific configs, ensuring consistency.

Real-World Examples

• Logging Module: As above—for auditing in enterprise deploys.
• Config Transformer: Functions to parse/modify JSON/XML based on vars.
• API Caller: Wrapper for REST calls to external services, with auth from Azure Key Vault.
• Migration Use: A module from Bamboo scripts for file copies; import in Jaws steps for hybrid testing.

In action: A project with multiple steps imports the module, calling functions to handle common tasks—reduces code bloat.

Best Practices

• Modular Design: Export only needed functions; use params for flexibility.
• Versioning: Append versions to names; update projects manually on changes.
• Security: Avoid sensitive data in modules; use vars/secrets instead.
• Migration from Bamboo: Extract shared scripts; test imports in dev projects.
• Performance: Keep modules lightweight; profile functions for slow ops.
• Debugging: Use Write-Host for logs; enable __debug to trace imports.

Troubleshooting Common Issues

• Import Failures: Check module enabled in project; verify path/exports.
• Missing Functions: Ensure Export-ModuleMember used; test locally.
• Cross-OS Issues: PowerShell 7+ for Linux compatibility.
• Enterprise Scale: For large teams, share via exports; document modules.
• Logs: Deployment logs show import errors; use debug mode.

Conclusion

Custom script modules bring reusable PowerShell power to your deployments, enhancing efficiency and aiding enterprise migrations from tools like Bamboo.

Pair with Step Templates in Action. Create your first module—visit Script Modules! New to Jaws? Start with Getting Started.

Environments and Targets in Jaws Deploy

Environments and targets form the backbone of your deployment topology in Jaws Deploy, allowing you to model real-world infrastructure and control where and how releases are rolled out. Environments represent logical stages in your pipeline (e.g., development, testing, production), while targets are the actual destinations—such as servers, VMs, or cloud services—where the deployment logic executes. This separation ensures precise, secure, and scalable deployments, especially in hybrid or multi-cloud setups.

Whether you're deploying a simple web app or managing enterprise-scale microservices, understanding these concepts helps prevent config leaks, enforce progression rules, and simplify migrations from tools like Bamboo. This article explains how to set them up, manage them, and integrate with deployment logic.

What Are Environments?

Environments are logical groupings that define stages in your release lifecycle, such as "Dev," "Staging," or "Production." They act as gates, controlling access and configurations without tying directly to physical infrastructure.

Key features:

• Progression Control: Use lifecycles to automate or gate promotions (e.g., require approvals before moving from Staging to Production).
• Scoping: Variables and steps can be scoped to environments for env-specific behavior (e.g., different connection strings in Dev vs. Prod).
• Visibility: Dashboards show activity, trends, and deployment history per environment, helping spot bottlenecks.

Environments are shared across projects in a workspace, making them reusable for consistent pipelines.

This shows environments like Staging and Production with last deployments, statuses, durations, and trends. Use it to monitor activity at a glance.

What Are Targets?

Targets are the execution endpoints for your deployments. Jaws supports two main types:

• Machines: Physical or virtual servers running the Jaws Deploy Agent—a lightweight service for Windows/Linux. Agents pull tasks from Jaws, execute steps, and report back.
• Cloud Targets: Managed services like Azure Web Apps, where Jaws interacts directly via APIs without an agent.

Targets are assigned to environments (one-to-many) and can be tagged for flexible grouping (e.g., "region-us," "app-tier"). This enables targeted deploys without overcomplicating logic.

View machines with active status, connection, OS, agent version, environments, tags, and actions like checking updates. Tags like "app-web.1.0" help in scoping.

Setting Up Environments

1. Add Environments: From the left menu, go to Environments > Add new environment. Name it (e.g., "Staging"), add a description, and optionally assign a lifecycle.
2. Configure Lifecycles: In the Lifecycles menu, define phases (e.g., "Test" > "Stage" > "Prod") with rules like mandatory environments or manual approvals. Assign to projects for automated progression.
3. Scope Resources: Link variables or steps to environments via scoping—e.g., a secret variable only resolves in "Production" for security.

For enterprise migrations (e.g., from Bamboo), map Bamboo stages to Jaws environments: Start with a 1:1 replication, then optimize with lifecycles to reduce manual gates.

Tip: Use channels for variant paths, like fast-tracking hotfixes through a "Beta" environment.

Setting Up Targets

Machines

1. Install Agent: Download the installer from the Machines page or docs. Run on your server (Windows service or Linux systemd). It handshakes with Jaws automatically.
2. Add and Configure: Once online, the machine appears in the list. Assign environments, tags, and check connection/agent version.
3. Agent Management: Agents auto-update; use "Check for updates" for manual control. Supported on Windows/Linux, with .NET 8 runtime.

Cloud Targets

1. Add Cloud Accounts: In Cloud Accounts, link providers like Azure (subscription ID, tenant, etc.).
2. Configure Targets: For Azure Web Apps, add via the Azure Web Apps menu—select slot, region, and link to environments.
3. Hybrid Use: Combine with machines for mixed deploys, e.g., app to Azure, database to on-prem VM.

During migrations, install agents on existing Bamboo agents for dual-running; gradually decommission as you shift to Jaws.

While not directly for targets, use variables scoped to machines/cloud for target-specific configs, like Azure keys.

Integrating with Deployment Logic

• Targeting Deploys: In project steps, select targets via environments or tags—e.g., deploy only to machines tagged "web-tier" in "Staging."
• Parallelism and Conditions: Steps run in parallel across targets; add conditions (e.g., OS-specific) for fine control.
• Monitoring: Deployments show per-target logs and statuses; use dashboards for cross-environment views.
• Migration Tip: In Bamboo-Jaws hybrids, trigger Jaws deploys from Bamboo scripts post-build, passing artifacts via API for seamless transition.

Best Practices

• Simplify Topology: Start with 3-5 environments; use tags for granularity instead of proliferating envs.
• Security: Scope secrets to targets/environments; use Azure Key Vault integration for external storage.
• Enterprise Scale: For migrations, audit Bamboo agents and map to Jaws machines; leverage self-hosted Jaws Stack for on-prem parity.
• Performance: Tag for selective deploys; monitor trends to optimize slow targets.
• Testing: Use DEV environments for dry runs; enable __debug for variable resolution insights.

Conclusion

Environments and targets in Jaws Deploy provide a flexible foundation for modeling and executing deployments, making it easy to manage complex infrastructures—especially during enterprise migrations from tools like Bamboo.

Dive deeper with Managing Release Progression with Lifecycles or Installing Jaws Deploy Agent. For migration help, see Migrating from Octopus Deploy (adaptable principles). Ready to configure? Head to your dashboard now!

‍

Managing Machines in Jaws Deploy

Machines in Jaws Deploy are physical or virtual servers (on-prem or cloud VMs) that serve as deployment targets, running the lightweight Jaws Deploy Agent to execute steps from your projects. They represent the "where" of your deployments—handling tasks like package extraction, script running, and service installations. Managing machines involves installing the agent, adding them to your workspace, configuring environments/tags, monitoring status, and handling updates—essential for reliable, scalable CD.

Unlike agentless cloud targets (e.g., Azure Web Apps), machines offer full customization via the agent, supporting Windows and Linux. This is particularly useful in enterprise setups migrating from tools like Bamboo, where you can repurpose existing agents for hybrid operations. As of September 22, 2025, agents now include improved auto-update logic and enhanced logging for containerized scripts.

This article covers setup, management, monitoring, and best practices.

What Are Machines?

Machines are endpoints where deployments occur:

• Agent-Based: The Jaws Deploy Agent (a background service) polls the server, executes steps, and reports back.
• Supported OS: Windows (as a service) and Linux (via systemd).
• Capabilities: Run PowerShell scripts (default), with bash/Python support rolling out later in 2025; handle packages, configs, and custom logic.
• Assignment: Link to environments (e.g., "Production") and tags (e.g., "region-us") for targeted deploys.

In contrast to cloud targets, machines are ideal for custom or legacy infra. For migrations, install agents on Bamboo-managed servers to test parallel deploys.

Installing the Jaws Deploy Agent

The agent is required on every machine:

1. Access the UI: In your workspace, go to Machines > Add new machine.
2. Download Script: Select OS (Windows/Linux) and download the install_agent script.
3. Run the Script:
   • Windows: Open elevated PowerShell; run the script. Installs to C:\\\\Program Files\\\\JawsDeploy\\\\Agent as "Jaws Deploy Agent" service.
   • Linux: Run with admin privileges (sudo); installs to /opt/JawsDeploy/Agent as a systemd service.
4. Handshake: The agent starts and reports to Jaws; accept in the "Pending handshakes" section, optionally assigning an environment.

No user interaction during install; agent auto-starts and connects.

For enterprise batch installs, script deployments via tools like Ansible; during Bamboo migrations, install on existing agents for dual-running.

See the Installing Jaws Deploy Agent guide for details.

Adding and Configuring Machines

Once installed:

1. Accept Handshake: In Machines, under Pending, click "Accept" and set environment/tags.
2. Edit Details: Click Edit to rename, reassign environments, or add tags (e.g., "app-web" for scoping).
3. Authentication: Agents use built-in auth; configure proxies if needed (see Proxy Setup).
4. Tagging: Add custom tags for grouping (e.g., "os-windows," "tier-db")—key for targeted deploys without env proliferation.

Machines appear in the list with status indicators.

This displays machines with active/connection status, OS, agent version, environments, tags, and actions like Edit, Check for updates, Delete.

Monitoring and Maintaining Machines

• Status Checks: Green for active/connected; red for issues. Use "Check for updates" to verify agent version (auto-updates supported).
• Activity Logs: View last deployments, errors in dashboards.
• Updates: Agents self-update; manual via UI button or script re-run.
• Uninstallation: Stop service, remove files (Windows: Uninstall via Control Panel; Linux: systemd remove).
• Troubleshooting: Reject unrecognized handshakes; check agent logs (in install dir) for connection errors.

For enterprises, monitor via dashboards; integrate with tools like Jira for alerts on offline machines.

Integrating with Deployments

• Targeting: In steps, select via environments/tags—e.g., deploy only to "tier-web" machines.
• Parallelism: Run steps across multiple machines simultaneously.
• Hybrid Use: Combine with cloud targets, e.g., deploy app to Azure, scripts to machines.
• Migration Tip: From Bamboo, add machines matching existing agents; test deploys in parallel.

Best Practices

• Security: Use least-privilege; agents pull work—firewall outbound to Jaws only.
• Scalability: Tag for dynamic groups; auto-scale VMs with agent pre-installed.
• Enterprise Migration: Install on Bamboo servers; gradually shift logic to Jaws for reduced maintenance.
• Performance: Monitor connection times; update agents regularly.
• Backup: Snapshot VMs; agent config is minimal.
• Debugging: Enable __debug for agent-side var logs.

Conclusion

Managing machines in Jaws Deploy provides a robust foundation for agent-based deployments, simplifying enterprise migrations from tools like Bamboo with easy setup and monitoring.

For more, see Installing Jaws Deploy Agent or Tagging in Jaws Deploy. Add your first machine—head to the Machines page! New to Jaws? Start with Getting Started.

Cloud Targets in Jaws Deploy

Cloud targets in Jaws Deploy represent managed cloud services where your applications or services are hosted, allowing seamless deployments without the need for installing agents on physical machines. Unlike traditional servers or VMs that require the Jaws Deploy Agent, cloud targets leverage provider APIs for direct interaction, making them ideal for serverless or PaaS environments. This reduces overhead, enhances security, and simplifies management in cloud-native setups.

Currently, Jaws Deploy supports Azure Web Apps as a primary cloud target, with plans for expanded support (e.g., AWS App Runner, Google Cloud Run) in future updates. Cloud targets are especially useful for hybrid deployments—combining them with machines for full-stack apps—or during migrations from on-prem to cloud, where you can gradually shift logic without disrupting workflows.

This article covers what cloud targets are, how to set them up, integrate with your projects, and best practices for enterprise use.

Understanding Cloud Targets

Cloud targets are deployment destinations backed by cloud provider APIs, enabling Jaws to push packages, run scripts, or apply configurations directly. Key benefits:

• Agentless: No software installation needed on the target—Jaws handles authentication via linked cloud accounts.
• Scalability: Leverage cloud auto-scaling; deploy to slots (e.g., Azure staging slots) for zero-downtime updates.
• Security: Credentials are stored securely in Jaws (or integrated with vaults like Azure Key Vault), with scoping to prevent leaks.
• Hybrid Integration: Assign to environments and tags alongside machines for mixed topologies, e.g., deploy a web app to Azure while updating an on-prem DB.

In contrast to machines (which run the agent for custom scripting), cloud targets focus on provider-specific actions like restarting apps or swapping slots.

For enterprises migrating from tools like Bamboo, cloud targets streamline the shift to PaaS: Map Bamboo deployment tasks to Jaws steps, using API triggers for handoffs.

Setting Up Cloud Targets

Step 1: Add Cloud Accounts

Before adding targets, link your cloud provider credentials:

1. Go to the left menu > Cloud Accounts > Add new account.
2. Select Azure (current option) and provide details: Subscription ID, Tenant ID, Application ID, and Secret (from an Azure AD app registration with Contributor role).
3. Test the connection to verify.

This account is reusable across targets and workspaces, with secrets stored encrypted.

While not directly for accounts, store related secrets here (e.g., Azure keys) scoped to cloud targets for added security.

‍

Step 2: Add Cloud Targets

1. Navigate to Azure Web Apps (under DEPLOYMENT NODES) > Add new Azure Web App.
2. Select your cloud account, resource group, app name, and slot (e.g., production or staging).
3. Assign environments (e.g., "Staging" for testing slots) and tags (e.g., "region-westus") for targeting.
4. Save and test deployment readiness.

Once added, the target appears in the list with status, last activity, and quick actions.

For migrations, add cloud targets mirroring your Bamboo environments—test deploys in parallel to validate.

Types of Cloud Targets

Azure Web Apps

• Supported Actions: Deploy .zip packages, apply config transforms (JSON/XML), run post-deploy scripts (e.g., PowerShell for migrations), and swap slots.
• Slots: Use for blue-green deploys—deploy to a staging slot, test, then swap to production via a step.
• Integration: Link to Azure Key Vault for secrets; scope variables to apps for env-specific settings (e.g., app settings overrides).
• Limitations: Focused on .NET/Node/Java apps; for containers, use custom steps to push to Azure Container Instances (planned native support in 2025).

Future expansions may include AWS/GCP targets—watch for updates if multi-cloud.

Integrating with Deployment Logic

Cloud targets integrate like machines:

• In Projects: Add steps like "Deploy Package" and select the target via environment or tag.
• Scoping: Steps/variables can be scoped to cloud targets (e.g., run an Azure-specific transform only on Web Apps).
• Parallelism: Deploy across multiple apps/slots simultaneously.
• Lifecycles: Promote releases through environments, triggering slot swaps or restarts.

Example: In a project step, upload a .zip built from your CI tool (e.g., Bamboo), deploy to an Azure staging slot, and use a "Run Script" step to validate before swapping.

For enterprise migrations, trigger Jaws from Bamboo post-build via API, passing artifacts—gradually move full CD to Jaws.

Monitor cloud deploys here, with statuses, durations, and errors per target.

Best Practices

• Security First: Use least-privilege Azure AD apps; scope secrets to targets/environments.
• Hybrid Strategies: Tag cloud targets consistently with machines for unified deploys.
• Migration Tips: For Bamboo users, start with agentless cloud targets to reduce on-prem footprint; test blue-green with slots.
• Performance: Monitor deployment durations; use redownload packages option for consistency in distributed teams.
• Debugging: Enable __debug for variable insights; check Azure portal for app logs if issues arise.
• Enterprise Scale: In self-hosted Jaws, integrate with corporate proxies; use workspaces for team silos.

Conclusion

Cloud targets in Jaws Deploy simplify deploying to managed services like Azure Web Apps, offering agentless efficiency and tight integration with your logic—perfect for modernizing enterprise setups during migrations from tools like Bamboo.

Explore more with Azure Web App Deployment or Environments and Targets. For migration support, see Migrating from Octopus Deploy. Configure your first target today!

Using Package Feeds in Jaws Deploy

Package feeds in Jaws Deploy are sources from which deployment artifacts—such as .zip files, .tar.gz archives, or NuGet packages—are retrieved during a release or deployment. They act as repositories for your build outputs, ensuring that the right versions are pulled securely and consistently across environments. Whether you're using the built-in package store for simplicity or connecting external feeds for integration with existing CI tools, feeds streamline artifact management without exposing them publicly.

This approach is particularly helpful in enterprise setups, where you might migrate from scattered artifact storage in tools like Bamboo to a centralized, versioned system in Jaws. Feeds support SemVer 2.0 for versioning, enabling precise control and rollbacks. As of September 2025, feeds now include enhanced support for container image references in package notes, aiding hybrid workflows.

This article covers how to use package feeds, their role in deployments, and tips for optimization.

The Role of Package Feeds

Feeds provide a reliable way to store and reference artifacts:

• Artifact Types: Supports compressed files (.zip, .tar.gz) for general apps, NuGet (.nupkg) for .NET libraries, and indirect references for containers (e.g., Docker tags in notes).
• Versioning: Each package has a unique ID and version; releases snapshot specific versions for immutability.
• Security: Feeds are private to your workspace; access controlled via service accounts for API uploads.
• Integration: Pull from feeds in steps like "Deploy Package," where Jaws handles extraction, transforms (JSON/XML), and installation.

In deployments, targets (machines/cloud apps) download from feeds on-demand, with options to redownload for freshness. This decouples builds from deploys, ideal for CI/CD where Bamboo/GitHub Actions pushes to a feed, and Jaws pulls during release.

For migrations, map Bamboo artifacts to Jaws feeds: Upload via API post-build, then reference in projects for seamless transition.

Setting Up and Using Feeds

Jaws offers built-in and external feeds—configure via the Package Store menu.

Built-in Feeds

• Jaws' internal store per workspace; upload manually or via API (see Built-in Package Store).
• Usage: In a project step, select "Deploy Package" and choose from the store's list.

External Feeds

• Connect to NuGet servers or custom repositories (see Connecting External Feeds).
• Usage: Reference by URL in steps; Jaws authenticates and pulls during deploy.

To use in a deployment:

1. Upload Artifact: From CI or manually to a feed.
2. Create Release: Associate package versions (e.g., my-app@1.2.3).
3. Execute Deploy: Jaws fetches and applies on targets.

This lists packages with IDs, versions, sizes, upload dates, and download links. Search and filter to find artifacts quickly.

Best Practices

• Version Consistently: Use CI build numbers in SemVer (e.g., 1.0.${BUILD_NUMBER}) for traceability.
• Automate Uploads: Script API calls in CI (e.g., curl POST to /api/packagestore/package) for zero-touch.
• Security: Use service accounts for uploads; avoid public feeds for sensitive artifacts.
• Optimization: For large packages, compress well; use redownload sparingly to save bandwidth.
• Enterprise Migration: From Bamboo, export artifacts and batch-upload to Jaws feeds; test pulls in dev environments.
• Container Workflows: Note image tags in releases; use "Run Script" steps to pull/deploy from registries.

Troubleshooting Common Issues

• Package Not Found: Verify upload/version in store; check API responses for errors (e.g., 3001 invalid param).
• Download Failures: Ensure targets have network access; test with manual deploys.
• Version Conflicts: Use unique SemVer; delete duplicates via UI.
• Large Files: Workspace storage limits apply; upgrade plans for more.
• Debugging: Enable __debug to log feed resolutions during deploys.

Conclusion

Using package feeds in Jaws Deploy centralizes artifact management, making deployments reliable and integrated with your CI/CD. Whether built-in for quick starts or external for legacy compatibility, feeds simplify enterprise migrations from tools like Bamboo.

For details, see Built-in Package Store or Connecting External Feeds. Upload your first package—head to the Package Store now! New to Jaws? Try Getting Started.

Built-in Package Store in Jaws Deploy

The built-in package store in Jaws Deploy is a secure, workspace-specific repository for storing deployment artifacts like .zip, .tar.gz, or NuGet packages. It's your go-to feed for managing versions without relying on external services, ensuring artifacts are private and accessible only during deploys. This simplifies workflows by keeping everything in one place—no need for separate artifact servers.

Designed for ease, the store supports manual uploads via UI, automated via API, and versioning with SemVer 2.0. For enterprises migrating from tools like Bamboo, it's a direct replacement for shared artifact repositories, with added benefits like automatic cleanup and integration with project steps. As of September 2025, the store now handles larger files (up to 500MB base) and includes metadata for container references.

This article explains the store's features, setup, usage, and maintenance.

Features of the Built-in Package Store

• Private and Secure: Artifacts are not public; access limited to your workspace and service accounts.
• Version Management: Upload multiple versions per package ID; releases reference specific ones for consistency.
• Supported Formats: .zip/.tar.gz for general files, .nupkg for NuGet; prepare with dot-separated name.version (e.g., MyApp.1.2.3.zip).
• Inspection and Download: View details, download versions, or delete unused ones.
• Storage: Per-workspace limits (expandable via plans); automatic versioning prevents overwrites.

In deployments, targets pull from the store on-demand, with transforms applied post-download. For migrations, bulk-upload Bamboo artifacts via API to seed the store.

This page shows the upload section, preparation instructions, and package list with IDs, latest versions, sizes, upload dates, and actions like "Show all versions."

Setting Up and Uploading to the Store

1. Access the Store: From the left menu > Package Store.
2. Prepare Packages: Zip your artifacts; name with ID.version.ext (e.g., filemail.2.1.37.zip). Use SemVer for consistency.
3. Upload Manually: Click "Choose File" > Select your .zip/.tar.gz/.nupkg > Upload. Jaws validates and adds to the list.
4. Upload via API: For automation (e.g., from CI):
   • Use POST /api/packagestore/package
   • Headers: Authorization (Basic with service account)
   • Form Data: file=@path/to/package, packageId=my-app, version=1.2.3

• Versioning Rules: New uploads create versions; duplicates prompt overwrite or error.

For enterprise teams, set up service accounts for CI uploads; integrate with Bamboo post-build scripts during migration.

Using the Store in Deployments

• In Projects: In a "Deploy Package" step, select from the store's dropdown—Jaws lists available IDs/versions.
• During Release: Associate versions in release creation; deploys pull automatically.
• Redownload: Option in deploy settings to force fresh pulls, useful if packages update post-release.
• Transforms: Auto-apply to configs inside packages (e.g., appsettings.json with #{VAR} placeholders).

In container workflows, use the store for sidecar artifacts; note image tags separately in releases.

Maintenance and Best Practices

• Cleanup: Delete old versions via UI to free storage; Jaws warns on limits.
• Auditing: Upload history tracks who/when; integrate with enterprise logs.
• Optimization: Compress packages; use external feeds for massive artifacts.
• Migration from Bamboo: Script bulk uploads from Bamboo shared artifacts; test references in Jaws projects.
• Security: Mask sensitive data in packages; use scoped service accounts for uploads.
• Scaling: For high-volume, consider connecting external NuGet feeds to offload storage.

Troubleshooting Common Issues

• Upload Failures: Check file format/size; API errors like 2002 (auth) or 3001 (params).
• Not Found in Steps: Ensure package ID/version matches; refresh store list.
• Storage Limits: Monitor via dashboard; upgrade or clean up.
• Debugging: Use __debug in deploys to log package resolutions.

Conclusion

The built-in package store in Jaws Deploy offers a simple, integrated way to manage artifacts, reducing complexity in your CD pipelines—especially during enterprise migrations from tools like Bamboo.

For advanced use, see Connecting External Feeds or Using Package Feeds. Start uploading—visit your Package Store! New to Jaws? Check Getting Started.

Connecting External Feeds in Jaws Deploy

External feeds in Jaws Deploy allow you to connect to third-party repositories like NuGet servers, Artifactory, or custom artifact stores, expanding your package sources beyond the built-in store. This is useful for integrating with existing enterprise ecosystems, pulling from CI-generated feeds, or leveraging public registries without duplicating storage.

Jaws supports NuGet-compatible feeds out-of-the-box, with authentication for private ones. For enterprises migrating from tools like Bamboo, connecting external feeds bridges legacy artifact systems, enabling gradual transitions without immediate uploads to Jaws' store. As of September 2025, external feeds now support enhanced credential scoping and proxy handling for corporate networks.

This article covers setup, usage, security, and migration tips.

Benefits of External Feeds

• Integration Flexibility: Pull from Azure Artifacts, MyGet, or self-hosted NuGet—ideal for .NET-heavy enterprises.
• No Duplication: Reference existing packages without re-uploading; saves storage in Jaws.
• Hybrid Workflows: Use alongside built-in store; fallback if internal feeds fail.
• Enterprise Compliance: Connect to audited feeds; maintain data sovereignty.

In migrations, link Bamboo-exported NuGet feeds to Jaws, testing pulls before decommissioning.

Setting Up External Feeds

1. Access Feeds: From Package Store > External Feeds (or via project steps for ad-hoc).
2. Add a Feed: Click "Add external feed":
   • Type: NuGet (primary; others via custom URL).
   • URL: Feed endpoint (e.g., https://pkgs.dev.azure.com/org/_packaging/feed/nuget/v3/index.json).
   • Credentials: Username/API key; store securely (integrate with Azure Key Vault).
   • Name/Description: For easy reference.
3. Test Connection: Jaws verifies access and lists sample packages.
4. Proxy (Optional): For enterprises, configure via Jaws Stack settings (see Proxy Setup).

Feeds are workspace-shared; scope usage via service accounts for security.

Using External Feeds in Deployments

• In Projects: In "Deploy Package" steps, select the external feed and search for IDs/versions.
• During Release: Reference packages in creation; Jaws pulls during deploy with auth.
• Fallback: Set primary/secondary feeds; auto-switch if one fails.
• Transforms: Apply to pulled packages as usual.

For container workflows, use external feeds for manifests; pull images in "Run Script" steps.

Example API for release with external package:

json

{  "projectId": "abc123",  "version": "1.2.3",  "packageVersions": {"my-app": "1.2.3@external-feed-name"}}

In Bamboo migrations, script pushes to external feeds, then trigger Jaws releases referencing them.

Best Practices

• Authentication: Use API keys over usernames; rotate regularly.
• Performance: Cache frequently used packages in built-in store; monitor pull times.
• Security: Scope feeds to environments; avoid public ones for prod.
• Migration Strategy: From Bamboo, connect existing Artifactory feeds; validate in Staging before full switch.
• Version Control: Enforce SemVer in CI; use feed queries to list available versions.
• Enterprise Scale: For proxies/firewalls, test connectivity; integrate with SSO for auth.

Troubleshooting Common Issues

• Connection Failures: Check URL/creds; test with curl from agents.
• Auth Errors: Verify scopes; API returns 2002 for invalid.
• Package Not Resolved: Ensure feed indexed; refresh in Jaws.
• Proxy Issues: Configure in self-hosted; debug with logs.
• Debugging: Use __debug to trace feed pulls during deploys.

Conclusion

Connecting external feeds in Jaws Deploy extends your artifact options, facilitating integrations and enterprise migrations from tools like Bamboo while keeping deploys flexible.

Pair with Built-in Package Store or Using Package Feeds. Connect your first feed—go to Package Store! New to Jaws? See Getting Started.

Creating Releases in Jaws Deploy

Releases in Jaws Deploy are versioned snapshots of your project's deployment logic, capturing the state of steps, variables, and packages at a specific point in time. They serve as immutable bundles ready for deployment to one or more environments, ensuring consistency and traceability across your pipeline. Creating a release is a key step in the CD process: It packages your build artifacts (from CI tools like Bamboo or GitHub Actions) and applies rules like channels or lifecycles for controlled rollouts.

Whether triggered manually via the UI for quick tests or automated through API integrations for production workflows, releases make deployments repeatable and auditable. This is especially valuable in enterprise migrations (e.g., from Bamboo), where you can replicate build numbers as release versions for seamless continuity. As of September 2025, releases now support enhanced container tagging in notes for better integration with Docker workflows.

This article walks through creating releases, managing versions, adding notes/packages, and automating the process.

Understanding Releases

A release represents a deployable version of your project:

• Versioning: Follows SemVer 2.0 (e.g., 1.2.3-rc1), ensuring semantic clarity and compatibility checks.
• Components: Includes selected package versions, variable snapshots, step configurations, and optional notes/channels.
• Immutability: Once created, a release can't be edited—recreate if changes are needed, promoting safe promotions.
• Relation to Deployments: Releases are deployed to environments via lifecycles; track history for rollbacks.

Releases are tied to channels (optional) for branching logic, like "Stable" vs. "Beta." In migrations, map Bamboo build artifacts to Jaws releases for version parity.

This shows release version, creation time, notes, channel, packages, and deployment history. Use the "Create Release" button here.

Creating a Release Manually

For testing or ad-hoc deploys:

1. Navigate to the Project: From the Projects page, select your project and go to the "Releases" tab.
2. Click Create Release: Provide:
   • Version: A unique SemVer string (auto-suggests next increment, e.g., from 2.1.37 to 2.1.38).
   • Channel: Optional; select for lifecycle variants (e.g., hotfix channel skips testing).
   • Packages: Choose versions from your package store (e.g., my-app v2.1.37); supports multi-package projects.
   • Notes: Add details like changelog, Jira tickets, or container tags (e.g., "Image: myrepo/app:2.1.37").
3. Review and Create: Preview the snapshot; Jaws validates compatibility (e.g., package existence).
4. Deploy Immediately (Optional): Check "Deploy after creation" and select environments.

Post-creation, the release appears in the list with status and quick deploy actions.

For enterprise teams, use notes to link to Jira for compliance; during Bamboo migrations, script version syncing via API.

Automating Release Creation

For CI/CD integration, automate via REST API or PowerShell SDK—essential for production pipelines.

Using the REST API

• Endpoint: POST /api/release
• Auth: Basic with service account.
• Body Example:

{
  "projectId": "abc123",
  "version": "2.1.38",
  "channelName": "Stable",
  "notes": "Built from commit abcdef; Jira: PROJ-123",
  "packageVersions": {"my-app": "2.1.38"}
}

• Response: Release ID for subsequent deploys.

Trigger from CI tools like GitHub Actions or Bamboo post-build.

Using the PowerShell SDK

• Command: Invoke-ReleaseAndDeployProject -projectId "abc123" -version "2.1.38" -environmentName "Staging"
• Simplifies creation + deploy in one call.

In migrations, add this to Bamboo scripts for hybrid runs: Build in Bamboo, create/release in Jaws.

Managing Release Versions and Packages

• Version Rules: Must be unique per project/channel; use build numbers (e.g., from CI) for traceability.
• Packages: Upload via UI/API to the package store before release; supports .zip, .tar.gz, NuGet. For containers, note image tags in releases—Jaws steps can pull/deploy them.
• Redownload Option: During deploy, force package re-download for freshness.
• Cleanup: Delete old releases via UI/API to manage storage.

Enterprise Tip: In large setups, use channels to separate release streams (e.g., "LTS" for stable enterprise branches).

Best Practices

• Semantic Versioning: Follow MAJOR.MINOR.PATCH; use pre-releases (-rc1) for testing.
• Automation First: Manual for dev; API for prod—integrate with CI for zero-touch.
• Notes for Traceability: Include commit hashes, tickets; link to Jira/Bitbucket.
• Migration Strategy: From Bamboo, export build artifacts and trigger Jaws releases via scripts; test lifecycles to mimic Bamboo gates.
• Security: Use service accounts with minimal scopes; audit release history.
• Debugging: Deploy with __debug = true to log resolved vars/packages.

Conclusion

Creating releases in Jaws Deploy bridges your builds to deployments, with flexible manual/automated options suited for enterprise migrations from tools like Bamboo.

For more, see Managing Release Progression with Lifecycles or CI/CD Integration. Automate your first release—check the API Reference for details! New to Jaws? Start with Getting Started.

Executing Deployments in Jaws Deploy

Executing a deployment in Jaws Deploy is the process of applying a release to one or more environments, running the defined steps on targets (machines or cloud apps), and monitoring the outcome. It's where your planning pays off: Releases are pushed live, configurations are transformed, scripts execute, and your app updates seamlessly. Deployments can be manual for controlled rollouts or automated via lifecycles and API triggers for CI/CD efficiency.

This step ensures reliability with features like live previews, parallel execution, and detailed logging—crucial for minimizing downtime in production. For enterprise teams migrating from tools like Bamboo, deployments in Jaws mirror plan executions but with enhanced visibility and fewer custom scripts. As of September 2025, deployments now include improved container handling in logs for better debugging in Kubernetes-like setups.

This article covers how to execute deployments, monitor progress, handle errors, and automate for scale.

Preparing for Deployment

Before executing:

• Have a Release Ready: Create one manually or via API (see Creating Releases).
• Check Targets: Ensure machines are online (green status) and cloud targets (e.g., Azure Web Apps) are connected.
• Review Lifecycles: Confirm progression rules—e.g., auto-deploy to Staging, manual for Production.
• Scope and Variables: Verify variables resolve correctly (test with __debug = true for previews).

In migrations, align Bamboo artifacts with Jaws packages; test a dry-run deployment to validate.

Executing a Deployment Manually

For targeted or testing deploys:

1. From the Release Page: Select a release > Click "Deploy" (or "Deploy again" for redeploys).
2. Choose Environments: Select one or more (e.g., "Staging"); Jaws shows eligible based on lifecycle.
3. Configure Options:
   • Redownload Packages: Force fresh pulls from the store (useful if artifacts updated).
   • Exclude Steps: Skip specific steps (e.g., for partial deploys).
   • Parallelism: Set how many targets run simultaneously (default: all).
   • Guided Failure: Enable for manual intervention on errors.
4. Preview and Start: Review the plan (targets, steps, vars); confirm to execute.

Deployment starts immediately, with live updates in the UI.

This view shows the deploy button, options, and running deployments with statuses, durations, and triggers (e.g., "TeamCity").

Automating Deployments

For production efficiency:

• Lifecycles: Set auto-promotion rules (e.g., after successful Staging, deploy to Prod). Trigger via API post-CI.
• API Execution: Use POST /api/release/deploy with release ID and environments.Example Body:

{
  "releaseId": "def456",
  "environments": ["Production"],
  "redownloadPackages": true
}

• SDK: PowerShell's Invoke-ReleaseAndDeployProject combines creation and deploy.
• CI/CD Triggers: Integrate with tools like Bamboo—post-build, call API to execute (see CI/CD Integration Guide).

In enterprise setups, automate for zero-touch: Use webhooks or scheduled deploys; during Bamboo migrations, run parallel executions to compare outcomes.

Monitoring and Managing Deployments

• Live Progress: Watch in the Deployments tab—grouped by steps/targets, with real-time logs and statuses (Completed, Failed, Running).
• History and Trends: View past deploys with durations, errors, warnings; dashboards show activity graphs for bottlenecks.
• Notifications: Set up alerts (email/Slack via integrations) for failures.
• Intervention: Pause/resume, skip steps, or retry failed targets mid-deploy.
• Auditing: Every deploy logs who triggered it, when, and changes—key for compliance.

For container workflows, logs now highlight image pulls/tags; enable verbose with __debug.

See deployment slots, statuses, errors/warnings, and trends across projects/environments.

Handling Errors and Troubleshooting

• Common Issues: Package not found (check store), connection failures (verify targets), variable mismatches (use debug).
• Debug Mode: Set __debug = true in project variables—logs all resolved values and contexts.
• Rollback: Redeploy a previous release; use lifecycles for automated fallbacks.
• Enterprise Tip: In migrations, compare Bamboo logs with Jaws; use output variables to capture diagnostics.

If stuck, check machine/agent logs or Azure portal for cloud targets.

Best Practices

• Start Small: Manual deploys for dev; automate for prod.
• Zero-Downtime: Use cloud slots or blue-green with tags.
• Security: Scope deploys to roles; audit triggers.
• Performance: Parallelize where safe; monitor trends to optimize steps.
• Migration Strategy: From Bamboo, script API calls in plans; gradually deprecate Bamboo deploys.
• Scale: For enterprises, use tags for canary deploys; integrate with monitoring tools.

Conclusion

Executing deployments in Jaws Deploy turns your plans into action, with robust monitoring and automation for reliable outcomes—streamlining enterprise migrations from tools like Bamboo.

Learn more in Managing Release Progression with Lifecycles or Variables. Execute your first deploy now! For help, see Contact Us.

Deployment History and Auditing in Jaws Deploy

Deployment history and auditing in Jaws Deploy provide essential tools for tracking, reviewing, and ensuring compliance in your CD processes. History lets you view past deployments, analyze trends, and rollback if needed, while auditing focuses on who did what, when, and how—crucial for security and regulatory requirements. Together, they offer transparency into your operations, helping debug issues, optimize workflows, and maintain accountability.

In enterprise migrations from tools like Bamboo or Octopus, these features map to build logs and user permissions, but with enhanced UI dashboards and API access for automation. As of September 23, 2025, history now includes improved filtering for container-related deploys, and auditing logs API actions more granularly.

This article covers viewing history, accessing logs, auditing user actions, and best practices.

Viewing Deployment History

Deployment history records every release rollout, allowing you to revisit outcomes and patterns.

• Access History: From a project > Deployments tab, or the main dashboard for cross-project views. See lists with deployment ID, environment, status (Completed/Failed), errors/warnings, creation time, trigger (e.g., user or CI tool like TeamCity), and duration.
• Trends and Activity: Dashboards show graphs of deployment frequency, durations, and success rates over time—filter by project, environment, or date.
• Release Association: Each deployment links to its release, showing version, notes, and packages for context.
• Rollback Support: Redeploy past releases directly from history for quick reversions.

In migrations, use history to compare Jaws deploys with Bamboo runs; export data via API for reporting.

This displays projects with recent deployments, trends (bar graphs for activity), and summaries of statuses, errors, warnings, and durations. Filter to drill down.

Shows a release's deployment history with statuses, times, and triggers; click to view logs.

Accessing Deployment Logs

Logs provide detailed insights into what happened during a deployment.

• Live and Historical Logs: During execution, view real-time logs in the deployment page. Post-deploy, access from history—logs include step outputs, timestamps, machine IPs, file operations, errors, and warnings.
• Structured Format: Logs are grouped by step and target, with levels (Info, Warning, Error) for easy scanning.
• Debug Mode: Set __debug = true in variables for verbose output, including resolved vars and contexts—great for troubleshooting.
• API Access: Use GET /deployment with deploymentId to fetch status and logs (optional skipLogs or getLogsAfter for paging). Response includes status object and logs array with timestamps, levels, and messages.

For enterprises, logs aid compliance; integrate with external tools via API for centralized monitoring.

Auditing User and System Actions

Auditing ensures traceability of changes and operations.

• RBAC and Permissions: Actions are gated by roles (e.g., Organization Admin, Project Deployer)—view in Settings > Roles & Permissions. Roles scope to workspaces/projects/environments, logging who can do what.
• Service Accounts: For API auditing, track actions via account names (e.g., "TeamCity" for CI triggers). API keys are one-time view, with Basic Auth for secure access.
• Audit Trails: History implicitly audits deploys (who triggered, when); for broader actions (e.g., project edits), use notifications and user invite/accept logs.
• Compliance Tools: Export history/logs via API for reports; integrate with Jira for ticket-linked audits.

In Bamboo migrations, Jaws' auditing replaces plan logs with more granular, user-scoped tracking.

Lists accounts with names, roles, statuses, and IDs; manage API keys for audited automation.

Shows invite history with statuses, dates, inviters, and expirations—part of user audit.

Best Practices

• Regular Reviews: Use trends to spot patterns (e.g., frequent failures in Staging); set alerts for errors.
• Automation: Trigger deploys via API for auditable CI/CD; log custom notes in releases.
• Security: Limit roles; rotate API keys; use debug sparingly in Prod.
• Migration from Bamboo: Import Bamboo logs as initial history; align triggers for consistent auditing.
• Performance: Filter large histories; archive old deploys if needed.
• Compliance: Enable all logging; integrate with SIEM tools via API.

Conclusion

Deployment history and auditing in Jaws Deploy deliver the visibility and accountability needed for robust CD, simplifying enterprise migrations from tools like Bamboo with intuitive UI and API support.

For more, see Executing Deployments or Service Accounts and Automation. Review your history—check the dashboard! New to Jaws? Start with Getting Started.

Introduction to Variables

Variables in Jaws Deploy are dynamic placeholders that let you customize deployment behavior without hardcoding values, making your workflows flexible, secure, and reusable. They can hold configuration data, secrets, or computed values, resolved at runtime based on context like environments or targets. This eliminates repetition and reduces errors, especially in multi-stage pipelines where settings vary (e.g., dev vs. prod connection strings).

Variables are a cornerstone for enterprises, enabling centralized management of configs during migrations from tools like Bamboo—map scattered env vars to Jaws' scoped system for better control. Types include text, secrets, numbers, booleans, dates, and maps, with expressions for advanced logic. As of September 23, 2025, variables now support enhanced scoping for container tags, aiding hybrid deployments.

This introduction covers types, scoping, expressions, usage, and tips to get started.

Understanding Variables

Variables store values that inject into steps, scripts, or configs during deployment. They resolve based on scopes, ensuring the right value applies (e.g., a secret only in Production).

• Key Features: Multi-valued (one var, many scopes), expressions (#{VAR.otherVar + "suffix"}), outputs (capture from steps), and history tracking for audits.
• Levels: Project-specific (per-project tab), workspace-shared (reusable across projects), or global (org-level, though limited).
• Resolution Order: When multiple scopes match, priorities apply: machine > cloud target > tag > environment > unscoped.

In migrations, import Bamboo vars as workspace variables for quick setup.

This shows the variables list with actions, names, types, values (masked for secrets), scopes (environment, tag, etc.), and add buttons. Hover for history.

Types of Variables

Jaws supports various types for different needs:

• Text: Simple strings, e.g., paths or URLs.
• Secret: Encrypted for sensitive data like API keys—masked in UI/logs.
• Number: Integers/floats for counts or ports.
• Boolean: True/False for toggles.
• Date: Timestamps for scheduling.
• Map: Key-value pairs for structured data (e.g., JSON-like configs).

Choose types when adding; secrets auto-encrypt. For enterprises, use secrets with Azure Key Vault integration for external storage.

Scoping Variables

Scoping controls where values apply, preventing leaks:

• Unscoped: Default value everywhere.
• Environment: E.g., different DB URLs in Staging vs. Production.
• Tag: For machine groups, e.g., "region-us" gets local endpoints.
• Machine/Cloud Target: Per-target overrides, e.g., unique certs.

Add scopes when creating variables; multiple per var for overrides. Resolution favors specifics (e.g., machine beats environment).

In action: A "ConnectionString" secret scoped to "Production" ensures it's only used there.

Using Expressions

Expressions make variables dynamic: #{VAR.baseUrl}/#{VAR.endpoint} resolves to a full URL. Nest them, use conditionals (e.g., #{if VAR.isProd then "prod-value" else "dev-value"}), or reference outputs (e.g., #{PreviousStep.Output}).

In scripts: Access as $Jaws.Parameters["VAR.name"].Value.

For migrations, expressions replace Bamboo's variable substitutions, with more power.

Adding and Managing Variables

1. Add a Variable: Project > Variables tab > Add variable. Name it, select type, add values/scopes.
2. Workspace Variables: Settings > Workspace Variables—for shared use; reference in projects as #{VAR.sharedName}.
3. Edit/History: Click edit; view changes via hover (who/when).
4. Outputs: In steps, set with Set-JawsOutputValue; scope to machine/env for reuse.

Not directly variables, but shows user management; for vars, imagine a similar list with scoping columns.

Best Practices

• Scope Narrowly: Use environments/tags to avoid conflicts; secrets always scoped.
• Expressions for Logic: Compute values on-the-fly; test with debug mode.
• Security: Secrets for creds; integrate with vaults.
• Migration from Bamboo: Import as workspace vars; automate with API.
• Debugging: Set __debug = true to log resolutions; monitor in deploys.
• Enterprise Scale: Share workspace vars for teams; audit history for compliance.

Conclusion

Variables introduce flexibility and security to your deployments, making Jaws Deploy adaptable for any scale—perfect for enterprise migrations from tools like Bamboo.

Dive deeper with Variables or Project Steps Explained. Add your first variable—open a project now! New to Jaws? Start with Getting Started.

‍

Variable Resolution Rules

Variable resolution in Jaws Deploy determines how multi-valued variables are evaluated and selected during a deployment, based on the current context. Variables are designed as multi-valued entities, meaning a single variable can hold different values depending on the deployment context, such as the machine or cloud target being deployed to. This context includes assigned environments and tags, allowing for flexible parametrization of deployment flows.

Understanding these rules is crucial for avoiding unexpected behavior and ensuring precise control over configurations. The rules prioritize specificity and complexity to resolve potential matches, making them reliable for enterprise-scale setups where variables might overlap across environments, tags, machines, or cloud targets.

Scoping Attributes

Variables can be scoped using the following attributes to define when a particular value applies:

• Environment (typical use-case for differentiating stages like Staging vs. Production).
• Tags (for grouping machines or targets).
• Specific machine.
• Specific cloud target.

Scopes allow you to tailor values to the deployment context. For example, you can create a variable named InstallationDirectory with:

• C:\\\\deployments\\\\myApp when deploying to the Staging environment.
• /opt/myApp when deploying to the Production environment.

Resolution Process

When a deployment context matches more than one value for a variable, Jaws Deploy resolves the conflict by selecting the value with the most complex or "strongest" scope. The complexity is determined by the combined amount and importance of the scoping attributes. The importance order is:

• Specific Cloud Target or Machine (most important).
• Tag.
• Environment (least important).

If multiple attributes are specified on a value (e.g., one environment and two tags), they are combined using AND logic between different attributes and OR logic between values of the same attribute. For instance, a scope with { Environment: ['Staging', 'UAT'], Tag: ['tag_A', 'tag_B'] } translates to:(context.Environment == 'Staging' OR context.Environment == 'UAT')

AND

(context.Tags.Contains('tag_A') OR context.Tags.Contains('tag_B')).

The overall scoping strength priorities are:

• Environment + Machine/CloudTarget (strongest).
• Machine/CloudTarget.
• Environment + Tag.
• Tag.
• Environment (least important).

This ensures that more specific scopes (e.g., tied to a particular machine) override broader ones (e.g., environment-only).

Examples

Consider the variable InstallationDirectory in a project with:

• 2 environments (Staging and Production).
• 1 machine in Staging (StagingServer).
• 3 machines in Production (ProdServer01, 02, and 03).

Suppose ProdServer03 requires a custom value. The scoped values would be:

• { value: 'C:\deployments\myAppStaging', scope: { Environment: ['Staging'] } }.
• { value: 'C:\deployments\myAppProd', scope: { Environment: ['Production'] } }.
• { value: 'C:\deployments\myAppProd_Custom', scope: { Machine: ['ProdServer03'] } }.

Resolution:

• Deploying to any Staging server uses the first value due to Environment match.
• Deploying to any Production server (except ProdServer03) uses the second value due to Environment match.
• Deploying to ProdServer03 uses the third value, as Machine scoping strength is higher than Environment, overriding the match.

This example highlights how Jaws Deploy prioritizes specificity to select the appropriate value.

Best Practices and Notes on Conflicts

• Always define scopes from most specific to general to leverage the resolution rules effectively.
• Test resolutions in a development environment using debug mode (__debug = true) to log how variables are evaluated.
• Avoid over-scoping to prevent unnecessary complexity, but use it where needed to handle exceptions (like the custom machine in the example).
• If conflicts arise (e.g., equal strength scopes), review and refine scopes to ensure one is more specific—Jaws Deploy will select based on the defined priorities, but clear hierarchies prevent ambiguity.

These rules make variable management predictable and powerful, supporting complex deployment scenarios while minimizing risks. For more on using variables, see the full Variables guide.

Nested and Referenced Variables

Nested and referenced variables in Jaws Deploy enhance the flexibility of your deployment configurations by allowing variables to incorporate or depend on the values of other variables. This feature enables dynamic, context-aware setups where values are resolved at runtime based on the deployment environment, tags, machines, or cloud targets. It's particularly useful for creating modular and reusable configurations, reducing redundancy in complex workflows.

In enterprise migrations from tools like Bamboo, nested variables help replicate dynamic substitutions, while referenced variables ensure seamless integration in scripts and steps. This article explains nesting (how variables can include others in their values), referencing (how to access them in steps and scripts), syntax, examples, rules, and limitations, based on Jaws Deploy's variable system.

Nesting Variables

Nesting allows you to define a variable's value using the value of another variable. When editing workspace or project variables, you can embed references to other variables within a value. These nested values are resolved based on the deployment context, just like standard variable resolution.

Syntax

Use the following syntax to nest variables:

#{VAR.variable_name}

Example

Suppose you have a base variable BasePath set to C:\\\\Apps\\\\. You can nest it in another variable InstallPath as #{VAR.BasePath}MyApp. During deployment, InstallPath resolves to C:\\\\Apps\\\\MyApp, depending on the context (e.g., scoped overrides for BasePath).

This nesting can chain multiple levels, but be cautious of potential complexity in resolution.

Rules and Limitations

• Nested values resolve using the same scoping rules as the parent variable—more specific scopes (e.g., machine) override broader ones (e.g., environment).
• If the nested variable doesn't resolve (e.g., no matching scope), the parent may fail or use a default, depending on the context.
• No explicit limit on nesting depth is mentioned, but deep chains may increase resolution time or risk circular references (not supported; avoid to prevent errors).
• Nesting works in variable values but not in scopes themselves.

Referencing Variables

Referenced variables are accessed within deployment steps or scripts to inject their resolved values. Jaws Deploy provides specific syntax for different contexts, ensuring variables are evaluated correctly at runtime.

In Deployment Steps

Every deployment step is based on a step template with a GUI JSON definition. When editing a project step in the UI, text inputs support variable references.

Syntax

#{VAR.variable_name}

Example

In a "Run Script" step's body or a "Deploy Package" step's path field, use #{VAR.InstallationDirectory} to insert the resolved value (e.g., C:\\\\Apps\\\\MyApp).

‍

In Deployment Scripts

PowerShell deployment scripts have access to the full context, including resolved variables.

Syntax

$Jaws.Parameters["VAR.variable_name"].Value

Example

In a script:

$installPath = $Jaws.Parameters["VAR.InstallationDirectory"].Value
Write-Host "Installing to $installPath"

This outputs the resolved path during execution.

Rules and Limitations

• References resolve based on the current deployment context (environment, tags, machine/cloud target).
• If a reference doesn't match any scope, it may resolve to an empty string or cause an error—always define defaults for unscoped cases.
• Expressions can include logic like conditionals (e.g., #{if VAR.isProd then "prod-value" else "dev-value"}), but nesting within expressions follows the same rules.
• Scripts must handle null/empty values gracefully to avoid failures.

‍

Best Practices

• Use nesting for composable configs (e.g., base + env-specific suffixes) to keep variables DRY.
• Test references with debug mode (__debug = true) to log resolutions and spot issues.
• For enterprises, nest secrets carefully to maintain security—avoid exposing in non-Prod scopes.
• During migrations, map Bamboo variables to nested structures for dynamic behavior.

Conclusion

Nested and referenced variables add power to your Jaws Deploy configurations, enabling dynamic resolutions that adapt to contexts. Master them for efficient, error-free deployments.

For more, see Variables guide or Project Steps Explained. Experiment in a project—add a nested variable today! New to Jaws? Start with Getting Started.

Best Octopus Deploy Alternatives & Competitors

Jaws Deploy is a smart Continuous Delivery platform which is easy to integrate, significantly reducing setup time and improving deployment reliability compared to Octopus Deploy.

In this write-up we evaluated several other CI/CD and Software Delivery vendors in order to outline what are the best alternatives.

What Is Octopus Deploy?

Octopus Deploy is a deployment automation platform built for orchestrating releases across multiple environments. It integrates cleanly with build systems and uses step-based workflows, but some teams encounter friction as infrastructure grows—setup can be time-consuming, variable modelling is limited, and scaling agents or targets increases overhead.

Why Teams Look for Alternatives

Common pain points include slow onboarding, heavy manual configuration, limited built-in verification/rollback, and rising maintenance and licensing overhead as the deployment surface expands.

Meet Jaws Deploy — A Clear Alternative

Jaws Deploy offers capabilities similar to Octopus but focuses on simpler setup and lower ongoing cost, making it attractive for teams wanting fast adoption and reduced operational load.

Strengths of Jaws Deploy

• Lightweight setup & agent model (cloud or self-hosted).
• Straightforward pricing, avoiding steep scaling costs.
• Robust environment/machine/variable modelling, including tag- and machine-scoped variables.
• Reusable step templates plus custom scripting for advanced workflows.
• Clear topology mapping via projects, environments, channels and lifecycles.

When Octopus May Still Be Right

It remains strong if your organisation already runs a large, stable Octopus installation or depends on niche integrations Jaws Deploy doesn’t yet support.

When Switching to Jaws Deploy Makes Sense

Ideal when you want quicker onboarding, simpler infrastructure, strong variable/tag modelling, clear pricing and a tool that scales with minimal maintenance.

Other Tools to Consider

• GitLab – all-in-one DevOps platform.
• Jenkins – highly customisable CI/CD via plugins.
• GitHub Actions – great for GitHub-centric teams.
• Ansible Automation Platform – config-driven automation.
• Spinnaker – advanced cloud-native and multi-cloud delivery.

What to Avoid in a CD Tool

When evaluating options, beware of tools that:

• Use CI-first architectures forced into CD — e.g., Jenkins extended with dozens of plugins for deployments, which often leads to brittle workflows.
• Lack real environment/machine/variable modelling, making multi-environment deployments fragile.
• Rely on expensive or heavy infrastructure footprints, where agents/targets become a scaling bottleneck.
• Introduce unnecessary operational complexity — e.g., Spinnaker, which is powerful but notoriously complex to operate unless you have a large platform engineering team.
• Provide weak topology mapping, making it hard to manage multiple environments, machines or tags consistently.

Final Thoughts

Octopus Deploy remains a solid platform, but many teams prioritise simpler setup, lower operating costs and clear modelling of environments and variables. Jaws Deploy offers a modern, lightweight alternative that delivers those benefits while remaining familiar to teams coming from Octopus.

Best Azure Dev Ops alternatives

What is Azure DevOps?

Azure DevOps is Microsoft’s full lifecycle DevOps platform: code repo, build/test pipelines, package feeds, release pipelines and cloud/on-prem deployments. It allows teams to build, test and deploy applications to any cloud or on-premises target.

Release pipelines in Azure Pipelines let you define environments, deployment jobs, track deployment history and apply strategies.

While powerful, many teams find hurdles: initial setup, large ecosystem, and cost or complexity as deployment footprint grows.

Why Look for Alternatives

When teams scale, particular friction points appear:

• Creating and managing environments/targets, tagging machines, and onboarding new applications can take time.
• Complex topologies (many environments, machines, tags) require heavy configuration.
• Licensing, infrastructure and maintenance overhead increase with scale.
• The full platform may include many capabilities beyond what pure deployment automation requires.

Enter Jaws Deploy

Jaws Deploy is a focused deployment automation platform designed to simplify CD workflows while retaining rich modelling and control.

Key benefits:

• Lightweight onboarding & agent model: pre-defined topology concepts (projects, environments, machines, tags) to get started faster. jawsdeploy.net
• Simpler pricing and lower maintenance overhead: fewer moving parts, less infrastructure to manage.
• Strong variable/machine/target modelling: variables scoped by environment, machine or tag; clear topology mapping. jawsdeploy.net+1
• Reusable step templates + script support: built-in templates plus custom scripting for flexibility. jawsdeploy.net
• Integration-friendly: Works with your existing CI/CD stack (including Azure Pipelines) via REST API and SDK. jawsdeploy.net

When Azure DevOps Might Still Be Right

If you already use Azure DevOps end-to-end (repos, boards, pipelines, artifacts) and have invested in the ecosystem, it may make sense to keep using it for deployment. Also if you need deep integration with Microsoft stack and advanced features built into Azure Pipelines.

When to Consider Switching to Jaws Deploy

If your primary need is deployment automation (rather than full lifecycle), if you want to reduce infrastructure/agent overhead, or if you have many environments/machines/tags and need a simple, powerful tool to manage them—Jaws Deploy is a strong alternative.

Other Tools to Consider

• Jenkins – highly customisable CI/CD tool extended into deployments.
• GitLab – integrated DevOps platform including CI/CD and deployment capabilities.
• Ansible Automation Platform – automation/orchestration with deployment features.
• GitHub Actions – lightweight CI/CD with some deployment support.
• Spinnaker – advanced delivery platform for progressive deployments and multi-cloud.

Final Thoughts

Azure DevOps is a very capable platform. For teams seeking full lifecycle capabilities, it may be ideal. But if deployment automation is the core requirement and you want fast adoption, lower cost, and simpler topology modelling—Jaws Deploy offers a compelling alternative.

Best GitLab alternatives

What is GitLab?

GitLab is a unified DevOps platform combining source control, CI/CD pipelines, project management and deployment capabilities. Its deployment features allow you to deploy applications to internal or public infrastructure, track deployment history, and use feature flags.

It supports review apps, feature-flags-based releases, and has a strong presence in the DevOps space for teams wanting an all-in-one solution.

Why Teams Sometimes Explore Alternatives

Although GitLab is very integrated, some teams find:

• When deployments get complex (many machines, tags, environments) the abstraction may feel less dedicated.
• Scope and model for machine-target topology or variable scoping may require custom scripting or workarounds.
• Cost/licensing for enterprise features may rise as scale increases, and the deployment component may not be as focused as a dedicated tool.

Why Jaws Deploy Makes a Good Alternative

Jaws Deploy provides deployment-specific features built to manage complex topologies, variables, and multi-target deployments while integrating with GitLab CI/CD.

Highlights:

• Dedicated topology modelling: projects, environments, machines, tags, scoped variables.
• Step-based deployment logic and reusable templates: designed for deployments with both built-in and custom step support.
• Integration with GitLab: Works seamlessly with GitLab pipelines, allowing the build/deploy flow to continue but with a stronger deployment layer.
• Ease of adoption and lower ongoing maintenance: simpler to operate for dedicated deployment needs.

When GitLab May Still Be Right

If your team already uses GitLab for repositories, issues, CI/CD and you want to keep everything in one platform, deployment via GitLab can be very convenient. Also for smaller teams or simpler deployment footprints.

When to Consider Switching to Jaws Deploy

If deployment complexity is growing, you need better variable/machine/target modelling, or you want a dedicated tool with lower overhead that works alongside GitLab rather than relying on GitLab as the deployment engine.

Other Tools to Consider

• Azure DevOps – build/test/deploy in a unified Microsoft stack.
• Jenkins – CI/CD with deployment via many plugins.
• Ansible Automation Platform – automation + deployment focus.
• GitHub Actions – CI/CD with deployment support.
• Spinnaker – advanced for progressive, multi-cloud delivery.

Final Thoughts

GitLab provides a strong, unified platform for DevOps and deployment. But when deployment needs become more granular and complex—and you want a dedicated layer that simplifies variable/machine modelling and reduces maintenance—Jaws Deploy presents a compelling alternative.