Repository navigation
Remotion Lambda: Allow customization of Lambda name, overriding recommendation #5911
Description
Allow callers to customize the Lambda function name and deploy multiple functions with the same configuration under distinct names. Remotion recommends reusing functions, but corporate policies can impose naming requirements or require resource isolation.
Current dependencies on the naming convention
Audited against Remotion 4.0.539, commit 0914e32587.
The generated name has this format:
remotion-render-{version}-mem{memory}mb-disk{disk}mb-{timeout}sec
| Area | Current limitation |
|---|---|
| Deployment and deduplication | deployFunction() always generates the standard name and exposes no override. It treats a function with matching Remotion version, memory, disk and timeout as already deployed. Supporting identical configurations under different names therefore requires changing both name generation and the existing-function check. Source |
| Discovery | getFunctions() only includes names beginning with remotion-render-. The complete format is not required for discovery: version compatibility is determined by invoking the function, and configuration comes from AWS. CLI automatic selection depends on this list. Source |
| Default IAM policies | The generated user policy scopes function management/invocation and log-group management to remotion-render-*. The execution-role policy also scopes worker invocations and log writes to that prefix. Custom names outside the prefix require corresponding permissions for both the caller and execution role. User policy, execution role |
| Fast progress polling | getRenderProgress({skipLambdaInvocation: true}) parses memory and timeout from the name and throws if it cannot parse it. Normal polling with skipLambdaInvocation: false already provides a fallback. Source |
| Cost estimates | Progress and final cost estimates parse memory from rendererFunctionName, falling back to the main function's memory. A custom renderer name can therefore produce inaccurate estimates when the main and renderer functions have different memory sizes. Progress, final estimate |
| Name prediction | speculateFunctionName() only generates the standard name. Callers using a custom name need to retain and pass that name explicitly. Source |
What already works
The ordinary rendering invocation path passes the supplied functionName directly to AWS without enforcing the naming convention. The function reads its own name from AWS_LAMBDA_FUNCTION_NAME. Invocation, runtime name.
The CLI accepts an explicit --function-name even when the function is absent from discovery, but warns that the workflow is unsupported. Source.
Custom-name support primarily needs deployment/deduplication, discovery and IAM changes. Fast polling and accurate estimates for differently sized renderer functions additionally need configuration metadata that does not depend on the name.
AWS's own naming constraints still apply: plain function names are limited to 64 characters and use letters, digits, hyphens and underscores. AWS reference.
Activity
[-]It should be possible to customize the Lambda function name or deploy multiple functions with the same name. It doesn't bring a benefit, but corporate policies do have naming requirements or require isolation of resources.[/-]