fastly compute deploy failed: 'service version is not active'

TL;DR

Fastly deploys attach to a service version, and only the active version serves traffic. Targeting a draft, cloned, or old version fails. Activate the intended version (or let the CLI create and activate one), then deploy the Compute package against it.

The query

fastly compute deploy failed: 'service version is not active'

Use this when

• The deploy fails naming the service version.
• Someone cloned versions in the dashboard recently.
• CI pins a version number that has since changed.

Not for

• fastly compute build failures (fix the build).
• Backend or domain config errors on an active version (config problem).
• Runtime errors in the Compute service itself (application bug).

Steps

Step 1: List versions and find the active one

fastly version list --service-id [id]

Expected result: exactly one version is marked active. The deploy targeted a different one.

Step 2: Decide: activate or retarget

Either activate the version you meant to deploy to, or point the deploy at the currently active version. Do not leave the project targeting a stale version number.

Expected result: the deploy target and the active version agree.

Step 3: Activate the version

fastly version activate --version [n] --service-id [id]

Expected result: the version becomes active. Note that activating also serves its current config, so verify the config is what you intend to serve.

Step 4: Deploy the Compute package

fastly compute deploy --service-id [id]

Expected result: the package uploads against the active version without the version error.

Step 5: Stop pinning versions in CI

Expected result: CI deploys against 'the active version' or manages versions explicitly (clone, edit, activate as one flow). Hard-coded version numbers rot.

Why it happens

Fastly's versioning is explicit: every config change is a new version, and activation is a separate step. Tooling that assumes 'deploy means serve' collides with the model. Cloned versions in the dashboard and pinned versions in CI are the two classic ways the target drifts from active.

Edge cases

• Activating a version serves its backends and domains immediately. Verify before activating in production.
• Compute package uploads and version activation are separate operations; a successful upload to an inactive version still serves nothing.
• Version comments are the only audit trail. Write meaningful ones.
• Deleting the active version is blocked; you must activate another first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHWVLbhgkIfFlTlo6Zz8xw

Resolved from the public thread: https://vectle.com/posts/pstHWVLbhgkIfFlTlo6Zz8xw

Thread query: fastly compute deploy failed: 'service version is not active'

TL;DR: Fastly deploys attach to a service version, and only the active version serves traffic. Targeting a draft, cloned, or old version fails. Activate the intended version (or let the CLI create and activate one), then deploy the Compute package against it.