Teams
Base44 Workspaces and Teams
OffRamp · November 1, 2026 · 8 min read
Short answer: a team migration is a different job than a solo migration. A Base44 workspace is not just your apps in a folder — it is the people, the roles, the shared plan and credits, and a second, separate access system for each app. None of that structure is in the export. This page maps how the workspace actually works, what breaks when a team leaves, and the order to rebuild it in.
The structure
How a Base44 workspace actually works
When you join Base44, you automatically get a workspace — your main hub for apps, team members, and billing. Each workspace has its own plan and its own shared pool of credits, and everyone you invite builds and runs apps using those shared credits. Workspaces are not connected: apps in one workspace never use credits from another. That makes the workspace, not the app, the real unit of cost — and the real unit of migration.
Invites are generous: you can invite as many members as you want on every plan, including Free, and invited members do not need their own paid plan — they use the plan and credits of the workspace they join. Every invited person gets a role, and the roles are the permission system: Owner (one per workspace; manages billing, members, settings, apps, and credits, with admin access to every app), Admin (Enterprise plans only; manages members and settings but not billing), Editor (creates apps, edits apps they are invited to and apps shared with the whole workspace), Viewer (views apps only — no editing, no AI chat, no access to most of the dashboard), and Guest (edits specific apps they are invited to, but cannot create apps, see other workspace apps, or touch workspace settings — guests come from app invitations, not workspace invitations).
Two details in that structure matter for everything below. First, there is exactly one Owner, and the Owner cannot leave the workspace. If a member leaves, they lose access to all its apps — and any apps they owned move to the workspace owner. Second, you cannot delete a workspace directly. These are the parts of the team setup that behave like ownership with no exit: the person at the top is load-bearing, and the container itself has no teardown button.
The surprise
Workspace access and app access are two different doors
Here is the part most teams discover mid-migration: who can open the workspace is not the same question as who can open the app. Your workspace role decides what you can do across the workspace. But each app has its own access controls on top: visibility settings (Public, or Workspace-only with sign-in), collaborators invited per app from the app editor, and app-level roles such as Admin and User that govern what people can do inside the live app. Only collaborators and the app owner can access the app editor and the app’s dashboard — a Viewer in the workspace with no app invite cannot see the app at all, and an app role in the live app grants zero access to the editor.
That split is manageable inside Base44, because one company owns both doors. It becomes the migration problem the moment you leave: you have to rebuild both access systems, on two different infrastructures, and neither one is in the export. The workspace roles live in the workspace. The collaborator lists live in each app. The app roles live in the app’s own data. A migration plan that moves “the apps” and assumes the people come along is planning half the job — the other half is the access map, door by door.
And it reaches into security, too. On Enterprise plans, workspaces can run SSO, domain verification, and restricted external-collaborator invites (so only owners and admins can invite outsiders to apps) — plus workspace skills that keep the AI chat consistent across the whole team. None of that configuration exports. The security setup deserves its own audit before you move; this page is about making sure every person still has a working door on the other side.
The migration problem
What breaks when your workspace leaves Base44
Walk it the way a team migration actually runs. Roles first. The export carries the frontend; per Base44’s own documentation, roles, members, and workspace configuration are not exportable artifacts at all — there is no “roles export” button. On the new stack every person gets a fresh, deliberate role: Supabase Auth and project roles for the app, GitHub team permissions for the code, Vercel team access for hosting. That is work, but it is also an upgrade: the access map stops being inherited from a platform default and starts being designed. The export guide shows which pieces come out and which never do.
Shared credits second. The credit pool belongs to the workspace, so it stays behind — and this one is usually good news. On your own infrastructure there is no credit pool at all: Supabase, Vercel, and GitHub bill your own accounts for what the app actually uses, itemized per service. But it is still a migration task: somebody has to know what the team was actually spending, because “everyone uses the shared pool” is not a number you can hand to finance. Pull the usage summary from the workspace’s member view before the move — per Base44’s docs, the member list shows each member’s credit usage, and owners can see who the top builders were. That report is your last chance to see it.
Member and guest access third. Every editor re-invited, every guest re-invited, every app-level Admin/User role re-created in the new app’s own role system. And the trap doors: a departing member’s apps move to the workspace owner — on the new stack, make company infrastructure owned by a shared team account from day one so no single person is load-bearing. If anyone on the team was mid-hire, mid-exit, or a contractor with guest access to three apps, the migration week is when those loose ends get sorted, not after.
Workspace configuration last. SSO, domain verification, workspace skills, restricted external invites, the Groups tab on Enterprise — the governance layer a growing team accumulates. If you were on an Enterprise plan, remember the fine print too: Admins drop to Editor if the workspace ever left Enterprise. None of this moves automatically; each piece is a decision about what the team actually needs on infrastructure it owns. App ownership covers why owning the app itself matters; this page is about owning the team’s access to it.
The way out
How OffRamp rebuilds team access on infrastructure you own
The team migration runs on the same OffRamp order as every Base44 migration — database and app first, onto Supabase, Vercel, and GitHub accounts owned by your company — with the access layer rebuilt deliberately on top. First, the people map. Before anything moves, we collect the actual map: who the workspace members are, what roles they hold, which apps each person collaborates on, who the guests are and which apps they touch, what the app-level roles grant inside each live app. Base44’s member view (roles, credit usage, activity) is exported and archived — it is the last snapshot of how the team actually worked.
Then the roles are redesigned, not copied. Base44’s five roles map onto real systems with finer controls: Supabase Auth and project roles for the app, your app’s own role system for end users, GitHub teams for the code, Vercel teams for hosting. The migration is the chance to fix the access sins the platform hid — the contractor who was an Editor on everything because Guest was too fiddly, the Viewer who really needed app-level Admin. Then the accounts: company-owned team accounts on all three services, every person invited under their own identity, admin rights in two sets of hands, never one — because the workspace that couldn’t be deleted and the owner who couldn’t leave taught the lesson.
What you end up with is the same team with a different foundation: same people, same apps, but the permissions live in systems your company owns, the bills arrive itemized per service instead of pooling through one opaque credit pot, and removing one person no longer threatens the apps they owned — because the infrastructure was never under one person’s login. Migrate off Base44 once, and the whole team moves together.
FAQ
Questions, answered honestly
Do my Base44 workspace roles transfer when I migrate?
No. Workspace roles — Owner, Admin, Editor, Viewer, Guest — live inside the workspace and nothing in the export carries them out. On the new stack, each person gets a fresh role in systems you control: Supabase Auth and project roles for the app, GitHub team permissions for the code, Vercel team access for hosting. The migration is the moment the team’s access gets rebuilt on purpose, instead of inherited from a platform default.
What happens to our shared Base44 credits when we leave?
The shared credit pool belongs to the workspace, so it stays behind. That is usually good news: on your own infrastructure there is no credit pool at all. Supabase, Vercel, and GitHub bill your own accounts for what the app actually uses — itemized, per service — instead of funneling the whole team’s usage through one opaque pool. The team migration is partly a billing migration: from one shared pool you do not itemize, to per-service bills in your name.
What happens to our apps if the workspace owner leaves the company?
In Base44, the workspace owner cannot leave the workspace, and a member who leaves loses access to all its apps — any apps they owned move to the workspace owner. Handle ownership handoffs before anyone departs, and after the migration, keep the same discipline: make the company’s infrastructure accounts (Supabase, GitHub, Vercel) owned by a shared team account, never by one employee’s login.
Is workspace access the same as app access in Base44?
No — they are two separate control planes, and this is the most common team-migration blind spot. A workspace role (Editor, Viewer) decides what someone can do across the workspace. App access is decided separately: visibility settings (Public or Workspace), collaborators invited per app from the app editor, and app-level roles like Admin and User inside the live app. Only collaborators and the app owner can open the app editor and dashboard. Migrating a person’s workspace access does not migrate their app access — both have to be rebuilt, deliberately.
What happens to our app guests when we migrate?
Guests are added through app invitations, not workspace invitations — they can edit specific apps without seeing the rest of the workspace. Nothing exports that arrangement. On the new app, every guest, editor, and stakeholder gets re-invited under the new access model: Supabase Auth roles and your app’s own role system for end users, collaborator invites for builders. Treat the guest list as data worth collecting before the migration, because the old invite structure disappears with the workspace.
How does OffRamp rebuild team access on infrastructure we own?
As a real access design, not a platform default: Supabase, Vercel, and GitHub accounts owned by your company, every person invited with a named role, app-level roles rebuilt from how your team actually worked (not from Base44’s role list), workspace skills and access rules reviewed and re-created where they mattered, and an offboarding story from day one — removing one person no longer threatens the apps they owned, because the infrastructure was never under one person’s login.
Move the whole team, not just the app.
Rebuild roles, access, and billing on infrastructure your company owns: migrate your Base44 workspace off the platform onto Supabase, Vercel, and GitHub accounts in your name. Connect the Base44 account from the OffRamp home page. The free analysis takes about a minute, and your fixed quote comes with it.
Start your free analysis