Guide

Teams

A team owns databases and shares access to them. Invite a teammate and they can see and connect to every database the team owns, without you handing round connection strings. Team management lives under Team settings in your cloud dashboard.

Your primary team

Every account has exactly one primary team, created for you automatically. It is your personal workspace and it owns the databases you create on your own. You cannot delete, leave, or transfer your primary team, because it is tied to your account. Deleting your account is what removes it.

You can also create additional teams that you own. Those extra teams can be renamed, transferred, or deleted, unlike your primary one.

Roles

There are two roles: owner and member. The owner runs billing, invites and removes people, renames the team, and can transfer ownership. Members can see and connect to the team's databases and take backups of them. Actions that roll back or remove the owner's data, such as restoring or deleting a backup or resetting a branch, are reserved for the owner. Every team has exactly one owner at a time.

The team's current owner controls every database on the team, including one a member created inside it. Owner-level controls such as deleting the database, managing its firewall, client certificates, credential rotation and settings belong to the owner, not to the member who created it. There is no separate admin role on a team. The owner's plan pays for the team's databases, and they count against the owner's limits.

Inviting a member

Only the owner can invite. Open Team settings, enter the teammate's email, and send the invitation. Inviting requires a paid plan: the Free plan cannot add members. On Solo and Pro each invite consumes a purchased seat, so add a seat in Billing first if you have none free.

The invite arrives by email with an accept link. The link is valid for 7 days, after which it expires and you have to send a new one. A pending invite reserves a seat until it is accepted or expires, so you cannot invite more people than you have seats for.

Resending an invite

Resend from the pending invite in Team settings if the email got lost. Resending mints a brand-new link and immediately invalidates the previous one, so a recipient always has just a single working link. Only pending invites can be resent. You can also revoke a pending invite to cancel it outright.

Accepting an invite

Click the link in the email and sign in. The invite is bound to the exact address it was sent to. If you accept while signed in as a different account, the page refuses and shows you both addresses: the one the invite was sent to and the one you signed in as. Sign in with the invited address, or ask the owner to re-invite the address you actually use.

One exception: if the invited address is a known alias of your account (for example, you changed your Google email after signup), the accept still goes through. Accepting is idempotent, so clicking an already-accepted link just lands you on the team.

Seat billing ($3 per member)

A paid plan includes one seat, which the owner uses. Every additional teammate is $3 per member per month, billed to the owner's existing subscription. Adding a member charges the prorated difference; removing one credits it back. There is no separate invoice for the team, it is all folded into the owner's plan.

The owner never counts as a paid seat. Only accepted non-owner members and still-pending invitations count against your seats.

Removing a member or leaving

The owner can remove any member from Team settings, which frees the seat. A member can leave a team they joined at any time. Either way, access to every database the team owns is revoked right away.

Removing or leaving does not rotate any database credentials. This is by design: the shared connection strings keep working for everyone still on the team. If a departing teammate had a copy of a connection string or password and you want that access cut off, rotate the affected database's credentials yourself.

Renaming a team

The owner can rename a team from Team settings at any time. Renaming only changes the display name; it does not affect databases, connection strings, or membership.

Transferring ownership

The owner can hand a non-primary team to an existing member. Invite the person and wait for them to accept, then transfer ownership to them. The new owner picks up billing for the team's seats and you become a regular member. Primary teams cannot be transferred, since each account keeps its own primary team.

Everything the team holds moves to the new owner's plan with it. From the moment of the transfer, the team's databases count against the new owner's database limit, and their backups, branches, always-on capacity and storage follow the new owner's plan, not the plan of whoever created them.

So a transfer only goes through when the new owner's plan can hold all of it, together with what they already have. Before anything changes, Layerbase checks the number of databases, the engines their plan includes, branches per database, storage, always-on capacity, and any plan feature in use such as point-in-time restore, client certificate (mTLS) authentication or scheduled backups. If something does not fit, the transfer is refused with each reason listed, for example "Sam's Free plan allows 2 databases; this team has 3", and nothing is changed. The new owner can upgrade, or you can remove what does not fit, and then try again. A transfer never moves part of a team. A team that runs on a dedicated server cannot be transferred until support hands the server's billing over.

Control moves with it too. After a transfer, the new owner holds the owner controls for every database on the team, including ones someone else created: settings, the firewall, client certificates, credential rotation and deleting. The new owner's plan pays for the team's databases from then on. A creator who stays on the team becomes a member like anyone else, and the new owner decides what they can do.

Account holds on a team's databases follow the same rule. A billing hold (a past-due payment or an account paused for non-payment) comes from the team owner's account only, so a member's own billing problem never pauses a team database while the owner is in good standing, and a billing hold on the owner's account applies to every database on every team they own, including a team transferred to them. When the hold lifts, it lifts from all of them; a database it stopped stays stopped until someone starts it. An acceptable use pause applies if either the owner or the person who created the database is paused.

If the team owner deletes their account

An owner cannot delete their account while a team they own holds databases other members created. Deleting the account waits until each such team is handed off: transfer ownership to a member first, then delete the account. See Deleting your account for the full flow.

If an owner's account is deleted and a team is not handed off, Layerbase support can instead schedule the databases members created in that team for deletion. Each affected member gets an email that names the team, the databases, and the deletion date, which is 7 days after the deletion was scheduled. Until then the databases keep running, so connect and export anything you want to keep. After the deadline each database is deleted through the normal delete path, which takes a final backup first. If the owner's account is restored before a database's deletion starts, its scheduled deletion is canceled. Questions about a scheduled deletion go to support.

When invitations are paused

Databases run inside containers on our servers. Today a team's databases can share a container with the owner's personal databases or with another team's. Because a team member connects with credentials that work inside that container, we do not let anyone join a team whose databases share a container with databases outside the team. We are moving each team's databases into their own isolated container; until a team's move is done, Team settings tells the owner that inviting members is temporarily unavailable.

While a team is paused: new invitations, resends, and ownership transfers are refused; invitations you already sent stay pending, and the invitee sees the invite without an accept button and a note that the team is being prepared. Existing members keep their access. A pending invitation still expires 7 days after it was sent, so if one expires during the pause, send a new one once invitations are available again. This is temporary while team isolation rolls out. To have a team moved sooner, contact support.

The same rule covers new databases. Until a team's move is done, a request that would put a database in a container it shares with databases outside the team, while a team involved has members, is refused on that server: creating a database or a stack, creating a branch, restoring an archived database, running a point-in-time restore, or turning on branching. Nothing is created or changed when that happens, and the message points you to support. A database that already runs in its team's isolated container cannot be moved to another server yet.

If you downgrade to Free

Downgrading to Free while you still have members does not kick anyone out. Existing members keep their access, but Team settings shows a banner because the Free plan does not bill for seats and cannot add new ones. To resolve it, either upgrade to a paid plan to start billing the seats again, or remove the members you no longer need.