Repo pool & rotation

Every backend caps how much one repository can comfortably hold: about 850 MB on GitHub, 9 GB on GitLab, 90 GiB on a Hugging Face dataset. If a vault were tied to one repo, that cap would be your ceiling. Instead, zcrypt keeps a pool of repositories per account and adds to it as needed.

The pool is scoped to a unique combination of (you, platform, account). Connect two GitHub accounts and each gets its own independent pool; they never share or contend.

At any moment, each pool has exactly one active repo that new chunks go to. The cycle is simple:

1. zcrypt uploads chunks to the active repo.
2. Before each upload it checks the active repo's tracked usage against the platform threshold.
3. When the active repo reaches its threshold, zcrypt deactivates it and auto-creates a new repository to become the active one.
4. New chunks flow into the new repo; the cycle repeats.

New repositories are created private and given a plausible, developer-looking name such as fast-cache-v3 or core-worker-v7, with a description like "Internal build artifacts and cache storage." Nothing in the repo hints that it belongs to an encrypted drive. On Telegram, which has no repos, the same logic spreads files across virtual storage locations in your channel instead.

Thresholds are deliberately conservative, sitting under each platform's real limits so uploads never bump into a hard wall mid-transfer.

Some platforms limit how fast you can push, not just how much you can store. GitHub, for instance, throttles sustained pushes at roughly 7 GB per hour. To avoid tripping that ceiling mid-transfer, zcrypt paces its own writes to each platform rather than hammering the API and getting rate-limited.

Before sending each chunk, the background sync worker checks a per-platform budget over a trailing one-hour window. If pushing the chunk would exceed the limit, the worker holds it just long enough for earlier bytes to age out of the window, then sends, so short bursts go straight through and only sustained, over-cap volume is slowed.

• •Only GitHub is throttled by default (~7 GB/hour); Telegram, GitLab, and Hugging Face are not rate-limited by zcrypt.
• •Budgets are tracked per platform, so saturating GitHub never slows a push to GitLab or Telegram.
• •The wait happens before a chunk claims a repo upload slot, so a throttled push never holds a slot idle or blocks other repos from making progress.

zcrypt records the encrypted bytes written to each repo as uploads complete, so the "is this repo full?" check is a fast database lookup rather than a live API call on every chunk. Usage is tracked per repo, which is what lets a pool know precisely when to rotate and lets your total capacity add up across all of them.

• •Bring your own storage: connect the accounts the pool draws on
• •Storage obfuscation: how disguised names and commits hide the repos
• •Uploading: how chunks reach the active repo