Tell us the problem or your need
The default component/dependency/installer index is fetched exclusively from proxy.usebottles.com (RepositoryManager.__repositories). This host resolves to a single Linode IP (172.105.68.126). In regions where that IP/SNI is throttled or blocked by ISP-level filtering, onboarding hangs indefinitely at the final "Loading bottles…" step — the Continue button does nothing and no error is logged.
strace -f -e trace=connect confirms the app only ever attempts connect() to 172.105.68.126:443, which never completes (stuck in EINPROGRESS). Meanwhile the actual binaries referenced in the manifests point directly at github.com / gitlab.com release assets (861 GitHub URLs across the components repo, 0 usebottles URLs). GitHub itself is fully reachable in the affected region — only the index host is not. So the single point of failure is the index domain, not the payload hosting.
I understand the proxy was introduced deliberately as a gating layer, so that frequent untested commits to the public repositories don't reach end users. That goal is valid and should be preserved — the issue is purely that the gated index is served only from one self-hosted domain.
Describe the solution you'd like
Keep the gating, but serve the gated index from GitHub infrastructure instead of a single self-hosted host.
Concretely: publish a stable, gated ref of the existing public repos — e.g. a dedicated release/stable branch, version tags, or a separate "releases-only" repository — that is updated only after testing (exactly the role the proxy plays today). Then point the default index URLs at that ref via GitHub raw or a github-backed CDN, e.g.:
https://raw.githubusercontent.com/bottlesdevs/components/release/
or https://cdn.jsdelivr.net/gh/bottlesdevs/components@release/
This preserves the "users only see vetted content" guarantee while removing dependency on a single domain/IP. The override mechanism for this already exists in the codebase (PERSONAL_COMPONENTS / PERSONAL_DEPENDENCIES / PERSONAL_INSTALLERS env vars and PersonalRepositories config), so the architecture is already prepared for an alternative base URL — only the default needs to change.
Other solutions?
- Mirror list with failover. Make each repository url a list of sources tried in order on timeout, e.g. [proxy.usebottles.com, raw.githubusercontent.com/.../release, cdn.jsdelivr.net/gh/...@Release]. Any single source going down stops being fatal. This pairs naturally with the primary solution once a stable GitHub ref exists.
- CDN in front of the existing proxy (server-side only, no client release). Put proxy.usebottles.com behind an anycast CDN (e.g. Cloudflare/Fastly) so it is no longer a single Linode IP that can be geo-degraded. Fixes the symptom without touching the client, though it may carry hosting cost.
- Expose the existing override in the UI. Surface PERSONAL_* as a "Custom repository URL" field in Preferences, letting users in filtered regions point at a mirror without rebuilding. Cheapest stopgap, since the feature already exists internally.
Additional context and references
- Affected file: bottles/backend/managers/repository.py — RepositoryManager.__repositories (hardcoded proxy.usebottles.com base URLs); override logic in __check_personals().
- Manifests already reference upstream release assets directly (github.com/gitlab.com); the proxy is used only for the index layer.
- Public repos that already hold this data: bottlesdevs/components, bottlesdevs/dependencies.
- Reproduction: on a network where 172.105.68.126:443 is filtered, onboarding hangs at "Loading bottles…" (Step 13/13). Routing only usebottles.com through a VPN immediately unblocks onboarding (dxvk/vkd3d/nvapi download normally), confirming the index host is the sole blocker.
- Bottles version: 64.1.
Tell us the problem or your need
The default component/dependency/installer index is fetched exclusively from proxy.usebottles.com (RepositoryManager.__repositories). This host resolves to a single Linode IP (172.105.68.126). In regions where that IP/SNI is throttled or blocked by ISP-level filtering, onboarding hangs indefinitely at the final "Loading bottles…" step — the Continue button does nothing and no error is logged.
strace -f -e trace=connect confirms the app only ever attempts connect() to 172.105.68.126:443, which never completes (stuck in EINPROGRESS). Meanwhile the actual binaries referenced in the manifests point directly at github.com / gitlab.com release assets (861 GitHub URLs across the components repo, 0 usebottles URLs). GitHub itself is fully reachable in the affected region — only the index host is not. So the single point of failure is the index domain, not the payload hosting.
I understand the proxy was introduced deliberately as a gating layer, so that frequent untested commits to the public repositories don't reach end users. That goal is valid and should be preserved — the issue is purely that the gated index is served only from one self-hosted domain.
Describe the solution you'd like
Keep the gating, but serve the gated index from GitHub infrastructure instead of a single self-hosted host.
Concretely: publish a stable, gated ref of the existing public repos — e.g. a dedicated release/stable branch, version tags, or a separate "releases-only" repository — that is updated only after testing (exactly the role the proxy plays today). Then point the default index URLs at that ref via GitHub raw or a github-backed CDN, e.g.:
https://raw.githubusercontent.com/bottlesdevs/components/release/
or https://cdn.jsdelivr.net/gh/bottlesdevs/components@release/
This preserves the "users only see vetted content" guarantee while removing dependency on a single domain/IP. The override mechanism for this already exists in the codebase (PERSONAL_COMPONENTS / PERSONAL_DEPENDENCIES / PERSONAL_INSTALLERS env vars and PersonalRepositories config), so the architecture is already prepared for an alternative base URL — only the default needs to change.
Other solutions?
Additional context and references