Managing deployments with VIP-CLI

Worker names identify deployments within an environment. Deploying a name that already exists updates that worker; using a new name creates another worker. Renaming a local worker does not remove the old deployment.

Building, validating, and deploying

1. Compile the example worker:

vip edge-workers build response-headers

The compiled artifact is written to build/response-headers.wasm.

2. Validate it against the develop environment:

vip @example-app.develop edge-workers validate response-headers

Validation builds the worker and sends its WASM to the server’s validator without creating or updating a deployment. It reports validity and detected phases. It does not execute test requests or establish routing, performance, or application correctness.

3. Deploy the worker:

vip @example-app.develop edge-workers deploy response-headers

By default, deployment builds and validates the worker, then prints the action, current and intended active state, request scope, phases, byte size, and source-storage behavior before uploading. Non-production deployment proceeds without an interactive approval prompt; review source and configuration before running it.

4. Inspect the deployed worker:

vip @example-app.develop edge-workers get response-headers

For a newly created worker, confirm that Active is no and that its scope and phases match the intended configuration.

5. Enable the worker when ready to test traffic:

curl -sS -D - -o /dev/null "https://<develop-domain>/edge-example/"

Replace <develop-domain> before running the command. Verify that the response includes x-edge-example: enabled. Test a path outside the configured scope, and exercise both cached and origin responses where applicable. Inspect the worker’s active state with get or list if the result differs from expectations.

Customers are responsible for reviewing and testing worker behavior before production use, including its effects on caching, access controls, redirects, and error handling.

Deployment and activation

Deployment does not disable an active worker. Uploading new code or configuration to an active worker makes that update live without a separate enable step.

To inspect an update before it handles requests, disable the existing worker before deploying. Disabling also removes its behavior from traffic while it is inactive; account for that when planning the change.

Production deploy and enable require confirmation unless --skip-confirmation is supplied. --enable requests activation; it does not bypass confirmation. A production deployment with --enable uses 1 confirmation covering both actions.

Inspecting, disabling, and deleting

List deployments in an environment:

vip @example-app.develop edge-workers list

Inspect the stored entry source along with a worker’s details:

vip @example-app.develop edge-workers get response-headers --source

Disable a worker to stop it handling requests while retaining its deployment:

vip @example-app.develop edge-workers disable response-headers

Delete a deployment when permanent removal is intended:

vip @example-app.develop edge-workers delete response-headers

Deletion prompts in every environment unless --force is supplied. It removes the remote worker, not its local source files.

Source storage and recovery

By default, deployment stores the UTF-8 entry source file alongside the binary. It does not archive imported modules, dependencies, or the complete project. get retrieves source only when --source is requested.

--skip-source omits source on creation and preserves the previously stored source on update. Preserved source can therefore differ from the newly deployed binary. Without that flag, deployment replaces the stored source, including when the entry file is empty.

Retain source, manifests, dependency lockfiles, and reviewed artifacts in the development workflow. The CLI does not provide an automatic rollback command. Recovery requires a reviewed known-good deployment or disabling the affected worker.

Multiple workers and automation

build without a name builds all workers. validate and deploy require a name or --all; a name and --all cannot be combined.

Bulk deployment prepares every selected worker before starting uploads. A preparation or validation failure makes no deployment changes. Uploads then run sequentially. If an upload or enable fails, earlier changes are retained and later workers are not attempted; there is no automatic rollback.

Automation must identify the target environment explicitly. VIP_NON_INTERACTIVE=1 prevents interactive Edge Workers production confirmation; it does not authorize a production change. Production deployment or enablement in that mode requires --skip-confirmation. Delete uses its separate --force flag. The documented command surface has no Edge Workers --non-interactive flag.

Available CLI options

--skip-build does not establish that an artifact matches current source. Use build, validation, and confirmation bypasses only when the skipped step has been handled separately. To inspect options for the installed version, run:

vip edge-workers deploy --help