Today we’re shipping one of the most-requested account features we’ve ever tracked: Team Workspaces. You can now invite teammates into your Shifter account, give each one a role that fits what they actually do, and let the same person belong to several workspaces at once without juggling logins.
If you’re in a hurry: open the Team page in the panel, send an invite, pick a role, done. Existing Shifter users join with one click. Anyone new signs up with a magic link and no password to remember. You can switch between any workspace you belong to from a single dropdown in the sidebar.
If you want the longer version, here is what we built and why.
Why we built this
For years, the typical Shifter account looked like one person, one email, one login. That works fine for a solo developer running a scraper or a single ops engineer maintaining a SERP pipeline. It stops working the moment more than one person needs to touch the account.
The patterns we kept hearing about:
A developer who builds the scrapers shouldn’t need access to the company credit card. Whoever signs off on invoices shouldn’t need to know what an ISP proxy is to do their job. A freelance engineer working across three clients shouldn’t have to ask each one to share a login over Slack. An agency running campaigns for many brands shouldn’t be merging traffic from all of them into one membership.
Shared logins paper over those problems and create new ones. There’s no audit trail. There’s no way to remove someone’s access when they leave. And when the password changes, everyone with the old one calls support.
Team Workspaces fixes all of that without making the simple case any harder.
What changes for you
If you’ve been the only person on your account, nothing changes on day one. Your existing account is now called a Personal workspace. It’s yours, exactly as it was, with one new affordance: you can invite people into it.
The moment you do, the model expands. Your account becomes a workspace, the people you invite become members, and each of them gets a role that controls what they can see and do.
The three roles
We deliberately kept this to three tiers. More granularity sounds nicer in a slide deck and turns into a permission matrix nobody remembers in practice.
Viewer. Read-only. Sees memberships, traffic, and invoices. Can browse the order catalog to see what’s available, but can’t buy anything or change anything. This is the right role for an analyst who needs to look at usage trends, a CFO who wants to see what’s being spent and where, or a security reviewer pulling an audit.
Billing. Everything a Viewer can do, plus the ability to add funds, pay invoices, buy new plans, and upgrade existing ones. Billing can’t manage memberships beyond purchase or change team membership. This is the role for the person who holds the company card.
Admin. Everything Billing can do, plus full membership management (cancel, switch, upgrade, change settings) and full team management (invite, remove, change roles). The owner of the workspace is implicitly an Admin in their own workspace and can never lock themselves out.
Every gate is enforced both in the UI (a Viewer doesn’t see a Pay Now button as clickable in a way that lies to them, and gets a clear toast if they try anyway) and on the server. Calling a gated endpoint as the wrong role returns a 403, not a 500, and not a silent success.
Multi-workspace, not multi-account
This is the part of the design we’re most proud of, because it’s the part that took the longest to get right. A user is not stuck inside one workspace. The same email address can be the owner of their Personal workspace, a Viewer in one client’s workspace, and a Billing user in another.
We didn’t want to make people maintain three logins for that, or sign out and in to switch contexts. So the sidebar has a workspace switcher above the profile menu. It opens upward, lists every workspace you belong to (Personal first, then the rest), and switching context happens in a single click. The dropdown only appears once you’re actually in more than one workspace, so solo users never see it.
The active workspace lives in your session. Every request re-validates that you still belong to it. If a workspace owner removes you while you’re working in that context, the next page load drops you back into your Personal workspace and tells you why. Nothing about the session can outlive a revoked membership.
Inside any workspace, everything is scoped to that workspace. The plans you see, the balance in the wallet, the invoices, the team list, the memberships, all of it. Switching is the only thing that changes the context, and it changes everything at once. There is no situation where you can accidentally pay an invoice from the wrong account.
Inviting someone
Open the Team page in the workspace you want to manage. Type an email, pick a role, send.
If that email already belongs to a Shifter user, they get a one-click “Join” button the next time they sign in. They keep their existing account, their existing Personal workspace, and now they’re also a member of yours. No new account is created. No password reset. No re-onboarding.
If that email is brand new to Shifter, the invite turns into a streamlined signup. First name only, last name optional, magic-link login, no password to remember or rotate. The moment they confirm the magic link, they’re in your workspace, and they also get a Personal workspace of their own that they can switch to later if they want.
We block obvious nonsense automatically: you can’t invite yourself, you can’t invite someone who’s already a member, and there’s a 10-seat cap per workspace. (If 10 isn’t enough for what you’re building, talk to us at hi@shifter.io, this is intentionally a soft cap.)
Some patterns this unlocks
A few of the workflows we’ve already seen people set up on staging:
Finance-only access. The engineering team owns the workspace as Admins. The CFO is invited as Billing. The CFO can fund the wallet, see every invoice, pay anything that’s outstanding, and answer their own questions about spend without anyone in engineering being interrupted.
Audit access for security reviews. Invite the reviewer as a Viewer for the length of the engagement. They see exactly what they need to see for the audit. When the engagement is over, remove them in one click and their access is gone, immediately, including any background session they had open.
Agencies running multiple client workspaces. Each client owns their own workspace and invoices land in their own wallet. The agency’s project lead is added to all of them as Admin, with one login. Switching between client contexts is one click in the sidebar. No traffic is ever co-mingled between workspaces, because plans don’t cross workspaces.
Freelancers working across clients. The reverse pattern. The freelancer is added as a Billing or Admin user in each client’s workspace. The client retains ownership of the account, the plans, and the invoices. When the engagement ends, the client removes the freelancer and the relationship cleanly ends.
Separating personal experiments from company traffic. Same person, two workspaces. Personal for nights and weekends. Company workspace for production scrapers. Separate balances, separate invoices, separate plans. One login, one sidebar click between them.
A few details worth knowing
A handful of mechanics that aren’t obvious from the screens but matter once you’re using this:
-
The owner of a workspace can’t be removed by anyone. The owner can downgrade or remove other Admins, but the workspace itself belongs to the original creator. If a company needs to transfer ownership for any reason, we can do that on request, so reach out.
-
Account deletion cascades both directions. If a member’s account is deleted, their memberships in other workspaces are cleaned up. If a workspace owner deletes their account, the workspace and its memberships go with it. We surface this in the delete-account flow so nothing happens by surprise.
-
Roles are workspace-scoped, not global. You are not a “Billing user” on Shifter, full stop. You are a Billing user in workspace X. In a different workspace you might be a Viewer, or you might be the owner. The role you have in your current context is always what’s enforced, and it’s always visible in the switcher.
-
Plans don’t move between workspaces. A residential plan bought in workspace A is a workspace A asset and stays there. If you want a plan to belong to a different workspace, buy it in that workspace.
Where to find it
It’s already live for everyone, no opt-in. Sign in to your panel, look for “Team” in the sidebar, and start inviting people.
If you’re new to Shifter and want to set up your first workspace properly, the residential proxy plans and ISP plans are the usual starting points. The plan goes in the workspace, the team goes around it.
We’ve been wanting to ship this since we rebuilt the residential gateway, because account-level features only really make sense once the underlying product stops being the bottleneck. Now it is, and now Team Workspaces is here. If there’s a permission shape we missed, or a role split that doesn’t quite fit your team, write to us. We deliberately kept the surface small so we can keep moving it.