How to configure jurisdictional geo-fencing in SkyeConnex
Set up per-account or per-company jurisdictional policy so uploads fail rather than degrade when residency cannot be guaranteed. Allow-list, block-list, and strict-mode patterns explained.
Geo-fencing is the platform's enforcement of which jurisdictions can hold shards of your data. The policy applies at upload time — shards are placed only in providers within the policy. Out-of-policy uploads either degrade (use whichever providers are eligible) or fail (strict mode).
This guide covers the three configuration modes, where to set them in the platform, how the effective-policy cascade resolves conflicts, and how to verify the policy is being enforced.
The procedure
-
STEP 01
Decide the policy mode
Three modes are available. Allow-list admits only the named jurisdictions for shard placement. Block-list excludes named jurisdictions; all others are eligible. Strict-mode is a modifier — when policy cannot be satisfied (e.g. you've allow-listed Canada and only 6 of 7 Canadian providers are healthy), strict-mode fails the upload rather than degrade to fewer-than-seven shards. Pick the mode that matches your regulatory regime: PIPEDA / PHIPA → allow-list Canada with strict-mode; SOC 2 → block-list politically high-risk jurisdictions; FedRAMP → allow-list US with strict-mode.
-
STEP 02
Open Company Settings → Geo Policy
From any page in the platform, navigate to Company Settings (top right, under your account menu). The Geo Policy tab shows the current effective policy with a cascade preview — you can see which settings came from reseller-level, company-level, or per-account configuration.
-
STEP 03
Configure the jurisdiction set
The jurisdiction list is sourced from the ISO 3166-1 alpha-2 country codes. For each jurisdiction you add to the allow-list (or block-list), the platform shows the providers currently active in that jurisdiction. Adding 'CA' shows AWS ca-central-1, OVH Beauharnois, Backblaze Canadian region, and any on-prem MinIO connexions you've declared as Canadian. The minimum allow-list to satisfy RS(5,2) is the number of jurisdictions needed to host 7 shards. If a single jurisdiction has ≥7 providers, one-jurisdiction allow-list works.
-
STEP 04
Set the strict-mode flag
The strict-mode toggle controls failure behaviour. With strict-mode off: a transient provider outage forces some shards into out-of-policy providers (degraded but accepted). With strict-mode on: the upload fails until policy can be satisfied. For regulated workloads, strict-mode on is the default expectation. The platform surfaces strict-mode failures as deep-linked remediation banners — the user sees what failed and one click takes them to the setting that fixes it.
-
STEP 05
Verify the policy is enforcing
Upload a test file. Open the file's flyout and the per-file SkyeMap. Confirm shard placement matches your allow-list. Generate a signed Sovereignty Audit report from Company Settings → Reports. The signed JSON includes per-shard residency with confidence grades (probed, declared, observed). Verify the report offline against our published issuer key using any FIPS 204 verifier.
Common questions
Can different accounts under the same company have different policies?
Yes, but with caveats. The effective-policy cascade resolves reseller → company → account. Per-account policy is allowed to be stricter than company; if it tries to be looser, the policy enforcer surfaces the conflict. The cascade preview in Company Settings shows where each setting resolved.
What happens to existing files when I tighten the policy?
Existing files are not re-distributed. The platform offers a one-action migration: schedule existing files to be re-shattered under the new policy. The migration runs as a background Celery task; progress shows in the admin dashboard. Files in flight are completed under the old policy then re-migrated.
Can I enforce per-folder policies?
Per-folder policy isn't a first-class primitive in v1.2, but the per-folder SkyeMap surfaces sovereignty drift at folder granularity. For per-folder enforcement, the typical pattern is a separate sub-account with its own policy.
Does geo-fencing affect read performance?
Not materially. Reads parallel-fetch all seven shards and return as soon as any five succeed — meaning the read pays the latency of the 5th-fastest provider, not the 7th. A wider geo-policy gives more provider choice; a narrower one means latency depends on the narrower set. For most allow-lists with ≥7 in-policy providers, the impact is negligible.
Want help configuring this?
A 45-minute briefing walks through this configuration on your tenant, live.