BYOSA. Bring Your Own Storage Account¶
BYOSA lets a paying customer point AppGantry at a storage account they own and pay for. Build artifacts upload directly to that account, download directly from it, and never touch our infrastructure beyond the metadata row in our database.
Available on Business: not Team. Enterprise is coming soon.
For step-by-step Azure configuration, see the BYOSA setup guide.
What BYOSA gives you¶
1. A flat bill¶
Per-MB metering drops off your AppGantry invoice. You pay the platform fee on our side and your cloud provider's actual storage and egress rates on theirs. There is no AppGantry margin in the middle on the bytes.
2. Compliance¶
Some customers (finance, healthcare, government) can't let build artifacts (their unreleased apps!) live in another tenant's storage. BYOSA gives you tenancy isolation on the artifact data while we still run the metadata + control plane.
3. Geography¶
Pin your storage account to a specific Azure region for data residency. Our default hosted account lives in one region; yours can be anywhere Azure offers Blob Storage.
How it works¶
sequenceDiagram
participant Dev as Developer / CI
participant DF as AppGantry API
participant DB as AppGantry DB
participant ST as Customer's Azure Storage
participant T as Tester
Dev->>DF: POST /builds (request upload)
DF->>DB: insert build row
DF-->>Dev: signed direct-upload URL (to ST)
Dev->>ST: PUT artifact (direct)
Dev->>DF: POST /builds/{id}/complete
DF->>ST: HEAD blob (size check)
DF->>DB: mark build ready
T->>DF: GET install link
DF-->>T: signed download URL (to ST)
T->>ST: GET artifact (direct)
The artifact bytes never cross AppGantry's edge. Only metadata, signed-URL requests, and the upload-completion callback do.
What an org gives up¶
Mostly, predictability of the bill is replaced by predictability of the ceiling: you control the storage account, so you control retention, redundancy class, region, and cost.
| Concern | Hosted | BYOSA |
|---|---|---|
| Bill | Platform fee + per-MB usage | Platform fee flat; cloud bill at your provider |
| Redundancy | GRS (geo-redundant) | Your choice |
| Region | Our default region | Your choice |
| Mid-life migration | Trivial (already on hosted) | Ops-mediated; not via the public API |
| Disaster recovery | Our account failover | Yours |
Trade-offs to know¶
- BYOSA is Business only: not Team.
- An org is fully hosted or fully BYOSA: no mixed mode. Per-project BYOSA is on the roadmap.
- Mid-life migration (hosted → BYOSA after you've shipped builds) goes through our ops team with explicit data-copy steps. The public API refuses to flip it directly.
- Azure Blob Storage is supported in v1. AWS S3 BYOSA is planned; contact us if S3 is a blocker.
- Customer-managed encryption keys (CMK) on top of BYOSA are transparent to us. That's your storage account's responsibility.
Security boundary¶
- We auth into your tenant via a multi-tenant Azure AD app. You admin-consent it once. No customer secrets are shared with us; we hold no credentials of yours in our database.
- Our app is granted a role that lets it write blobs into a single container you create. Nothing else in your storage account, and nothing in any other resource group, is accessible.
- Activating BYOSA on an org is operator-mediated. The customer- facing API for BYOSA is read-only (GET config + diagnose-on-demand).
The full trust model lives in the public BYOSA setup guide.
See also¶
- BYOSA setup guide: Azure configuration.
- Plans & pricing: the pricing context BYOSA exists in.