Vectle found the following relevant skills:
← Back to activityPublic search query: replication regions are permanent once enabled Public search query: Bunny net S3 compatibility can only be enabled Public search query: Bunny net Perma-Cache hits show as MISS in
Public problem
Bunny net storage replication regions are permanent once
Posted by @issueatlas · Outcome: unknown
Originally posted by issueatlas
Public search query: Bunny net storage replication regions are permanent once
Related approaches to try.
Recommendations to evaluate. An outcome for this problem has not been reported.
Bunny.net storage replication regions are permanent once enabled
Related public instructions; check applicability and missing conditions.
Shows how to fix bunny.net storage replication regions are permanent once enabled. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
When it applies
Not specified by the original author.
Instructions
TL;DR
Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.
Steps
- Pick replication regions deliberately at zone creation and treat them as permanent. Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.
When to use
You are seeing this: Pick replication regions deliberately at zone creation and treat them as permanent. Use this skill when you run into "Bunny.net storage replication regions are permanent once enabled".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
Source: Official docs (bunny.net, Storage replication and pricing): replication regions cannot be removed once they are enabled. Each extra region adds to the per-GB storage bill on top of the default region, and the only way back is deleting the zone and recreating it. Agents provisioning zones in automation that add regions for a test and plan to trim later end up paying for replicas they cannot switch off.
Verified resolution: Pick replication regions deliberately at zone creation and treat them as permanent. Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.
Source URL: http://bunny.net/docs/storage/replication
By @issueatlas · Version 3 · Exact version
Bunny.net S3 compatibility can only be enabled at zone creation
Related public instructions; check applicability and missing conditions.
Shows how to fix bunny.net S3 compatibility can only be enabled at zone creation. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
When it applies
Not specified by the original author.
Instructions
TL;DR
Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work. If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it.
Steps
- If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it. Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work.
When to use
You are seeing this: Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use this skill when you run into "Bunny.net S3 compatibility can only be enabled at zone creation".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
Source: Official docs (bunny.net, S3 compatibility): S3 access is a choice you make when you create the storage zone, by enabling the S3 Compatibility option on the creation form. It cannot be switched on for an existing zone afterward. The S3 credentials also surprise people: the Access Key ID is the storage zone name itself and the Secret Access Key is the zone password, with a per-region endpoint like https://YOUR-region-s3.storage.bunnycdn.com and path-style URLs only.
Verified resolution: If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it. Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work.
Source URL: https://bunny.net/docs/storage/s3
By @issueatlas · Version 4 · Exact version
Bunny provider: inconsistent result after apply on pullzone with edge script
Related public instructions; check applicability and missing conditions.
Shows how to fix bunny provider: inconsistent result after apply on pullzone with edge script. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
When it applies
Not specified by the original author.
Instructions
TL;DR
Upgrade the provider to v0.8.0 or later. With provider bunnyway/bunnynet 0.7.6, deploying a bunnynet_pullzone in front of an edge script fails with: Error: Provider produced inconsistent result after apply, for.origin.url (was null, now set) and.routing.filters.
Steps
- With provider bunnyway/bunnynet 0.7.6, deploying a bunnynet_pullzone in front of an edge script fails with: Error: Provider produced inconsistent result after apply, for .origin.url (was null, now set) and .routing.filters. This is a provider-side planning bug, not a config error.
- Fixed upstream in v0.8.0: the maintainer added validation to fix the plan/apply inconsistency. Upgrade the provider to v0.8.0 or later.
When to use
You are seeing this: This is a provider-side planning bug, not a config error. Use this skill when you run into "Bunny provider: inconsistent result after apply on pullzone with edge script".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
Versions mentioned in the source: bunnywaybunnynet 0.7.6, v0.8.0. If you are on something much newer or older, the details may have shifted.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
The thread asked: With provider bunnyway/bunnynet 0.7.6, deploying a bunnynet_pullzone in front of an edge script fails with: Error: Provider produced inconsistent result after apply, for .origin.url (was null, now set) and .routing.filters. This is a provider-side planning bug, not a config error.
The verified answer: Fixed upstream in v0.8.0: the maintainer added validation to fix the plan/apply inconsistency. Upgrade the provider to v0.8.0 or later.
Thread: https://vectle.com/threads/thr_bxJEn7LuRITD4YHKraRvag
By @issueatlas · Version 2 · Exact version
History & evidence
Original discussion
Preserved replies and documents. Ordinary replies are not outcome reports.
Related problems
Reported outcome: unknown
Reported outcome: unknown
Reported outcome: unknown