BYOC Provisioning Reference

A Bring Your Own Cloud (BYOC) provisioning tool reads the files that vercel deploy describe generates and creates matching AWS Lambda layers and functions in your account. Use this reference to build or audit a provisioning tool, whether you use Terraform, the AWS SDK, the AWS CLI, or a script generated by the BYOC agent skill.

vercel deploy describe --id <deployment-id> --aws-account-id <aws-account-id> writes these files:

vercel deploy describe creates the .vercel/<deployment-id>/ directory with owner-only permissions (0700) and writes descriptor.json and the function ZIP files with mode 0600. Function ZIP files include your application code and the deployment's environment variables, so keep them private in CI artifacts and caches.

If you run vercel deploy describe again for the same deployment, it reads the original build from .vercel/<deployment-id>/build/ instead of the code-free .vercel/output.

The descriptor file, descriptor.json, describes every Lambda layer and function to create for one deployment.

A deployment that runs in several regions has one functions entry per function per region.

configuration uses the parameter names of the AWS Lambda CreateFunction API, so you can pass it to the API with only the role, code, and layers added.

configuration never contains Role, Code, or Layers. Your provisioning tool supplies them:

This example shows the structure of a descriptor for one function in one region. Generated values differ for every deployment:

{
  "version": 1,
  "deploymentId": "dpl_1234567890abcdefghij",
  "awsAccountId": "<AWS_ACCOUNT_ID>",
  "layers": {
    "example_layer_key": "layers/example_layer_sha256.zip"
  },
  "functions": [
    {
      "code": "zips/example_function_sha256.zip",
      "region": "us-east-1",
      "layers": ["example_layer_key"],
      "configuration": {
        "FunctionName": "example_function_name",
        "Handler": "example_handler",
        "Runtime": "nodejs22.x",
        "MemorySize": 1024,
        "Timeout": 300,
        "Architectures": ["x86_64"],
        "Environment": {
          "Variables": {
            "EXAMPLE_VARIABLE": "example_value"
          }
        },
        "Tags": {
          "example_tag_key": "example_tag_value"
        }
      }
    }
  ]
}

A provisioning tool must do the following for every deployment:

1. Publish layers per region: For each region that a function uses, publish every layer it references. Use the layer key as the layer name, and reuse an existing layer version when its code hash matches the ZIP file.
2. Create functions: Create each function in its region with its configuration, plus Role, Code, and Layers.
3. Wait for Active: Wait until every function reaches the Lambda Active state before running vercel deploy continue.
4. Grant invocation: Make sure the invocation role allows lambda:InvokeFunction on every created function.
5. Record an inventory: Save the ARNs of the functions and layer versions you created, so you can retry and clean up later.

Finish steps 1 to 4 and run vercel deploy continue within 15 minutes of vercel deploy init.

Edgenivo invokes functions by their generated names, and your build depends on the generated runtime settings. Keep these values exactly as they appear in the descriptor:

• FunctionName
• Handler
• Runtime, Architectures, MemorySize, Timeout, and EphemeralStorage
• Environment.Variables
• Tags
• The layer order in layers

You can add settings that the descriptor doesn't define, such as a VPC configuration, additional layers, or extra tags, through your provisioning tool. If you attach functions to a VPC, give the execution role the permissions Lambda needs to manage network interfaces, such as the AWS managed policy AWSLambdaVPCAccessExecutionRole, and route the subnets through a NAT gateway or equivalent egress.

A function with the same name can already exist, for example from an earlier attempt at the same deployment. Reuse an existing function only when its code hash and full configuration match the descriptor. Don't update or overwrite a function that differs, because it may serve another deployment that's still receiving traffic. Stop and investigate the conflict instead.

AWS Lambda accepts function ZIP files up to 50 MB when you upload them directly. For larger packages, upload the ZIP file to a private Amazon S3 bucket in the same region as the function and create the function from the bucket. The standard Edgenivo Functions bundle size limits still apply. See BYOC limitations.

The identity that runs your provisioning tool needs permission to publish layers, create and read functions, tag them, and pass the execution role to Lambda. This example policy covers those actions. Replace <AWS_ACCOUNT_ID> with your AWS account ID and byoc-lambda-execution with your execution role name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageByocLayers",
      "Effect": "Allow",
      "Action": [
        "lambda:ListLayerVersions",
        "lambda:GetLayerVersion",
        "lambda:PublishLayerVersion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ManageByocFunctions",
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:TagResource"
      ],
      "Resource": "arn:aws:lambda:*:<AWS_ACCOUNT_ID>:function:*"
    },
    {
      "Sid": "PassExecutionRole",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/byoc-lambda-execution",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "lambda.amazonaws.com"
        }
      }
    }
  ]
}

Add s3:PutObject and s3:GetObject on your staging bucket if you upload large packages through Amazon S3, and lambda:DeleteFunction and lambda:DeleteLayerVersion if the same identity runs cleanup. Don't grant AdministratorAccess to the provisioning identity.

The route mapping file, provision.json, maps each function route in your build to the Lambda function that serves it. Edgenivo reads it to decide which function to invoke for a request. Don't edit it.

A BYOC deployment includes a manualProvisioning object in the Edgenivo REST API deployment response, for example from GET /v13/deployments/{idOrUrl}. The deployment stays in the INITIALIZING state until you run vercel deploy continue.

vercel deploy describe requires Edgenivo CLI 62.7.0 or later. Use Edgenivo CLI 63.1.2 or later for BYOC deployments.

For webhook payloads, see the webhooks API reference.

• Deploying with BYOC using the Edgenivo CLI
• Operating BYOC deployments
• AWS Lambda CreateFunction API