How do I move off DigitalOcean App Platform Legacy Node.js Buildpack Migration without getting stuck?
Plan the move from DigitalOcean's deprecated legacy Node.js buildpack to the newer buildpack before old apps become harder to maintain.
Blockers
- replaces: package/heroku-nodejs-buildpack-325 → package/digitalocean-legacy-nodejs-buildpack
- Runs the package-manager build script automatically before any build_command.
- requires_version: package/heroku-nodejs-buildpack-325 → runtime/ubuntu-22
- Defaults to Node.js 22.x if no engine is pinned.
- Defaults to Node.js 20.x for Node.js v1 apps if no engine is specified.
- Defaults to Node.js 16.x for Node.js v0 apps if no engine is specified.
Who this is for
- low-ops
- small-team
- cost-sensitive
Candidates
Migrate existing apps to the new Heroku Node.js buildpack now
As of 2026-04-03, DigitalOcean marks the legacy Node.js buildpack as deprecated and says all new apps already use the new Node.js buildpack by default. Existing apps created before 2024-09-17 likely still use the legacy buildpack, and DigitalOcean recommends upgrading them by adding the feature flag "new-nodejs-buildpack=true" to the app spec. The new buildpack uses Heroku Node.js buildpack version "325" and defaults to Node.js "22.x" if no engine is pinned; the docs list Ubuntu-22 support through Node.js 25.4.0, 24.13.0, 22.22.0, and 20.20.0. App Platform pricing is unchanged by buildpack choice; as of 2026-04-03, paid containers still start at "$5.00" per month for "apps-s-1vcpu-0.5gb" and billing remains per second with a one-minute minimum.
When to choose
Use this for active production apps where security updates, current Node support, and lower long-term platform risk matter more than short-term migration effort. It is the default path unless your app is one of the documented non-upgradeable sample-app cases or your build pipeline depends on legacy build behavior.
Tradeoffs
Pros: current supported path, newer runtimes, security updates, custom caching, and alignment with DigitalOcean defaults. Cons: migration can surface build-script assumptions because the new buildpack runs the package-manager build script automatically.
Cautions
If your app currently uses a custom "build_command", DigitalOcean says to remove that field from the app spec and move the logic into the package "build" script, because the new buildpack already runs "npm run build", "yarn build", or "pnpm build" before any "build_command". Verify the current buildpack in the Control Panel first; if Build Phase shows "Node.js v0.4.1", the app is still on the legacy buildpack. If your spec still pins an old stack, also verify "buildpack-stack=ubuntu-22".
Keep the legacy buildpack temporarily only while clearing blockers
As of 2026-04-03, this is a temporary hold pattern, not the preferred steady state. DigitalOcean still documents the legacy buildpack, but labels it deprecated and explicitly tells users to use the new Heroku Node.js buildpack instead. The legacy path uses Node.js Cloud Native Buildpack version "0.4.0" and defaults to Node.js "20.x" for Node.js v1 apps and "16.x" for Node.js v0 apps if no engine is specified. App Platform's platform policy says deprecated stacks can keep functioning, but new deployments and builds eventually require upgrade to a newer stack.
When to choose
Use this only when migration is blocked by app-specific build behavior, by a staged validation window, or because the app is one of the documented sample-app categories that cannot upgrade. It is a short-term containment option, not a maintenance strategy.
Tradeoffs
Pros: avoids an immediate build-process change and buys time for test coverage or refactoring. Cons: you stay on a deprecated path with older defaults, narrower runtime support, and increasing maintenance risk as platform defaults move forward.
Cautions
DigitalOcean says sample apps for PHP, Python, Ruby, Ruby on Rails, Laravel, and Django only support the legacy Node.js buildpack and cannot be upgraded. The legacy docs also note Yarn v3 Plug'n'Play needs ".yarnrc.yml" with "nodeLinker: node-modules" because the buildpack expects "node_modules". Do not confuse legacy buildpack status with App Platform legacy pricing plans; buildpack choice does not itself change per-container pricing.
Sources
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "How do I move off DigitalOcean App Platform Legacy Node.js Buildpack Migration without getting stuck?"