# Package Feeds / Artifact Store

Source: https://www.jawsdeploy.net/features/package-feeds

Every workspace has a built-in NuGet feed. Push from CI, pull during deployment, version with releases. No second artifact server to babysit - unless you already have one, in which case Jaws Deploy talks to it.

## 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.

> **// Why this matters more than it sounds - One less thing in the deployment dependency chain.**
> 
> A typical alternative stack is: CI builds an artifact, pushes it to Artifactory/Nexus/an S3 bucket, the deployment tool pulls it from there, and somebody owns the artifact server's uptime. Jaws Deploy collapses that into one hop. The artifact lives next to the release that uses it.

## 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.

## 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
```

## Versioning and the release link

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.

> **// What goes in a package vs. what goes in a variable - Artifacts are bytes. Variables are strings.**
> 
> A useful rule: if something can be rebuilt deterministically from source, it belongs in a package. If something differs per environment and exists only at deploy time, it belongs in a variable. Mixing the two - environment-specific files inside the package - is how teams end up with a Production-only artifact that nobody else can reproduce.

## 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:

## 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.

**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.

**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.