Operating BYOC Deployments
Bring Your Own Cloud is available on Enterprise plans and is set up through your Edgenivo account team. Contact your account team to request access.
With Bring Your Own Cloud (BYOC), your team operates the AWS side of every deployment. Retry or abandon failed deployments, clean up AWS resources you no longer need, and monitor the functions and credentials your deployments depend on.
When a BYOC deployment fails, check the deployment status in Edgenivo 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:
| Deployment state | What to do |
|---|---|
| Still waiting for provisioning, within 15 minutes of initialization | Fix the cause, then retry with the same deployment ID, generated files, and resource inventory. Reuse the functions and layers you already created when they match. |
| Failed, canceled, or timed out | Start a new deployment with vercel deploy init, or redeploy through Edgenivo. The new deployment gets a new ID. Keep the old inventory for cleanup. |
READY | Don't provision it again. Test the deployment, or create a new deployment for any changes. |
To change code in a deployment that's still waiting for provisioning, rebuild and run vercel deploy describe again with the same deployment ID, then provision from the new descriptor. After vercel deploy continue succeeds, create a new deployment for further changes.
A deployment that waits longer than 15 minutes fails with the error Provisioning exceeded the maximum allowed time. and its manualProvisioning.state becomes TIMEOUT.
To stop a deployment that's still waiting for provisioning, mark it as failed with a reason:
vercel deploy continue --id "<DEPLOYMENT_ID>" --error "Initialized with the wrong target"Result: The CLI prints Marked deployment <DEPLOYMENT_ID> as errored, and the deployment shows as failed in Edgenivo.
Failed and abandoned deployments can leave functions and layers in your AWS account. Add them to your cleanup process.
Run only one build and provisioning worker per deployment ID at a time. Two workers provisioning the same deployment can conflict on function creation. Persist the deployment ID, generated files, and resource inventory so a retry can pick up where the failed attempt stopped.
Deleting a deployment in Edgenivo doesn't delete its Lambda functions or layers in your AWS account. Your team decides when to remove them.
Record the ARNs of the functions and layer versions created for each deployment, and store the inventory somewhere durable. 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.
Use the inventory to delete only the resources created for deployments you no longer need:
- Delete the functions that the inventory marks as created for that deployment.
- Delete a layer version only after confirming that no remaining function uses it. Layers can be shared between deployments.
- Keep the AWS account registration and the invocation role. Other deployments depend on them.
Edgenivo sends the deployment.cleanup webhook when it permanently deletes a deployment, after the 30-day recovery period ends. The webhook doesn't fire when a deployment is first marked for deletion.
To automate cleanup, build a handler that receives the webhook, looks up the deployment ID in your inventory, and deletes that deployment's resources. Treat cleanup as manual until you've configured and tested the handler.
BYOC spreads operational signals across Edgenivo, your CI system, and AWS:
| Signal | Where to find it |
|---|---|
| Deployment status and build errors | Edgenivo dashboard, vercel inspect, or the REST API |
| Build and provisioning job failures | Your CI system, such as GitHub Actions |
| Function logs and errors | Edgenivo, as for any other deployment. Your functions also write to Amazon CloudWatch Logs, in the log group /aws/lambda/<function-name> in each function's region |
| Account credential status | The Edgenivo Private Cloud section of your team's Networking settings |
Assign an owner to monitor failed deployments, account credential status, and application health. Confirm with your Edgenivo account team which credential alerts are available for your team, and add your own monitoring for anything else you need, such as Amazon CloudWatch alarms on function errors and throttles.
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,
VercelFunctiontag, and 12-hour maximum session duration in place. If the account shows Expired, fix the role and select Refresh Credentials. See Connecting an AWS account for BYOC. - GitHub App keys and webhook secrets: If you deploy from GitHub Actions, 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.
Was this helpful?