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.
Two levers, adopt either or both
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