Deploying with BYOC from GitHub Actions

Keep the Edgenivo Git integration for a Bring Your Own Cloud (BYOC) project, so every push creates a preview or production deployment that GitHub Actions builds, provisions in your AWS account, and completes.

This setup is optional. You can also run BYOC deployments from any CI system with the Edgenivo CLI flow.

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

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 that you host. The relay can run on any service that can receive the webhook. The setup on this page deploys it as 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: vercel build --id, vercel deploy describe, provisioning, and vercel deploy continue.

The workflow authenticates to Edgenivo and AWS with OpenID Connect (OIDC), which gives each run short-lived credentials without storing long-lived access keys for either service. Builds run separately from the AWS provisioning credentials.

The 15-minute provisioning window starts when Edgenivo creates the deployment, so time spent waiting in the GitHub Actions queue counts toward it.

• A working 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: a Lambda function, an AWS Secrets Manager secret, and IAM roles.
• 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 with npx skills add vercel-labs/vercel-byoc.

1. Generate the integration

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

   Prompt

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

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

   Piece	Purpose
   GitHub Actions workflow	Builds, describes, provisions, and continues each requested deployment
   Provisioning scripts	Create the Lambda layers and functions from descriptor.json
   Webhook relay	Receives deployment.build-requested and starts the workflow
   Infrastructure template	Creates the relay, its secret, and the AWS roles the workflow assumes through OIDC

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

2. Create and install the GitHub App

   The relay starts workflows through a GitHub App. Create it with these settings:

   1. Create a private GitHub App under the account or organization that owns the repository.
   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.

3. Deploy 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 the webhook signing secret in AWS Secrets Manager in your selected account and region, and grants the relay access to the secret.

   The agent then publishes the workflow on the repository's default branch and registers a project-specific Edgenivo webhook for deployment.build-requested 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: A GitHub Actions job can obtain temporary Edgenivo credentials and read the intended project.
   • AWS authentication: A GitHub Actions job can assume the provisioning role in the intended AWS account.

4. Turn on the BYOC Git flow

   Connect the project to the Edgenivo Git integration, or reuse an existing connection. Then turn on the BYOC Git flow by adding the manualProvisioning property to your project's vercel.json, keeping your other settings:

   vercel.json

   {
     "manualProvisioning": true
   }

   Alternatively, set the project environment variable VERCEL_MANUAL_PROVISIONING to 1 for each environment that should use the BYOC Git flow.

   You don't need either setting for the CLI flow.

5. Test preview and production deployments

   Push a new commit to a preview branch.

   Check:

   • The GitHub Actions workflow runs for the commit.
   • The Edgenivo deployment reaches READY.
   • 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.

   Repeat the test on your production branch to verify production deployments.

• Operate BYOC deployments, including retries, cleanup, and credential rotation
• Review the BYOC provisioning reference