What's built in

Every workspace in Jaws Deploy ships with a NuGet-compatible package feed. It accepts .nupkg, .zip, .tar, and .tar.gz files. You push artifacts to it from CI, reference them in deployment steps, and the version that ends up in a release is locked at release-creation time.

The feed is not a separate product. There is no second service to install, configure, monitor, or upgrade. It is part of the workspace the same way variables and projects are.

Supported package formats

.nupkg Native NuGet packages. The feed speaks the NuGet protocol, so any tool that pushes NuGet can push here.
.zip Generic zip archives for non-.NET workloads. Steps that deploy zips extract them onto the target.
.tar / .tar.gz For Linux deployments and anything that has been tarballed by tradition.
External feeds Connect TeamCity, Azure DevOps, GitHub Packages, or Artifactory. Steps reference them like the built-in feed.

The push-from-CI pattern

The typical flow is: your CI job builds the artifact, packages it, and pushes it to the workspace feed. From there, anyone (or anything) that creates a release in that workspace can select that artifact version. CI doesn't need to know about deployments at all - it only needs an API key.

// Pushing from CI

NuGet-compatible push, no special SDK required

Because the feed speaks NuGet, nuget push and dotnet nuget push work as-is. PowerShell SDK is just sugar.

# from any CI runner with the API key in scope
nuget push Checkout.Web.2026.5.16.nupkg `
    -Source https://app.jawsdeploy.net/nuget/v3/index.json `
    -ApiKey $env:JAWS_API_KEY

# or, with the PowerShell SDK
Push-JawsDeployPackage `
    -Path ./Checkout.Web.2026.5.16.nupkg `
    -Workspace default

When you create a release, Jaws Deploy asks: "which package versions should this release include?" You pick Checkout.Web 2026.5.16 and Checkout.Migrations 2026.5.16, and those exact versions are recorded on the release.

From that moment on, the release is bound to those artifacts. Promoting the release to Production deploys those specific files. Re-running the release deploys those specific files. Six months later, those specific files. The link is what makes promotion meaningful.

External feeds

If you already have an artifact server you cannot or will not give up, Jaws Deploy connects to it as an external feed. The deployment step references the external feed instead of the built-in one, and the rest of the platform behaves identically: release locks the version, history records what was deployed, promotion deploys the locked version.

The most common external feeds in the wild:

// External feeds the platform plays well with

Where teams typically already have artifacts

  • TeamCity build artifacts - reference TeamCity build numbers directly as package versions.
  • Azure DevOps Artifacts - private NuGet feeds, npm feeds, generic feeds.
  • GitHub Packages - especially for .nupkg published from GitHub Actions.
  • Artifactory / Nexus - for teams with a centralized binary store they cannot retire.
  • Public nuget.org - for shared infrastructure packages that genuinely belong upstream.

// Built-in feed

When to use it

When you do not already have an artifact server. When you want the artifact to live next to the deployment. When you don't want a second thing to monitor.

// External feed

When to use it

When CI already publishes to a feed your org owns. When licensing or compliance pins you to a specific binary store. When you have a multi-tool ecosystem and Jaws Deploy is one consumer of many.

A final small detail

The feed enforces immutability per-version. Once Checkout.Web 2026.5.16 is pushed, you cannot push a different .nupkg with the same version number. That sounds like a constraint, until the first time someone tries to "just rebuild and push the same version" the day after a Production release. Then it sounds like a feature.