DECISION GUIDE · REVIEWED AUGUST 2, 2026
Forge-Hosted vs Remote Secret Scanners
Compare Atlassian-hosted and remote scanner architectures by trust boundary, egress, residency, operations, and capability trade-offs.
Short verdict
Forge-hosted architecture removes a vendor-operated processing boundary. Remote architecture adds responsibility but can support capabilities that require external infrastructure. Architecture is a trade-off, not a universal quality ranking.
Why this is not a “winner” page
Atlassian documents Forge Remote as a way for Forge frontends, functions, events, and scheduled triggers to call an Internet-accessible backend. Atlassian also states that remote services increase the partner’s responsibilities under the shared-responsibility model.
A remote can still implement region-specific endpoints and qualify for supported residency states. “Remote” therefore does not automatically mean “non-compliant”; it means the reviewer has another processor, logging path, availability dependency, and deletion lifecycle to examine.
Side-by-side comparison
| Decision criterion | Forge-hosted scanner | Remote-backed scanner | Evidence |
|---|---|---|---|
| Compute | Runs in Atlassian-managed Forge runtime. | Some processing runs on an Internet-accessible backend operated or selected by the app vendor. | Forge Remote essentials |
| Egress | Can be designed with no remote or external fetch declaration. | Content or metadata crosses to a declared remote for compute, storage, fetch, or other operations. | Forge remotes reference |
| Data residency | Forge persistent storage follows supported host-product residency behavior automatically. | Can qualify when region-specific URLs and required migration behavior are implemented. | Forge data residency |
| Operational responsibility | Atlassian operates runtime and hosted storage; the developer remains responsible for secure application behavior. | Vendor additionally operates backend authentication, isolation, logging, availability, deletion, and incident response. | Forge shared responsibility |
| Capability envelope | Bound by Forge runtime, storage, quotas, APIs, and supported modules. | Can add external models, databases, integrations, long-running services, or specialized infrastructure. | Forge Remote overview |
| Review burden | Review scopes, application logic, Forge storage, logging, and Atlassian’s platform controls. | Review all of the left side plus remote hosting, subprocessors, data flows, access, retention, and outages. | Runs on Atlassian |
Choose Forge-hosted scanner when
- Minimizing systems that receive potential credentials is the priority.
- Required features fit inside Forge’s supported capabilities.
- Runs on Atlassian eligibility is a procurement requirement.
Choose Remote-backed scanner when
- A necessary capability cannot be delivered within Forge.
- The vendor supplies adequate remote architecture, residency, retention, and assurance evidence.
- The additional boundary is accepted for a concrete functional benefit.
When using both is the stronger design
Some product portfolios legitimately contain both models. Evaluate the exact app version and manifest rather than assuming every product from one vendor shares the same data path.
Continue the evaluation
Evaluate with synthetic data before production
Inspect the public fixtures, review the architecture, then install on an Atlassian sandbox. Never use a live credential as a scanner test value.