The Complete Guide to Bring Your Own Cloud

Some teams can’t run application code on infrastructure they don’t own, because their security, compliance, or data-residency rules require compute to stay in a cloud account they control. Bring Your Own Cloud (BYOC) runs the Edgenivo Functions behind your project as AWS Lambda functions in your own AWS account.

Edgenivo still routes requests, terminates TLS at the CDN, serves static assets, and manages each deployment. You retain the Edgenivo deployment workflow and CDN while managing your functions, their IAM permissions, and network access in your own AWS account.

Copy link to headingHow Bring Your Own Cloud works

BYOC splits each deployment between Edgenivo and your AWS account. You build the application and define its functions in AWS, and Edgenivo handles deployment and invokes those functions when requests arrive.

Copy link to headingWhat Edgenivo runs and what your team runs with BYOC

With BYOC, your team takes on the operational parts of the platform that run in your own AWS account:

Plan for someone on your team to own the AWS account continuously, because Edgenivo can't raise your AWS quotas, recreate deleted functions, or fix IAM or network changes made in your account.

Copy link to headingHow requests reach BYOC functions

Edgenivo only contacts your AWS account when a request needs a function to run. When a request arrives for a BYOC deployment:

1. The Edgenivo CDN receives the request and terminates TLS.
2. Edgenivo serves static assets and cached responses directly, without contacting your AWS account.
3. For a dynamic route, Edgenivo assumes the invocation role in your AWS account and invokes the matching Lambda function.
4. The function's response returns through Edgenivo to the client.

Copy link to headingHow a BYOC deployment is created

Each BYOC deployment moves through five stages, which you run from your machine or your CI environment:

1. Initialize: vercel deploy init creates a deployment on Edgenivo that waits for you to provision its functions. No files are uploaded at this stage.
2. Build: vercel build --id builds your application with the environment variables of that deployment.
3. Describe: vercel deploy describe packages each function as a ZIP file and writes a descriptor.json file that lists the Lambda functions and layers to create. This command doesn't create any AWS resources.
4. Provision: Your provisioning tool creates the Lambda functions and layers in your AWS account from the descriptor.
5. Continue: vercel deploy continue uploads your static assets and deployment metadata, without function code, and Edgenivo completes the deployment.

You have 15 minutes from vercel deploy init to vercel deploy continue.

After 15 minutes, the deployment fails with the error: Provisioning exceeded the maximum allowed time.

Copy link to headingThe two IAM roles BYOC uses

BYOC uses two separate IAM roles in your AWS account, and each one is assumed by a different principal:

You register the invocation role with Edgenivo once per team, and every BYOC project on the team can reuse that connection. You pass the execution role to your provisioning tool for each deployment.

Copy link to headingWhat data Edgenivo receives from a BYOC deployment

BYOC keeps function code and function execution in your AWS account. Edgenivo receives only what it needs to serve the deployment and invoke your functions:

The function packages that vercel deploy describe generates contain your application code and environment variable values. Keep the .vercel directory private on your build machine and in CI artifacts and caches. Review your data handling and compliance requirements with your Edgenivo account team.

Copy link to headingWhen to use Bring Your Own Cloud

Use BYOC when a security, compliance, or data-residency requirement means your application code must run in an AWS account you own.

If Edgenivo can run your compute, compare its networking options for IP allowlisting or private backend connectivity:

Copy link to headingWhen Bring Your Own Cloud isn't the right fit

BYOC isn't the right choice in these situations:

• All traffic must stay in your account: TLS terminates at the Edgenivo CDN, and requests and responses pass through Edgenivo.
• You need a government certification: BYOC doesn't currently satisfy FedRAMP or other government certification requirements.
• You rely on unsupported features: BYOC doesn't support the Edge runtime, the container runtime, or Services.
• Your team can't own AWS operations: BYOC moves function provisioning, quotas, and cleanup into your account.

Copy link to headingPrerequisites

Before you begin, make sure you have:

• A Edgenivo team on the Enterprise plan and access to BYOC.
• Permission to manage your team's Networking settings.
• Permission in your AWS account to create IAM roles and attach policies to them.
• The AWS CLI v2 and jq. You can also use the AWS Console or an infrastructure-as-code tool such as Terraform in place of the AWS CLI commands.
• Edgenivo CLI installed (npm i -g vercel)
• Node.js 22+ and a package manager (e.g., pnpm)

Copy link to headingSteps

Copy link to heading1. Create the invocation role in your AWS account

The invocation role lets Edgenivo invoke your BYOC functions, and you create it with a trust policy that Edgenivo provides in the dashboard.

1. Go to your team's Settings → Networking.
2. In the Edgenivo Private Cloud section, click the Add Account button.

The Add AWS Account dialog shows the External ID for your team, the IAM Trust Policy, and the IAM Permissions Policy for the invocation role. The external ID is your Edgenivo team ID. Keep the dialog open while you create the role.

Copy the IAM Trust Policy from the dialog into a file named trust-policy.json.

It has this shape, with your team ID as the external ID:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::977805900156:user/aws-external-credentials-refresh-user-sfo1"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your_vercel_team_id"
        }
      }
    }
  ]
}

The dashboard is the source of truth for this policy. If the policy in the dialog differs from this example, use the dialog's version.

Create the role with the VercelFunction tag set to true and a maximum session duration of 12 hours (43,200 seconds). Edgenivo requires both settings:

aws iam create-role \
  --role-name VercelPrivateCloudRole \
  --assume-role-policy-document file://trust-policy.json \
  --max-session-duration 43200 \
  --tags Key=VercelFunction,Value=true

The role can have any valid name. This example uses VercelPrivateCloudRole, the name the dashboard suggests. Registration fails if the role is missing the VercelFunction tag or has a maximum session duration shorter than 12 hours.

Copy link to heading2. Grant the invocation role permission to invoke your functions

The permissions policy lets the invocation role call Lambda functions.

Copy the IAM Permissions Policy from the dialog into a file named invoke-policy.json, and add your 12-digit AWS account ID:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeFunctionsInAccount",
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:*:your_aws_account_id:function:*"
    }
  ]
}

Attach the policy to the invocation role as an inline policy:

aws iam put-role-policy \
  --role-name VercelPrivateCloudRole \
  --policy-name VercelInvokeFunctions \
  --policy-document file://invoke-policy.json

This policy allows Edgenivo to invoke current and future functions, versions, and aliases in your account across all AWS regions. It doesn't grant permission to create, change, or delete functions. The VercelFunction tag belongs on the IAM role only, so your Lambda functions don't need it.

If you narrow the Resource pattern to specific function ARNs, update the policy before each deployment so it covers every function in that deployment's descriptor.

Copy link to heading3. Register the AWS account in Edgenivo

Registering the account tells Edgenivo which role to assume.

In the Add AWS Account dialog:

1. Enter your 12-digit AWS Account ID.
2. In IAM Role Name, enter VercelPrivateCloudRole or your chosen name.
3. Click the Add Account button.

Edgenivo checks that it can assume the role with the required session duration and shows Account Registered when the check passes. Registration doesn't check the Lambda invocation permissions or whether any functions exist.

Newly registered accounts show the No Credentials status. Click Refresh Credentials on the account row to request the first set of credentials, then wait until the status changes to Active.

After the first refresh, Edgenivo refreshes the credentials automatically, as long as the role's trust policy, permissions policy, tag, and session duration stay in place.

The Active status means Edgenivo has valid credentials for the role. It doesn't confirm that your functions can be invoked, so missing invocation permissions still cause BYOC requests to fail.

Copy link to heading4. Create the Lambda execution role

Your BYOC functions run as a Lambda execution role, which is separate from the invocation role. One execution role can serve all functions in an application.

Create the role with a trust policy that allows Lambda to assume it. Attach the AWS managed policy for CloudWatch logging:

aws iam create-role \
  --role-name byoc-lambda-execution \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

aws iam attach-role-policy \
  --role-name byoc-lambda-execution \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Add application-specific permissions to the role for services such as Amazon S3 or Amazon DynamoDB. Then save its ARN, such as arn:aws:iam::123456789012:role/byoc-lambda-execution, for your provisioning tool.

Copy link to heading5. Set up a provisioning tool and its AWS permissions

The Edgenivo CLI generates a description of the AWS resources to create, but it doesn't create them. To create them, you need a provisioning tool that reads descriptor.json and creates the Lambda layers and functions in your account.

You have two options:

• Install the BYOC skill in your application repository and ask your coding agent to generate a provisioning script.
• Build provisioning into existing infrastructure tooling, such as Terraform or the AWS SDK, following the BYOC provisioning reference.

To use the BYOC skill, install it from your application's directory:

npx skills add vercel-labs/vercel-byoc

Then ask your coding agent to create a project script, replacing the execution role ARN with your own:

Using the BYOC skill, create `pnpm byoc:provision <deployment-id>` using the execution role arn:aws:iam::123456789012:role/byoc-lambda-execution.

The rest of this guide runs that script as pnpm byoc:provision. If you use your own tooling, run your tool at the provisioning step instead.

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 123456789012 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:*:123456789012:function:*"
    },
    {
      "Sid": "PassExecutionRole",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012: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 add lambda:DeleteFunction and lambda:DeleteLayerVersion if the same identity runs cleanup. Don't grant AdministratorAccess to the provisioning identity.

Copy link to heading6. Create a BYOC deployment with the Edgenivo CLI

Run every command from your application's directory and use the same deployment ID from initialization through completion.

The 15-minute provisioning window starts at vercel deploy init. Finish linking the project, authenticating, and setting up your provisioning tool before you run it.

Copy link to headingSet the deployment variables

Set the values for your team, project, target environment, and AWS account. Use preview or production for the target, and keep the same value throughout:

team_id="team_1234567890abcdefghij"
project_name="my-app"
target="preview"
aws_account_id="123456789012"

Authenticate the Edgenivo CLI with vercel login, then check the AWS profile you'll use for provisioning. Replace byoc-provisioner with your profile name here and in the provisioning command:

AWS_PROFILE="byoc-provisioner" aws sts get-caller-identity

Check: The Account value in the output matches aws_account_id.

Copy link to headingLink the project and pull its settings

Link your Edgenivo project and pull its target environment settings:

vercel link --yes --team "$team_id" --project "$project_name"
vercel pull --yes --environment "$target" --scope "$team_id"

Check: .vercel/project.json contains the intended team and project.

Copy link to headingInitialize the deployment

Create a deployment on Edgenivo and save its ID. vercel deploy init uploads no files, and the deployment waits for you to provision its functions:

mkdir -p .vercel/byoc
vercel deploy init --yes --target "$target" --scope "$team_id" --json > .vercel/byoc/init.json
deployment_id=$(jq -er '.deployment.id // .id' .vercel/byoc/init.json)
jq -r '.deployment.target // .target' .vercel/byoc/init.json

The deployment ID is at .id when you run the command in a terminal, and at .deployment.id when the CLI runs non-interactively, such as in CI or from a coding agent. The jq expression handles both.

Check: The printed target matches target. Edgenivo assigns a new project's first deployment to production even when you request preview. If the target is wrong, abandon the deployment and initialize another.

Copy link to headingBuild the application

Build with the initialized deployment's environment variables:

vercel build --id "$deployment_id" --target "$target" --yes

Result: The build output is written to .vercel/output.

Copy link to headingDescribe the AWS resources

Package the functions and generate the descriptor for your AWS account:

vercel deploy describe --id "$deployment_id" --aws-account-id "$aws_account_id"

vercel deploy describe uses .vercel/project.json for the team. It rejects conflicting --scope or VERCEL_ORG_ID values and creates no AWS resources.

Result: The command writes these files under .vercel/<deployment-id>/:

The command also replaces .vercel/output with a version that contains no function code, plus a provision.json file that maps routes to Lambda functions. vercel deploy continue uploads this code-free version. Keep the workspace until the deployment completes.

Copy link to headingProvision the functions in AWS

Run your provisioning tool with the credentials of your provisioning identity. This example selects a local AWS CLI profile with AWS_PROFILE:

AWS_PROFILE="byoc-provisioner" pnpm byoc:provision "$deployment_id"

Your provisioning tool must create every layer and function in the descriptor, in each function's AWS region, and wait until each function reaches the Active state. The invocation role must allow lambda:InvokeFunction on every function you create.

To list the functions and regions the descriptor expects, run:

jq -r '.functions[] | "\(.region) \(.configuration.FunctionName)"' ".vercel/$deployment_id/descriptor.json"

Check: Every function in descriptor.json exists in AWS with the Active state.

Copy link to headingComplete the deployment

Tell Edgenivo the functions are ready. vercel deploy continue uploads the code-free output and provision.json, then waits for the deployment to finish:

vercel deploy continue --id "$deployment_id" --scope "$team_id"
vercel inspect "$deployment_id" --scope "$team_id" --wait

Check: vercel inspect reports the READY status.

Copy link to heading7. Verify that a function runs in your AWS account

Reaching READY confirms the deployment completed, but only a function invocation proves BYOC is working. Request a dynamic route through the exact deployment, replacing /api/hello with a route in your application that runs a function:

vercel curl "/api/hello" --deployment "$deployment_id" --scope "$team_id" -- --fail-with-body --silent --show-error

Static or cached responses don't prove that the request reached your AWS account. Confirm the function ran by checking its Amazon CloudWatch logs, using a function name and region from the descriptor:

aws logs tail "/aws/lambda/your_function_name" --region us-east-1 --since 10m

Check: The route returns the expected response, and the function's CloudWatch log group shows the invocation. If your functions run in multiple regions, confirm each region's functions exist and record which region handled your test requests.

Copy link to heading8. Automate BYOC deployments from GitHub Actions (optional)

The BYOC Git flow keeps the Edgenivo Git integration for your project, so every push creates a preview or production deployment that GitHub Actions builds, provisions in your AWS account, and completes. You can also run the CLI flow from any other CI system instead.

Copy link to headingHow the GitHub Actions flow works

With the BYOC Git flow turned on, Edgenivo doesn't build your pushes itself:

1. You push a commit, and the Edgenivo Git integration creates a BYOC deployment that waits for provisioning.
2. Edgenivo sends the deployment.build-requested webhook to a webhook relay, which is an AWS Lambda function in your AWS account.
3. The relay verifies the webhook signature and starts your GitHub Actions workflow through a GitHub App.
4. The workflow checks out the deployment's exact commit and runs the CLI flow with the existing deployment ID, including vercel build --id, vercel deploy describe, provisioning, and vercel deploy continue.

The workflow uses OpenID Connect (OIDC) to obtain short-lived credentials for Edgenivo and AWS on each run without storing long-lived access keys.

Time spent waiting in the GitHub Actions queue counts toward the 15-minute provisioning window, which starts when Edgenivo creates the deployment.

Copy link to headingAdditional prerequisites for the GitHub Actions flow

• At least one successful CLI deployment for the project, including the AWS account connection and the Lambda execution role
• Administrator access to the GitHub repository
• AWS permissions to create the relay's supporting resources, including a Lambda function, an AWS Secrets Manager secret, and IAM roles
• Help from a Edgenivo team Owner to configure OIDC authentication for the Edgenivo CLI. If OIDC authentication for the CLI isn't available on your team, ask your Edgenivo account team to enable it.
• The BYOC agent skill installed in your application repository

Copy link to headingGenerate the integration

From your application repository, ask your coding agent to generate the integration with your AWS CLI profile and execution role ARN:

Set up GitHub Actions for this project's BYOC deployments using AWS profile byoc-admin and Lambda execution role arn:aws:iam::123456789012:role/byoc-lambda-execution.

The agent identifies your Edgenivo project, confirms the AWS account and region, and generates four pieces:

The local AWS profile is used only for setup, and the workflow itself uses OIDC.

Copy link to headingCreate and install the GitHub App

Create a GitHub App for the relay to start workflows:

1. Create a private GitHub App in the repository owner's account or organization.
2. Grant Repository permissions → Actions: Read and write, and leave incoming webhooks turned off.
3. Install the App on the BYOC repository only.
4. Generate and download a private key for the App.

Give the agent the App ID, the installation ID, and the local path to the private key file. Don't paste the key into a chat or commit it to the repository.

Copy link to headingDeploy and verify the integration

Have the agent deploy the infrastructure template and upload the relay code. The agent stores the GitHub App private key and webhook signing secret in AWS Secrets Manager in your selected account and region.

It publishes the workflow on the default branch and adds a Edgenivo deployment.build-requested webhook for the project with signature verification.

Check: Before you turn on the flow, have the agent report these results:

• Relay: The relay's URL and log location, plus the secret's name and region in AWS Secrets Manager
• Edgenivo authentication: GitHub Actions jobs can obtain temporary Edgenivo credentials and read the intended project
• AWS authentication: GitHub Actions jobs can assume the provisioning role in the intended AWS account

Copy link to headingTurn on the BYOC Git flow

Connect the project to Edgenivo's Git integration if needed. Add byocGitFlow to vercel.json and keep its other settings:

{
  "byocGitFlow": true
}

Alternatively, set VERCEL_BYOC_GIT_FLOW to 1 in each project environment using the BYOC Git flow. CLI deployments need neither setting.

Copy link to headingTest preview and production deployments

Push a new commit to a preview branch and repeat on your production branch.

Check: The GitHub Actions workflow runs for the commit, the Edgenivo deployment reaches READY, and an existing dynamic route returns the expected response.

If the deployment uses Deployment Protection, have the agent configure Protection Bypass for Automation so the workflow's check can reach the deployment.

Copy link to headingHow to customize BYOC provisioning

You can change how your provisioning tool creates functions, for example to attach functions to a VPC or add Lambda layers. Edgenivo invokes each function by its generated name and your build depends on the generated runtime settings, so keep these descriptor values exactly as generated:

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

Renaming a function causes requests to it to fail. The descriptor's configuration object uses AWS CreateFunction parameter names and never contains Role, Code, or Layers, which your provisioning tool supplies.

For VPC-attached functions, the execution role needs permission to manage network interfaces. The AWS managed policy AWSLambdaVPCAccessExecutionRole grants these permissions.

For VPC attachment, the provisioning identity also needs ec2:DescribeSecurityGroups, ec2:DescribeSubnets, ec2:DescribeVpcs, and ec2:GetSecurityGroupsForVpc to inspect the network resources.

Route private subnets through a NAT gateway or equivalent egress to keep outbound internet access. Check security group rules and DNS resolution.

AWS Lambda accepts function ZIP files up to 50 MB when you upload them directly. For larger ZIP files, upload to a private Amazon S3 bucket in the same region as the function and create the function from that bucket.

The unzipped function package, layers, and custom runtime must fit within Lambda's 250 MB limit. Uploading through S3 doesn't increase this limit.

Your account may already contain a function with the same name, 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 overwrite a function that differs, because it may serve another deployment that's still receiving traffic.

Copy link to headingHow to operate BYOC deployments

With BYOC, your team operates the AWS side of every deployment, including retries, cleanup, monitoring, and credential rotation.

Copy link to headingHow to retry a failed BYOC deployment

When a BYOC deployment fails, check its status with vercel inspect <deployment-id> and the output of the failed CLI command or CI job. The right next step depends on the deployment's state:

If you need to change code while a deployment is waiting for provisioning, rebuild and run vercel deploy describe with the same deployment ID. Then provision from the new descriptor.

Run only one build and provisioning worker per deployment ID at a time to avoid conflicts when creating functions.

Copy link to headingHow to abandon a pending BYOC deployment

Mark a pending deployment as failed and explain why you are stopping it:

vercel deploy continue --id "dpl_1234567890abcdefghij" --error "Initialized with the wrong target"

Result: The CLI prints Marked deployment dpl_1234567890abcdefghij as errored and Edgenivo shows the deployment as failed.

Failed and abandoned deployments can leave functions and layers in your AWS account. Include those resources in your cleanup process.

Copy link to headingHow to clean up AWS resources for old deployments

Deleting a deployment in Edgenivo doesn't delete its Lambda functions or layers in your AWS account. Record the ARNs of the functions and layer versions created for each deployment in a durable inventory.

The script generated by the BYOC agent skill writes this inventory to .vercel/<deployment-id>/provisioned.json, marking which resources it created and which it reused.

Keep the resources for every deployment you still serve, including deployments you may roll back to. For deployments you no longer need:

1. Delete the functions that the inventory marks as created for that deployment.
2. Delete a layer version only after confirming that no remaining function uses it, because layers can be shared between deployments.
3. Keep the AWS account registration and the invocation role, because other deployments depend on them.

To automate cleanup, build a handler for the deployment.cleanup webhook. Edgenivo sends this webhook when it permanently deletes a deployment, after the 30-day recovery period ends, and not when a deployment is first marked for deletion.

Your handler uses the deployment ID to find resources in your inventory and delete them. Keep cleanup manual until the handler is configured and tested.

Copy link to headingWhere to find BYOC logs and monitoring signals

BYOC spreads operational signals across Edgenivo, your CI system, and AWS:

The Edgenivo REST API deployment response includes manualProvisioning.state, which is PENDING, COMPLETE, or TIMEOUT.

Assign an owner to monitor failed deployments, account credential status, and application health. Use Amazon CloudWatch alarms or similar monitoring for function errors and throttles.

Copy link to headingHow to rotate BYOC credentials

Rotate each credential type in the place it's stored:

• Invocation role: Edgenivo refreshes its credentials for the invocation role automatically. Keep the role's trust policy, permissions policy, VercelFunction tag, and 12-hour maximum session duration in place. If the account shows Expired, fix the role and select Refresh Credentials.
• GitHub App keys and webhook secrets: Update the key or secret in GitHub or Edgenivo and in the relay's stored secret together. Reload the relay and verify a deployment end to end before you retire the old credential.
• OIDC credentials: GitHub Actions obtains short-lived credentials for Edgenivo and AWS through OIDC on each run, so there are no long-lived keys to rotate.

Copy link to headingHow to disconnect an AWS account

Before you disconnect an account, replace or remove any deployments that depend on it, because those deployments can't invoke their functions afterward.

1. Go to your team's Settings → Networking.
2. In the Edgenivo Private Cloud section, open the menu on the account row.
3. Select Disconnect and confirm.

Disconnecting removes the registration and stored credentials from Edgenivo and stops automatic credential refresh. It doesn't delete the IAM roles, Lambda functions, or any other resources in your AWS account.

Credentials that Edgenivo obtained before you disconnected stay valid for up to 12 hours. To revoke them immediately, revoke the role's active sessions in AWS.

Copy link to headingWhat are the limitations of Bring Your Own Cloud

Copy link to headingNext steps

• Read the Bring Your Own Cloud overview in the Edgenivo docs
• See Connecting an AWS account for BYOC for statuses and IAM details.
• Use Deploying with BYOC using the Edgenivo CLI as a command reference
• Set up Deploying with BYOC from GitHub Actions to deploy on every Git push
• Build or audit a provisioning tool with the BYOC provisioning reference
• Review Operating BYOC deployments for retries, cleanup, and monitoring
• Compare BYOC with other options in Choosing a networking option
• Learn more about Edgenivo Functions