10 Common Myths Surrounding Atlassian Forge

Since the launch of Atlassian Forge in 2021, several persistent misunderstandings have taken root within the developer community. Some of these stem from the early beta phases, while others arise from comparisons with Connect where important nuances are overlooked. In this article, we clear up ten Forge myths and present facts, documentation, and practical examples from real-world app development.

Myth 1: Forge apps are too slow for enterprise applications

The Myth: Forge’s serverless architecture leads to cold starts and unpredictable response times that are unacceptable for productive enterprise environments.

The Reality: Cold starts do exist, but they mainly affect apps with very low traffic. With regular use, functions stay “warm” and react in milliseconds.

Concrete numbers:

Warm Functions: Response times typically range between 50-200 milliseconds.
Cold Start: An additional one to three seconds during the first request after a long period of inactivity.
UI Kit: Native rendering without iframe overhead, often faster than Connect.

Best Practice: For time-critical operations, you can use Scheduled Triggers to keep functions “warm” or implement asynchronous patterns where users do not have to wait for the result.

Practical Example: Apps like draw.io are migrating from Connect to Forge, demonstrating that even complex graphical applications can run on the platform.

Myth 2: Forge’s storage limits make enterprise apps impossible

The Myth: With limited storage per key and app, you cannot build real enterprise applications.

The Reality: These limits refer specifically to the native Key-Value Storage API, which supports up to 240 KiB per key. For larger data volumes, there are three established strategies:

Intelligent Partitioning: By cleverly splitting data across multiple keys, even large datasets can be managed. Instead of storing one giant JSON object, data is broken down into smaller, logical units.
Forge SQL (since 2024): A MySQL-compliant database (based on TiDB) suitable for relational data and complex queries. Note: the per-installation limit is 1 GiB, and some MySQL features like foreign keys and multi-statement queries are not supported.
Forge Remote: You can connect your own database infrastructure (AWS RDS, Azure SQL, On-Premise) while fully retaining Forge’s security advantages in the frontend.

Myth 3: With Forge, the team loses control over its app

The Myth: Atlassian hosts the app and can deactivate features, throttle performance, or take the app offline at any time.

The Reality: You retain full control over your app logic, deployment timing, and all business decisions. Atlassian simply provides the secure infrastructure.

What you control:

All deployments are handled by the development team.
You decide on version jumps and updates.
Your business logic remains proprietary.
You have access to logs and monitoring data.

What Atlassian manages:

Infrastructure updates and security patches.
Scaling of serverless resources.
Backup of Forge storage data.
Compliance certifications (SOC 2, ISO 27001).

The benefit for your team: You save on a large portion of infrastructure overhead and can focus on product development. Instead of worrying about server updates and scaling, you focus on features.

Myth 4: Forge is only suitable for simple apps

The Myth: Forge’s capabilities are limited to simple configuration dialogs and webhooks.

The Reality: Numerous complex, mission-critical enterprise apps run productively on Forge:

draw.io: A full diagram editor with canvas rendering, currently migrating to Forge.
Mria CRM: A complete CRM system within Jira featuring customer journey tracking.
Custom Workflow Engines: Multi-step approval processes with state machines and escalation logic.
BI Dashboards: Complex data visualizations with real-time updates.

Available Technologies:

Custom UI with a full React ecosystem.
WebGL and Canvas for graphical applications.
WebSockets (via Forge Remote).
Integration of external APIs (OpenAI, Stripe, AWS services).
Background jobs via Async Events and Scheduled Triggers.

Myth 5: UI Kit is too limited, Custom UI is too complex

The Myth: UI Kit doesn’t offer enough flexibility, and Custom UI is overcomplicated. There is no middle ground.

The Reality: Both approaches have their place and can even be combined within the same app.

UI Kit Use Cases: Ideal for admin configuration pages, simple forms, quick prototypes, and apps that need to stay consistent with Atlassian’s design.

Benefits: Native rendering (no iframe), automatic design updates, fast loading times, and accessibility out-of-the-box.

Custom UI Use Cases: Best for dashboards with complex visualizations, apps with their own brand identity, and canvas-based applications.

Benefits: Full control over HTML/CSS, access to the entire React ecosystem, and pixel-perfect design implementation.

Hybrid Approach: The “Gold Standard” is using UI Kit for settings and admin areas while using Custom UI for the main application features.

Myth 6: Debugging in Forge is impossible

The Myth: Without direct server access, production errors cannot be diagnosed.

The Reality: Forge offers comprehensive debugging tools that, while different from traditional server debugging, are often more efficient.

The Toolkit:

Forge Tunnel: Shows logs in real-time in your terminal during development while you test the app in the browser.
Production Logs: Access logs from all installations (if users consent) via the CLI.
Structured Logging: Implement JSON-based logging for better filtering and analysis.
Error Tracking: Integrate external services like Sentry or Rollbar via Forge Remote for professional error tracking with stack traces.

Myth 7: Forge apps cannot integrate external services

The Myth: The sandbox environment prevents communication with external APIs or services.

The Reality: Forge apps can communicate with external services in a controlled way. All outbound requests are restricted to domains declared in the app manifest, and undeclared destinations are blocked.

Integration Methods:

Direct API Calls: Use the Fetch API for any external REST API.
OAuth 2.0: Forge supports standardized OAuth flows for services like Google, Microsoft, and Salesforce.
Webhooks (Inbound): Your app can provide web triggers for external services to call.
Forge Remote: For complex scenarios, run your own backend (Python, Java, Go) and connect it to Forge.

Myth 8: Migrating from Connect to Forge requires a complete rewrite

The Myth: The team must rewrite existing Connect apps from scratch—a massive investment of weeks or months.

The Reality: Atlassian offers a hybrid approach called “Connect on Forge”, which enables a step-by-step migration.

The Migration Path:

Phase 1: Register Connect and Forge—your app continues to run on your infrastructure but is managed via the Forge manifest.
Phase 2: Migrate modules gradually (e.g., start with admin pages) while others remain on Connect.
Phase 3: Full Forge migration—only after all modules are tested do you shut down the Connect backend.

Myth 9: Forge apps will cost a fortune starting in 2026

The Myth: With the new consumption-based pricing starting in January 2026, costs will explode.

The Reality: For most apps, costs remain within the generous Free Tier or are significantly lower than hosting your own infrastructure.

The Free Tier includes (monthly per app):

100,000 GB-seconds of compute duration.
0.1 GB Key-Value Store reads + 0.1 GB writes.
1 GB log writes.
Forge SQL: 730 GB-hours stored data, 100,000 compute requests, 1 hour compute duration.

Beyond this, a pay-per-use approach applies. You only pay for what you actually use, with no fixed monthly costs for unused servers.

Myth 10: Atlassian is forcing everyone to Forge – Connect is being shut down

The Myth: Connect will be completely shut down by the end of 2026.

The Reality: Connect is not being “switched off” overnight, but it is entering end of support status, which is more significant than simple maintenance mode.

The Timeline:

September 2025: No new Connect apps accepted on the Marketplace.
End of March 2026: Connect apps can no longer update their descriptor (no new permissions, modules, or scopes). Private app installation via “Connected Apps” is also discontinued.
Q4 2026: Connect enters “use at your own risk” status. Only critical or security-related bugs will be patched. Integration points may become incompatible as Atlassian products evolve.

Atlassian provides “Connect on Forge” as a migration path, allowing teams to transition gradually rather than rewriting from scratch.

Evaluating Forge Based on Facts

Many Forge myths date back to the beta phase or result from an incomplete understanding of the platform. The reality is: Forge is a mature, production-ready solution that is suitable for enterprise applications if your development team plans the architecture correctly.

Evaluate Forge based on your specific requirements rather than community hearsay. Most teams that embrace the platform find it to be the technically and economically superior solution for the future.

Is your team planning a move to Forge? Do you want to modernize your app strategy? Our experienced Atlassian development teams can support you with architecture, development, and certification. Contact us via email or simply schedule an initial remote meeting with us!