Regional package delivery

Keep package bytes close to your servers - for teams in Australia, the US, or anywhere far from the Jaws datacenter. Two independent levers: a regional package store, and private feeds your agents download from directly.

Search guides... Ctrl K

Jaws Deploy runs its web app and database in Germany. For a team whose servers are in Sydney, Perth, or the US west coast, that distance is invisible for UI clicks and deploy orchestration - those are small messages. Where it hurts is package bytes: a 1 GB artifact that has to cross an ocean on the way in and again on the way out adds minutes to every deployment.

This guide covers the two features that keep those bytes local. They are independent - use either, or both:

  • A regional package store ("package store location") for packages you push to the built-in Jaws feed.
  • Direct downloads from your own private feeds (TeamCity, a NuGet server, etc.), so agents pull straight from a feed that is usually already next to them.

Two levers, one goal

Lever 1: a regional package store

A workspace has a package store location. Leave it at the default and nothing changes - packages are stored and served the classic way. Set it to a region (say Australia) and, for packages pushed to the built-in Jaws feed:

  • Upload goes straight to that region's storage. Your CI asks Jaws where to put the bytes and uploads them directly to regional storage; only a small metadata call touches Germany.
  • Download comes straight from that region's storage. The agent asks Jaws where to get the package and receives a short-lived link to the regional blob, then downloads directly - chunked and resumable.

The result: for a Jaws-feed workspace pinned to Australia, package bytes stay in Australia. Everything else - your login, the UI, the deployment orchestration - keeps running from Germany, which is fine because those are latency-light, not bandwidth-heavy.

Setting it up

At signup, the package-store-location picker sets the region of your default Main workspace. For later workspaces, choose the location in the create-workspace dialog, or pass regionId to Create a workspace over the REST API. The picker always includes a default (no region) option, so choosing a region is entirely opt-in and never mandatory.

Available locations depend on your installation - list them in the app or via List package store locations. New regions are added as customer demand appears (Australia first, US when needed).

// REST API

Create an AU-pinned workspace

Pass regionId to pin the package store location. Omit it for the default location.

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

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

Lever 2: direct downloads from your own feeds

If you deploy packages from your own feed - a TeamCity build, a NuGet server, an artifact store - the shortest path is almost always the one that skips Jaws entirely. Your feed is usually closer to your agents than any datacenter: a Perth team with TeamCity and agents in Perth should never send a byte to Sydney, let alone Germany.

Turn on Allow direct downloads on the feed and, at deploy time, agents download each package straight from the feed. Jaws only resolves the download descriptor (a tiny metadata call it already makes to list versions) and hands the agent the feed location, credentials, and file details. The bytes go feed -> agent, often on the same LAN.

This is independent of the package store location: any workspace benefits, regional or not. A German team with a local TeamCity gets exactly the same win as an Australian one.

// Good to know

How the toggle behaves

  • Default off for existing feeds. Feeds that already exist keep the classic behaviour on upgrade - staged on the server, downloaded through Jaws - so nothing changes until you opt in. The toggle is pre-selected for newly created feeds.
  • No fallback when it is on. A direct-download package is never staged in Germany, so if an agent cannot reach the feed the deploy fails with the real feed error. That is by design: the whole point is that your feed is reachable from your agents.
  • Keep your agents current. An agent from before this release cannot use direct downloads; against a direct-download feed it gets a clear "downloaded by agents directly from its feed" error instead of bytes. Update the fleet's agents before you switch the toggle on.
  • Agents cache locally. Each machine fetches a given package version from your feed once and caches it, so turning this on does not hammer your feed on every deploy.

Which should I use?

  • You push to the built-in Jaws feed and your servers are far from Germany -> set a regional package store on the workspace.
  • You deploy from your own feed (TeamCity / NuGet / artifact store) that sits near your agents -> turn on Allow direct downloads on that feed.
  • Both -> do both. They compose: Jaws-feed packages stay in-region, own-feed packages never leave your premises, and only login, UI, and orchestration talk to Germany.