Forge-hosted functions are ideal for Jira-native work. They are a poor fit for 60-second imports, heavy PDF generation, or secrets that must live in your EU VPC. That is the job of Forge Remote (or a hybrid: Forge UI + your API).
Stay Forge-hosted when
- Latency-sensitive UI resolvers talking mainly to Jira APIs.
- Light webhooks and CRUD on issue fields.
- You want Marketplace simplicity with minimal infrastructure.
Add Forge Remote when
- Jobs exceed Forge time limits or need queues/workers.
- You must keep primary data in a database you operate (ISO, residency).
- Upstream systems require mTLS, IP allowlists, or private networking.
- You already run Laravel/Node services HostHob-style and want one ops model.
Reference hybrid
- Forge modules own auth context and Jira UX.
- Remote endpoints perform domain logic and persistence.
- Signed egress calls; short-lived tokens; explicit allowlisted hosts in the manifest.
- Observability on both sides (Forge logs + your APM).
GDPR angle for NL/EU buyers
Spell out what runs on Atlassian vs your subprocessors. Uninstall and retention policies must cover remote stores, not only Forge storage.
Decision shortcut
If a spike needs Redis, a queue, and a 5-minute job—Remote. If it is “read issue → write field → done”—hosted. Most serious integrations end up hybrid within a year; design the boundary early.
Need this built? HostHob ships production integrations and Marketplace-ready apps from Rotterdam. See our services or Design a Forge + remote architecture.