# Regional Package Delivery

Source: https://www.jawsdeploy.net/features/regional-package-delivery

Keep package bytes in your region and off the long-haul path. Pin a workspace's package store to a location near your servers, and let agents download straight from your own feeds - so a team in Sydney or Seattle deploys at local speed while accounts, UI, and orchestration stay centrally managed.

## One product, one login - bytes that stay in your region.

Jaws Deploy runs centrally, and for clicks and deploy orchestration that is exactly right: those are small, latency-light messages. The expensive part is moving large **package artifacts** back and forth across the world on every deployment. Regional delivery removes that round trip in two ways you can adopt independently - a regional package store for the built-in feed, and direct downloads from your own feeds - without splitting your account, your billing, or your data model.

- Package bytes stay in your region
- No second Jaws installation to run
- Works for the built-in feed and your own feeds
- Short-lived, single-item access links
- Opt-in per workspace and per feed
- Existing workspaces keep working unchanged

## Two levers, adopt either or both

- **Regional package store**: Pin a workspace's **package store location** to a region. Packages pushed to the built-in Jaws feed are uploaded to and downloaded from that region's storage - the bytes never leave it. Chosen at creation, then locked.
- **Direct feed downloads**: Flip **Allow direct downloads** on a private feed and agents pull packages straight from your TeamCity, NuGet, or artifact server - usually already next to them. Works for any workspace, regional or not.
- **Same trust boundary**: Both ride the authentication your agents and CI already use. Access is short-lived, scoped to a single package or feed, and can only ever reach resources inside the requesting machine's own workspace.

## Where your targets are, not where the datacenter is.

For teams in Australia, the US, or anywhere far from central infrastructure, regional delivery is both a performance win and a **data-residency** story: the package artifacts you deploy stay in the location you choose. You pick that location based on where the workspace's deployment targets live - and because stored packages physically reside there, the choice is fixed at workspace creation rather than a setting that could silently move data later.

## Pin a workspace to a region

Set the package store location at creation with regionId (list options via GET /api/workspace/regions). Omit it for the default location.

```
POST /api/workspace
Authorization: Basic <base64(...)>
Content-Type: application/json

{
  "name": "Sydney",
  "regionId": "au"
}
```

## Let agents skip the middle entirely

For packages that live in your own feed, the shortest path is the one that never touches Jaws infrastructure.

- Agents download each package straight from your feed - often on the same LAN as the target
- Jaws only resolves a tiny metadata descriptor; the bytes go feed to agent
- Off by default for existing feeds, pre-selected for newly created ones
- Each machine caches a version once, so your feed is not hammered on every deploy
- No server-side fallback when it is on - by design, your feed is meant to be reachable from your agents

> **Security - Credentials stay inside your workspace**
> 
> Direct-download feed credentials and regional storage links are delivered only over the authenticated, HTTPS negotiate response, only for resources in the machine's own workspace, and are never logged or persisted beyond the download. It is your own credential handed to your own machine - the same trust boundary agents already operate in when they receive deployment secrets.

> **Go deeper - Guides & reference**
> 
> Everything you need to set up regional delivery and direct feed downloads.

- [Start free](https://app.jawsdeploy.net/signup)
- [Read the guide](https://www.jawsdeploy.net/guides/regional-package-delivery)