Upgrading Node.js for Twilio Functions

Twilio builds a v2 Service on Node.js v24 when you don't specify a runtime:

• New Services build on Node.js v24.
• Existing Services generally keep the runtime from their most recent successful Build. A Service that last built on Node.js v22 stays on v22 until you deploy with a different runtime.
• Already-deployed Functions keep executing on the runtime they were built with. Twilio doesn't migrate them for you.

There are exceptions: a Service that last built on an unsupported runtime fails to build, and an Assets-only deployment moves the Service to Node.js v24. For the full set of rules, see Possible side effects.

Functions (Classic) (v1) Services are unaffected and continue to default to Node.js v22.

Because the default applies only when you don't specify a runtime, the safest way to control which runtime your Functions use is to set it explicitly on every deployment. For more information, see the Possible side effects section of this page.

To choose the Node.js version for a Service explicitly, do one of the following:

• Use the Node Version dropdown in the Dependencies tab.
• Set the runtime parameter when creating a Build.
• Pass the runtime parameter when using the Serverless Toolkit.

The same mechanisms let you target node22 if your dependencies aren't ready for Node.js v24 yet. Node.js v22 is in Maintenance LTS, so plan to move to v24.

If your Service last built on Node.js v22 or earlier, use the following steps to move it to Node.js v24.

If you have built your application with the latest Functions Editor, you can update your Node.js runtime by following these steps:

1. Open the Dependencies tab of an existing Service that you wish to update.
2. Open the Node Version dropdown menu, and select Node.js v24.
3. Click the Deploy All button to build and deploy your Service. Once complete, all Functions within that Service will be running on Node.js v24.

If you are using the Serverless API to build and deploy your Services, you can update your Node.js runtime by creating a new Build of your Service with the runtime parameter set to node24.

Using the Twilio CLI and your own Service SID, the command will be:

1
twilio api:serverless:v1:services:builds:create \
2
    --service-sid ZSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
3
    --runtime node24

If you'd prefer to use an SDK to trigger this build, refer to the Build documentation for examples of how to trigger a build in every supported programming language.

Run twilio plugins to check your current version. To upgrade to the latest:

1
twilio plugins:remove @twilio-labs/plugin-serverless
2
twilio plugins:install @twilio-labs/plugin-serverless@latest

Open the .twilioserverlessrc configuration file at the root of your project and pin the runtime your Service is on today. To find it, deploy the Function in How do I verify that the upgrade was successful? and read process.version, or check the runtime property of the most recent Build that includes your Functions. For example:

1
{
2
  "runtime": "node22"
3
}

Pinning your current runtime means a deployment that doesn't name a runtime keeps using it, so you don't switch to Node.js v24 before you have verified it.

If you are working with multiple people or deploying as part of your CI/CD system, make sure that everyone in your team has the updated .twilioserverlessrc file, for example by pushing it to your version control system.

To trigger a new deployment with Node.js v24 you can use the --runtime flag. Ideally deploy to a new environment, so you can verify the functionality in isolation.

The deployment command will be:

twilio serverless:deploy --runtime node24 --environment verify-24

Your Functions will now be deployed and running on the Node.js v24 runtime in that environment.

Once you have verified your code with Node.js v24, you can update the .twilioserverlessrc file to use node24 as the runtime.

1
{
2
  "runtime": "node24"
3
}

That means any future deployments will use Node.js v24 even if you don't pass in the specific runtime using the --runtime flag.

Your runtime version of Node.js is exposed on the process.version variable, so creating, deploying, and calling a short Function like this will return the current version for verification purposes:

1
exports.handler = (context, event, callback) => {
2
  return callback(null, process.version);
3
};

The simplest way to upgrade is to start by using the new Functions editor.

1. Create a new Service in the New Functions editor.
2. Copy your Functions code into the new Service as new Functions.
3. Copy over any Environment Variables and Dependencies that your Function(s) use. If you copy over @twilio/runtime-handler, make sure it's at least 2.1.2 — see Node.js v24 requirements.
4. Deploy your new Functions by clicking Deploy All. Because the new Service has no previous Build, Twilio deploys your code on Node.js v24, the default runtime for v2 Services.
5. Test that your Functions work as expected in the new Service.
6. Optional: to use a different runtime, go to the Dependencies tab, select a version from the Node Version list, and click Deploy All for the change to take effect.

Be sure to update any references to your old Function (e.g. Studio Flows, Twilio number config) to use the new Function URL. You can copy your new Function URL by clicking Copy URL at the bottom right of the Function editor.

If you are using the API directly or the Serverless Toolkit, you might encounter side effects if you don't explicitly specify a runtime with each deployment.

If you don't specify a runtime when you create a Build, the API resolves one for you:

• If the Service has no previous successful Build, the API uses the default runtime for v2 Services, Node.js v24.
• If the Service's most recent successful Build used a supported runtime, the API reuses that runtime. That means if you successfully deployed your code with Node.js v24 once, later deployments that don't set a runtime use Node.js v24.
• If the Service's most recent successful Build used a runtime that is no longer supported, such as Node.js v20 or earlier, the Build fails with Error 82007 rather than falling back to Node.js v24. Set runtime explicitly to move off the earlier version.
• If the Build contains no Functions, such as an Assets-only deployment, the API uses Node.js v24 regardless of what the Service built on previously. That Build then becomes the Service's most recent successful Build, so the next deployment that includes Functions and doesn't set a runtime also uses Node.js v24. For example, a Service on Node.js v22 that deploys only Assets switches its Functions to Node.js v24 on the next Functions deployment.

To avoid these side effects:

• With the API: Always pass a runtime parameter when creating a Build
• With the Serverless Toolkit: Make sure to follow the steps outlined above, especially defining a default runtime in the .twilioserverlessrc file.