Issue
Twilio Serverless enforces a platform limit of 100 Function Versions per Build. When this limit is reached, attempts to create a new Build will fail with the following error:
[function_versions are limited to less than or equal to 100.] (error 20001, HTTP 400)
This article explains the nature of this limit, why it exists, and recommended architectural approaches for scaling beyond it.
When deploying a Twilio Serverless Service with a large number of Functions (for example, one Function per customer or clinic), you may encounter the following error during Build creation:
-
Error Message:
[function_versions are limited to less than or equal to 100.] -
Error Code:
20001 -
HTTP Status:
400
This prevents adding additional Functions to the Service and blocks further scaling within a single Service.
Product
Twilio Functions
Environment
Twilio Console
Cause
The 100 Function Versions per Build is a hard platform limit in Twilio Serverless. This limit is enforced globally to ensure platform stability and performance. It cannot be increased for individual accounts or services.
For reference, see: Twilio Serverless API Limits
Resolution
1. Splitting Across Multiple Services
If your use case requires more than 100 Functions, the recommended approach is to split your Functions across multiple Serverless Services. For example, group Functions logically (e.g., by customer segment, region, or feature set) to stay within the per-Service limit.
Considerations for Cross-Service Routing
- Latency: Routing between Functions in different Services introduces a minimal increase in latency due to the additional HTTP request.
- Authentication: You must manage authentication and authorization between Services, typically using environment variables or API keys.
- Error Handling: Implement robust error management and retries for cross-Service calls, as network issues can occasionally impact communication.
- Logical Grouping: Where possible, group related Functions to minimize the need for cross-Service calls.
2. Review and Refactor
- Consolidate Functions: If possible, refactor your code to reduce the total number of Functions (e.g., by parameterizing shared logic).
- Review Deployment Strategy: Consider whether all Functions need to be deployed as separate entities, or if some can be combined.
Example Scenario
A healthcare provider manages inbound call routing for 95 clinics, with one Function per clinic. Upon reaching 100 Functions, they are unable to add more clinics. The solution is to split clinics across multiple Services and handle routing/authentication between them as described above.
Additional Information
- This is a hard platform limit and cannot be raised by Twilio Support.
- For more details, see the Twilio Serverless API documentation.
Below you will find references to useful documents: