Fastly Compute Deployment Debugging
Problem
After deploying to Fastly Compute, requests return stale content or 404s even though:
fastly compute publish reported success- The new version shows as "active" in
fastly service-version list
- The code is correct and works locally
Context / Trigger Conditions
- Version endpoint returns old version string after deployment
- New routes/features return 404
fastly purge --all doesn't fix the issue- Requests with cache buster (
?v=random) work but regular requests don't
fastly domain list doesn't show your custom domain- Different POPs return different results
Solution
1. Verify Code is Actually Deployed
# Check the direct edgecompute.app URL (bypasses custom domain config)
curl https://your-service.edgecompute.app/version
# Compare to custom domain
curl https://your-custom-domain.com/version
If edgecompute.app works but custom domain doesn't, it's a domain configuration issue.
2. Diagnose Cached Error Responses
The most common issue: 404s get cached at edge POPs before new code propagates.
# Test with cache buster
curl "https://your-domain.com/endpoint?bust=$RANDOM"
# Test without
curl "https://your-domain.com/endpoint"
If cache-busted works but regular doesn't = cached error response.
Fix: Wait 2-5 minutes for full propagation, then purge:
fastly purge --all --service-id YOUR_SERVICE_ID
3. Check Domain Configuration (Two APIs!)
Fastly has TWO domain management systems:
| System | CLI Command | API Endpoint |
|---|
| Classic Domains | fastly domain list | /service/{id}/version/{ver}/domain |
| Versionless Domains | (not shown in CLI) | /domain-management/v1/domains |
If fastly domain list doesn't show your domain, check the versionless API:
# Get your API token
TOKEN=$(fastly profile token)
# Query domain-management API
curl -s -H "Fastly-Key: $TOKEN" \
"https://api.fastly.com/domain-management/v1/domains?filter%5Bfqdn%5D=your-domain.com"
Look for "activated": true and "verified": true.
4. Force Clean Rebuild
If build caching is suspected:
rm -rf pkg target
fastly compute publish --comment "clean build"
5. Wait for Propagation
Fastly Compute deployments can take 2-5 minutes to propagate to all POPs worldwide.
Even after fastly service-version list shows the version as active, some POPs may
still serve old code.
Timeline:
- Version marked "active": ~30 seconds
- Most POPs updated: ~1-2 minutes
- All POPs updated: ~3-5 minutes (sometimes longer)
6. Check Real-time Logs
fastly log-tail --service-id YOUR_SERVICE_ID
Then make a request and see if it appears. If no logs appear, the request isn't
reaching your Compute code (likely a domain/routing issue).
Verification
After waiting and purging:
# Multiple requests to hit different POPs
for i in 1 2 3 4 5; do
curl -s "https://your-domain.com/version"
sleep 1
done
All should return the new version.
Example
Scenario: Deployed thumbnail serving code, but /hash.jpg returns 404.
Debug steps:
curl https://service.edgecompute.app/hash.jpg?v=123 → 200 (code works!)curl https://custom-domain.com/hash.jpg → 404 (cached)- Wait 3 minutes
fastly purge --all --service-id XXXcurl https://custom-domain.com/hash.jpg → 200 (working!)
Root cause: 404 was cached at edge before new code propagated.
Notes
- Accounts created before Sept 2025: May have classic domains, newer accounts use versionless
- Don't panic: If version check works on edgecompute.app, the code is deployed - just wait
- Purge timing: Purge AFTER propagation completes, not immediately after deploy
- POP variance: Different geographic POPs may propagate at different speeds
- Error caching: Fastly may cache 404/500 responses - this amplifies propagation issues
References