Forge CLI Legacy Template URL: End of Support Nov 26, 2026
Atlassian's legacy Forge templates URL reaches end of support on November 26, 2026, and the named affected segments are older CLI versions and enterprise firewall allowlist environments. Here is the pre-deadline checklist.
If you build Atlassian Forge apps from behind a corporate firewall, there is a dated entry for your calendar. Atlassian has deprecated the legacy Forge templates CDN URL, with end of support on November 26, 2026. The named affected segments are older Forge CLI versions and enterprise firewall allow-list environments, and both tend to break quietly rather than loudly.
What to verify before November 26, 2026#
Start with the checklist. Everything else in this post explains why each line matters, but you can run this today without reading further.
Pre-deadline verification checklist
- CLI versions: run
forge --versionon every developer machine and every CI runner that scaffolds or deploys Forge apps. Flag anything on an older version. - Template URL usage: search internal scripts, onboarding docs, and golden-path templates for any reference to the legacy templates URL.
- Outbound allowlist: diff your firewall and proxy allowlist against the current outbound host list in Atlassian's corporate-network documentation.
- Proxy configuration: confirm the proxy settings your CLI sessions actually use, on laptops and in CI, match what your network team thinks is deployed.
- Clean-environment test: run
forge createfrom a fresh container or VM inside the corporate network and confirm templates fetch. - Ownership: name one owner per environment for this cutover, plus a re-check date, since the allowlist can drift again after you fix it.
Why the clean environment matters
A forge create that works on a laptop with cached templates or an open network path proves nothing about your locked-down build environment. Test where the restrictions actually apply.
What ends on November 26, 2026, and who is affected#
Atlassian announced the deprecation of the legacy Forge templates CDN URL, the endpoint older CLI setups use to fetch project templates during forge create. End of support for the old URL is November 26, 2026. This is not a vague wind-down: Atlassian's announcement gives a date and names the affected segments explicitly (see the Forge changelog).
| Segment | Why it is exposed | First check |
|---|---|---|
| Older Forge CLI versions | Older versions can still point at the legacy templates URL | forge --version on every machine and CI runner |
| Enterprise firewall allowlist environments | Allowlists pinned to old hosts keep working right up until the old URL loses support | Diff allowlist entries against Atlassian's current outbound host list |
| Solution Partners and multi-client teams | Each client network has its own proxy rules and its own drift | Inventory CLI versions and allowlists per client environment |
Jan 1, 2026
Forge billing begins: consumption-based charges above free allowances
Today
Deprecation window: legacy templates URL still supported
Nov 26, 2026
End of support for the legacy Forge templates URL
After
Older CLI versions and stale allowlists run on an unsupported path
Why strict allowlist environments break quietly#
The uncomfortable part of this change is buried in Atlassian's own corporate-network documentation. It notes that the outbound-host lists are updated periodically and may not exactly match the latest CLI behavior. In other words, the reference you allowlist against can lag the tool you are running. For an organization with a strict egress policy, that is a standing drift risk, not a one-time migration task.
The same documentation states that Forge CLI network troubleshooting depends on unique customer environments and support may be limited. Its worked examples include GraphQL connectivity failures such as ECONNRESET when the proxy or network setup is wrong. So when a blocked host turns into a broken build, the burden of diagnosis sits with your platform team, not with Atlassian support.
Community threads show what this looks like in practice. Developers report forge create failing to fetch templates, with Atlassian responders pointing to blocked proxy or network access (thread 66113). Others report forge tunnel being unusable because its ngrok dependency is blocked by corporate security, forcing slower redeploy-heavy workflows (thread 67961).
And a 2026 thread shows deployments failing after a Forge CLI upgrade even after npm updates (thread 98772). These teams were not careless; they were operating in exactly the environments Atlassian now names as affected.
The stakes changed in January
Forge billing started January 1, 2026, with consumption-based charges above free allowances. A blocked forge create or a failed deploy is no longer just developer friction on a free platform. It can delay revenue-linked releases on a paid one.
The cutover, step by step#
- 1
Audit CLI versions everywhere
Inventory every developer machine and CI runner that scaffolds or deploys Forge apps, and record the installed CLI version. The affected segment is 'older Forge CLI versions', so you cannot answer 'are we affected?' without this list.
- 2
Update the outbound allowlist
Pull the current outbound host list from Atlassian's corporate-network page and diff it against your firewall and proxy rules. Because Atlassian notes the published lists are updated periodically, schedule a recurring re-check instead of treating this as one-and-done.
- 3
Upgrade the Forge CLI
Move every machine and CI image to the latest CLI. Do it one environment at a time: community thread 98772 shows deployments failing after a CLI upgrade even with npm updates, so upgrade and verify in pairs rather than upgrading everything at once.
- 4
Verify forge create and forge deploy
From a clean environment inside the corporate network, run
forge createand confirm templates fetch, then confirm a deploy still succeeds. This is the only step that proves the other three worked.
1Audit CLI versions
every machine + CI runner
2Update allowlist
diff against current host list
3Upgrade CLI
one environment at a time
4Verify create + deploy
clean env, inside the network
A concrete verification pass#
# 1. Record the CLI version on every machine and CI runnerforge --version# 2. Upgrade the Forge CLI to the latest version# per Atlassian's install docs# 3. From a clean container inside the corporate network,# confirm templates fetch through your proxy and allowlistforge create# 4. Confirm a deploy still succeeds after the upgradeforge deploy
Treat the results as readiness states per environment, not as a single yes or no. A team with six client networks can be ready in four and blocked in two; the blocked two need a named owner and a re-check date. The same discipline works for any dated vendor change; the general version is our vendor deadline readiness process. If your stack also includes Zapier, note that Zap steps using OpenAI Assistants stop working on August 26, 2026, three months before this Forge date.
Common mistakes before a network cutover#
- Treating the allowlist as one-and-done. Atlassian says the outbound-host lists are updated periodically and may not exactly match the latest CLI behavior. An allowlist verified in July can drift by November.
- Upgrading laptops but not CI images. The CLI version that matters most is the one in your pipeline, because that is the one that deploys.
- Testing from an open network path. A passing
forge createon a machine outside the egress policy tells you nothing about the environment that will fail. - Assuming support will debug your network. Atlassian states troubleshooting depends on unique customer environments and support may be limited. Plan for self-service diagnosis.
- Finding the owner after the failure. If nobody owns the cutover per environment, the first person to learn about a stale allowlist is a developer with a broken build.
Frequently asked questions#
Why does forge create say it is unable to fetch templates on our corporate network?
Community threads (such as thread 66113) show this failure behind blocked proxy or network paths, with Atlassian responders pointing to blocked access as the cause. Check your proxy configuration and outbound allowlist first. After November 26, 2026, older CLI versions relying on the legacy templates URL are on an unsupported path, so an upgrade plus an allowlist review is the durable fix.
Is forge tunnel affected by the November 26, 2026 change too?
The dated change is specifically end of support for the legacy templates URL. But forge tunnel has its own corporate-network problem: community thread 67961 reports its ngrok dependency being blocked by corporate security, forcing slower redeploy-heavy workflows. Both share the same root cause: outbound network policy that was never mapped to the CLI's real behavior.
We upgraded the Forge CLI and deployments broke. Is that known?
There is community evidence for it: a 2026 thread (98772) reports post-upgrade deployment failures even after npm updates. That is why the safe pattern is upgrading one environment at a time and running a verification deploy immediately after, rather than upgrading every machine and pipeline in one sweep.
Does Forge billing change how urgent this is?
It raises the stakes. Forge billing started January 1, 2026 with consumption-based charges above free allowances, and Marketplace vendors ship revenue-linked releases through these same create and deploy flows. A blocked deploy now interferes with a paid platform.
Track the Forge cutover like any other deadline
Duefront keeps a retained inventory of your monitored surfaces, routes each environment to an owner, tracks readiness states, and sends Watcher digests as November 26 approaches. You get a stakeholder-ready readiness snapshot instead of a surprise on cutover week.