GitHub Actions November 2025 changes are landing all at once: increased limits for reusable workflows, generally available M2 macOS runners, brownout windows for macOS 13 images ahead of a December 4 retirement, and the npm token migration deadline on November 19. If your CI/CD touches iOS builds or npm publishing, this week is your last mile to avoid surprise failures. Here’s a pragmatic plan to get through it.
What’s new in GitHub Actions November 2025
Let’s anchor on the highlights that affect real pipelines—not just the marketing line items.
First, reusable workflows got room to breathe. You can now nest up to 10 reusable workflows and make up to 50 total calls from a single run. For platform teams managing monorepos, that’s the difference between a brittle orchestration layer and something that scales across dozens of services.
Second, M2 macOS runners are generally available with labels you can drop in today: macos-15-xlarge, macos-14-xlarge, macos-13-xlarge, plus a macos-latest-xlarge that tracks the current default. If you’ve been squeezing Intel runners for iOS builds, the arm64 move usually cuts build times while trimming flaky simulator behavior—provided your toolchain is arm64-ready.
Third, the macOS 13 runner image has scheduled brownout windows through November (including today’s), and it’s fully retired on December 4. Jobs targeting macos-13, macos-13-large, or macos-13-xlarge will intermittently fail during brownouts and hard-fail after the retirement date.
Finally, npm classic tokens are being revoked on November 19. Classic token creation was disabled on November 5, and write-capable granular tokens now enforce 2FA by default with a maximum lifetime cap. If you publish from CI with classic tokens, your release pipeline will break after the cutoff unless you switch to granular tokens or OIDC-based Trusted Publishing.
Why this matters for your lead time and error budgets
Here’s the thing: none of these changes are theoretical. Brownouts interrupt on-call rotations and release trains. Token revocations break publish steps mid-sprint. And orchestration limits shape how you refactor a pipeline. If you own a platform backlog, this week’s work directly affects MTTR, release velocity, and developer trust—especially for mobile teams shipping iOS updates on tight app store windows.
macOS 13 runner deprecation: dates, labels, and quick exits
Key dates to circle: brownouts hit in defined windows this month, and the macOS 13 image retires on December 4. If you’re still on macos-13* labels, swap now to macos-15 or macos-latest (both arm64), or macos-14 if you need a trailing baseline while you sort dependencies. Expect faster builds on M2—often 10–30% in practice—once you purge Intel-only bits.
Common tripwires when you move to arm64:
- Homebrew paths and bottles: ensure brew installs target arm64 (no lingering Rosetta shims). Reinstall toolchains rather than copying caches built on Intel.
- Node, Python, and Ruby: pin arm64-native versions. If you use asdf or Volta/nvm, rebuild global modules; native extensions must be recompiled.
- Mobile SDKs: verify Xcode version alignment and Simulator availability on the new image; clean DerivedData to avoid linker mismatches.
- Binary tools: if you rely on prebuilt CLIs, confirm arm64 releases exist. If not, build from source or run via Rosetta only as a last resort.
Minimal YAML changes can get you green quickly: switch labels to macos-15 (or macos-latest), clear caches tied to Intel artifacts, and rebootstrap toolchains. If you’re juggling multiple workflows, consolidate the label change via a reusable workflow so you don’t miss any callers.
People also ask: How do I migrate off macOS 13 runners fast?
Do it in three passes:
- Discovery: search the repo for macos-13 and macos-13-* labels; inventory caches named with arch or Xcode versions.
- Switch and isolate: move labels to macos-15 (or macos-latest), disable or rename caches for a clean rebuild, and explicitly install arm64 toolchains.
- Stabilize: add a temporary retry on flaky simulator steps, then profile the longest jobs and split them using the increased reusable workflow limits.
If you need a deeper breakdown on November’s Actions changes, we published a focused walkthrough in what changed now and a practitioner’s take in changes that matter. For platform leads, the new limits and M2 runners brief includes planning notes you can copy into your runbooks.
npm token migration: what breaks on November 19
On November 19, classic npm tokens stop working. Many teams tucked a classic token into a GitHub Actions secret months (or years) ago and forgot about it. Those publish steps will start failing. Granular tokens with write permissions now enforce 2FA by default and carry shorter maximum lifetimes, while CI/CD scenarios can either use a Bypass 2FA setting or, better, move to OIDC-based Trusted Publishing to avoid long-lived secrets altogether.
Core takeaways:
- Classic tokens can’t be created anymore and are revoked on November 19; do not wait to rotate.
- Granular tokens are scoped and time-bounded; plan rotation and permission minimization.
- OIDC Trusted Publishing removes static secrets and is the safest long-term path for orgs.
We’ve been following this closely—see our zero-fluff breakdowns on everything to fix by Nov 19, what will break on Nov 19, and the cutover playbook. If your pipelines involve GitHub Actions, tie your npm rotation into the same change window as your macOS label switch to reduce coordination overhead.
People also ask: Will npm classic tokens still work after Nov 19?
No. Plan on failure states as if the token were deleted. Your job is to detect, rotate, and harden before that happens.
Reusable workflows: new limits, new patterns
The jump to 10 nested reusable workflows and 50 calls unlocks cleaner architecture for platform teams. Practical use cases:
- Monorepo orchestration: a top-level workflow can fan out to dozens of service-specific jobs via reusable calls without hitting old ceilings.
- Policy as code: call a standardized security scan or SBOM generation workflow from every pipeline instead of copy-pasting steps.
- Mobile matrix: encapsulate Xcode bootstrapping, CocoaPods/Carthage installs, and cache hygiene into a reusable unit referenced by each app target.
But there’s a catch: with more indirection, debugging gets trickier. Enforce consistent inputs/outputs contracts, version your reusable workflows, and log key environment details (runner image, Xcode, Node, Java) at each boundary so on-call engineers aren’t spelunking for root cause at 2 a.m.
Cache eviction is getting stricter—avoid thrashing
Actions enforces a 10 GB per-repo cache budget and is increasing eviction frequency to hourly. If you blow through 10 GB in a day with large DerivedData or node_modules caches, you may see more churn. Best practice: split caches by toolchain and version (for example, cache CocoaPods separately from DerivedData), compress aggressively, and prefer smaller, targeted caches over a single mega-cache. Store artifacts (not caches) for cross-job needs and purge caches on major image or Xcode jumps.
Security posture: tokens, 2FA, and OIDC
Zooming out, this month’s changes are pushing everyone to reduce blast radius. Granular access tokens, 2FA defaults, and shorter lifetimes are good frictions. If your org hasn’t adopted OIDC yet, make it the default for any external system that supports it—npm, cloud providers, artifact registries. OIDC shortens the time-to-revoke story from “hunt the secret across repos” to “disable a trust policy.”
Let’s get practical: the 90‑minute cutover checklist
Use this during your next change window. It’s sequenced to minimize time-to-green, then harden.
1) Find breakpoints fast
- Search your org for macos-13 labels and for npm tokens in Actions secrets named NPM_TOKEN, NPM_AUTH_TOKEN, or similar.
- List workflows calling npm publish or any package manager publish step.
- Flag repos that use reusable workflows so a single change fixes many callers.
2) Switch runners, clear caches
- Change all macos-13* labels to macos-15 or macos-latest.
- Invalidate caches tied to Intel artifacts; rebuild tools on arm64 cleanly.
- Pin Xcode and SDK versions explicitly to reduce variability.
3) Rotate npm auth
- Replace classic tokens with granular tokens that have the minimum permissions and a short lifetime; store them in repo or org secrets with a clear expiry note.
- Where possible, adopt OIDC Trusted Publishing and remove static tokens entirely.
- Add publication dry-runs in non-default branches to validate before production release.
4) Stabilize and observe
- Enable job summaries with version stamps (Xcode, Node, Java, CocoaPods, fastlane) on every run.
- Turn on annotations for flaky tests and set a temporary auto-retry for simulator jobs while the dust settles.
- Split the longest jobs using the expanded reusable workflow limits; parallelize where safe.
5) Close the security loop
- Delete any orphaned classic tokens; document rotation owners and dates.
- Enable 2FA org-wide and require it for write access to critical repos.
- Adopt least-privilege repository and environment permissions for Actions secrets and variables.
People also ask: Do I have to move to OIDC now?
No—but you probably should schedule it. Granular tokens work, and the Bypass 2FA setting exists for CI, but OIDC eliminates a class of mistakes. If you’re short on time, rotate to granular tokens now and create an issue to move to OIDC in your next sprint.
A short timeline to plan your week
Here’s a pragmatic view of the next few weeks:
- Today and next Tuesdays in November: expect macOS 13 brownout windows; plan around them or switch to macOS 15 now.
- By November 19: all npm classic tokens will be revoked; migrations must be complete.
- December 4: macOS 13 image retires; any remaining jobs on that label will fail hard.
If you paused on Copilot Extensions, note that they ended on November 10. We shared an MCP migration plan in this guide; it pairs well with the security posture work you’re doing for npm and OIDC.
Risks, edge cases, and how to think about them
Edge cases to anticipate:
- Private dependency hosts: if your npm publish also syncs to an internal registry, ensure those servers accept OIDC or rotated tokens; don’t break your internal distribution step.
- Binary plugins: some CI-only tools provide Intel-only binaries; replace them or temporarily run via Rosetta with a clear deprecation timeline.
- Monorepo churn: raising limits is great, but callers might still assume the old caps; audit your reusable workflow references and update version tags.
- Cache key drift: after the arm64 move, cache keys change; accept the cold-start cost rather than forcing cache reuse that drags Intel artifacts across architectures.
What to do next (developers)
- Open a PR that: switches macOS labels to arm64, adds a job summary of tool versions, and rotates NPM_TOKEN usage to a granular token or OIDC.
- Run a dry-run publish from a protected branch; watch for 401/403 errors and fix scopes/permissions immediately.
- Refactor long jobs into reusable workflows, taking advantage of the 10 nesting and 50 call limits for better parallelization.
What to do next (engineering managers and owners)
- Schedule a 90-minute maintenance window this week and staff it with one platform engineer and one app lead.
- Track three metrics for the next two weeks: iOS job success rate, median build time, and publish success rate. Alert on deviations over 10%.
- Document token rotation ownership and renewal cadence; make OIDC the default in your engineering handbook.
Need a second set of eyes?
If you want help prioritizing or you’re running a complex monorepo with dozens of mobile targets, our team has been guiding clients through these exact changes. Check our recent work, review CI/CD services, or reach out via contacts. We’ll map a zero-downtime plan and leave you with playbooks your team can run without us.
FAQ: quick answers for on-call
Can I keep Intel-only tools on M2 runners?
Temporarily via Rosetta, but expect performance hits and subtle failures. The right fix is switching to arm64-native binaries or rebuilding from source.
Do granular tokens really require 2FA?
Yes, for write scopes by default. CI can use a Bypass 2FA setting, but OIDC Trusted Publishing removes static secrets altogether and is preferred for security and compliance.
Are the new reusable workflow limits global or per run?
They apply per run: up to 10 nested reusable workflows and up to 50 total calls from that run. Design with those ceilings in mind to avoid orchestration failure modes.
Should I pin macOS 15 or use macOS-latest?
Pin a known-good version during this change window for predictability (for example, macos-15). Move back to macos-latest after you’ve stabilized and added version logging.
The bottom line
November packs real operational risk: brownouts today, token revocations next week, and a hard retirement in early December. The upside is tangible—faster macOS builds on M2, cleaner security with OIDC, and saner pipeline composition with expanded reusable workflow limits. Make the label switch, rotate auth, and capitalize on the limits boost while you’re in the files. Your future self—and your release train—will thank you.
