Proxy Bastion vs a proxy provider built-in sub-users

Last checked 2026-09-10

Several proxy providers already ship a sub-user or sub-account feature: log into the provider dashboard, create a secondary login under your main account, give it its own bandwidth or concurrency cap, and delete it later without touching anyone else. Within that one provider, this is free and it works.

The honest starting point for this page is that Proxy Bastion does not try to be a better version of that feature. If every proxy you hand out comes from a single upstream that already offers sub-users, use the native feature and stop reading. Proxy Bastion exists for a narrower problem: issuing, limiting and revoking access in one place when the proxies underneath come from more than one upstream, or when you do not want the people you hand access to holding a login on your upstream account at all.

Provider-native sub-users: side by side

DimensionProxy BastionProvider-native sub-users
Working across more than one provider One issuing and revocation surface in front of however many upstream providers you use. A person gets one link regardless of which upstream is behind it. A provider's sub-user system only knows about that provider's own account. Using three upstreams for redundancy or coverage means three separate sub-user systems, three separate dashboards, and three separate places to check who still has access.
Revoking access across providers Revoking a link removes that one person, no matter which upstream or upstreams it was backed by, from one place. Cutting someone off who was given proxies from two different providers means logging into each provider separately and deleting the matching sub-user in each one. Miss one and they keep an active proxy.
Exposing upstream credentials The person using the link never sees the upstream provider account, its username, or its password. They only ever hold their own relay link. A sub-user is still a credential minted inside the upstream provider's own account namespace. Handing it out means the recipient is, in a real sense, a user of your provider account, with whatever account-level pages or side effects that account exposes.
Unified limits and issuing workflow Issuing a new link and setting its limit is the same one call or one dashboard action regardless of which upstream, or how many upstreams, sit behind it. Each provider has its own dashboard, its own API shape, and its own idea of what a limit even means, so a consistent issuing workflow across providers has to be built by hand on top of them.

Where this page draws the line

  • Proxy Bastion does not compete with a provider built-in sub-user system and is not trying to replace it for the single-provider case, where it is already free and sufficient. It is for the case that sub-users cannot cover by design: coordinating issuing, limiting and revoking access across more than one upstream provider from a single place, without handing out the upstream account credentials themselves.

When Provider-native sub-users is the right choice

  • If you only buy proxies from a single upstream provider and that provider already offers native sub-users, use that feature directly. It is free, it already lives inside the billing and support relationship you have with that provider, and Proxy Bastion would only add a redundant layer on top of something that already works for that single-provider case.

Sources

  • Webshare's public sub-user API documentation describes sub-users as scoped to a single main proxy account, each with its own configurable bandwidth and concurrency limits and its own proxy list drawn from that one account, and each independently deletable through a dedicated delete-sub-user endpoint. This supports the claim that a native sub-user feature already gives per-user limits and independent revocation within one provider. https://apidocs.webshare.io/subuser (checked 2026-09-10)