Team vault

A team shares logins (user, password, private key) and notes in a vault that only its members can read. There is no Shellvane server: the team file lives on storage the team already shares — a shared folder (Dropbox, OneDrive, a network share), a WebDAV server, a Git repository or an S3 bucket — and it is encrypted end to end on each computer.

Open Team

Your identity

Each person creates their team identity once, with the name colleagues will see: a key pair kept in their own vault. Its join code holds only the public keys: send it to a team's admin to be added. Compare the key fingerprint with the admin (by phone, in person) so nobody can slip in another key.

Create a team

Create a team, give it a name and choose where its file goes. The creator is its first admin.

To add someone: paste their join code under Members, choose Member or Admin, then send them the invitation that appears. The invitation says where the team is and which admin key to trust; it contains no secret.

Join a team

Join a team and paste the invitation. Check where the team file is seen from your computer (a shared folder can have another path on yours) and type the storage password if it has one: it is kept in your vault.

Storage and credentials

Shared folder: every member needs the folder synced on their computer (Dropbox, OneDrive, a network share); its path can differ per computer.
WebDAV and S3: the user and password (or access key and secret key) are asked when creating or joining and kept in each member's own vault.
Git: create an empty repository the members can write to (GitHub, GitLab, Gitea… a private one), and use its address.
- With an SSH address (git@github.com:team/shellvane.git) or an HTTPS address your computer already logs in to (Git credential helper, macOS keychain, Git Credential Manager on Windows), leave user and token empty: Shellvane runs git with your own credentials. An SSH key with a passphrase must be loaded in the SSH agent, because Shellvane cannot answer a prompt.
- Otherwise enter a personal access token with write access to the repository (and the user name, if the service needs one). It is kept in your vault, passed to git through its environment and never written into the clone or the invitation.
- With a user and no token, Git's credential helper is asked for that user's saved password. On a network with a proxy, Shellvane uses the proxy and certificate variables of your shell profile (HTTPS_PROXY, NO_PROXY, SSL_CERT_FILE…) or Git's own http.proxy, as the terminal does.
- User and password work too (e.g. Bitbucket Server): put the password in the token field. If the server refuses passwords (two-factor login, SSO), create an HTTP access token instead.
- A password changed or a token expired? Open the team › Storage and credentials, type the new one and save (an empty field keeps the saved one). The same button appears when a team cannot be opened, also to correct the address.
- Each member uses their own credentials: the invitation contains only the address. Shellvane keeps a clone of the repository on your computer; when two people save at the same moment, the second change is redone automatically on top of the first, never merged by hand.

Share logins

Add a login with a label, a user, a password and/or a private key. Every member sees it; secrets are never shown in the list, and editing without retyping them keeps them.

A host uses a team login from its advanced options: Credentials from a plugin or a team › the team's login. Each connection reads the current value, so changing a password in the team changes it for everyone at once.

Share host groups

Right-click a group in the hosts panel › Share with team: the group, its subgroups and hosts (with their settings, jump hosts and team logins) go to the team. Every member gets it as a group of their own, at the top of their hosts, and Shellvane keeps it up to date — at start, every few minutes and with Update shared groups now in Team.

To change a shared group, edit it as usual, then right-click it › Publish changes to team. Members' copies are updated in place: hosts keep their identity, so tunnels, environments and favorites that use them keep working. A group changed on your computer and not published is kept, not replaced by team updates: the edit dialogs say so, and right-click › Discard local changes takes the team's version back.
Commands need your approval here too: a shared group can carry commands that run on your computer (ProxyCommand, password, certificate and pre-connect commands), commands typed on the servers with your account (startup and remote commands) and X11 forwarding. Until you review and approve them (red shield on the group, or right-click › Review the commands) your copy goes without them; any change asks again.
What only makes sense on one computer stays local: the key chosen for a host, its terminal theme, Wake-on-LAN and port knocking, and a credential plugin of that computer.
Stop sharing (in Team) removes the group from the team; every member keeps their copy as an ordinary group.

Share environments, snippets, workspaces and rules

Next to each environment, snippet, saved workspace and automation rule there is a team button: Share with team (or, once shared, Publish changes to team). Members get their own copy, kept up to date like shared groups:

An environment travels with the tunnels it uses; hosts, tunnels and workspaces are linked by name, first among the team's shared groups. A tunnel is created on a member's computer only when they have none with that name.
A workspace opens the same hosts by name; panes of hosts the member does not have are left out.
A rule keeps the group or host it applies to, by name; if the member has none, it stays off.
A copy you change locally is kept: team updates do not replace it, and the team does not see it until you publish it. The edit dialog warns you, and the team button turns orange: click it to Publish changes or Discard local changes (take the team's version).
A shared workspace never replaces one of yours with the same name: it arrives as Name (Team).

Commands need your approval. A shared environment runs commands on your computer (login check, login, preparation, jump host commands), and a respond rule types text into your sessions. The first time, and after every change made in the team, the environment does not start and the rule stays off until you review the commands (red shield button, or when you start it) and Approve them. What you share yourself is approved for you.

Sync, and when the storage is not there

Shellvane reads the team at start, every 5 minutes and with Sync now (in the team's header, or Sync teams now in the palette).

The last verified copy of the team is kept on this computer. When the storage cannot be reached (offline, VPN off, a Git server down, a deleted repository), the team opens from that copy, read-only, with a notice: logins keep working for connections, while changes wait until the storage is back.

If the storage answers but has no team file (a new or emptied repository or folder), the notice offers Publish this copy here: any member can put the team back, since the file is signed already. To move a team to a new repository: create it empty, set it in Storage and credentials, then publish the copy; the other members change the address in their own Storage and credentials.

Member limit and access

Under Members each person shows their role, whether they have joined (Invited until they open the team for the first time) and when they were last active.

Member limit: optional; an admin can cap how many members the team has (0, the default, for no limit). Adding someone when the team is at the limit is refused; raise the limit or remove someone first.
Access until: an admin sets the last day of a member's access, useful for contractors and temporary help. After that day the member is removed, with a new team key, the next time an admin's Shellvane opens the team; until then they can still read it. Clear the date to keep them.
Former members lists who was removed, when and by whom.

Activity

Activity lists what happened in the team, newest first: members added, joined, removed or whose access ended, roles and member limit changed, ownership handed over, logins, notes and shared objects added, changed or deleted. Filter it, or export it as CSV or JSON for your records.

Every entry is signed by the member who made it and travels encrypted inside the team file, so nobody can forge one, not even someone who can write the storage. It names members and items, never passwords or keys. Shellvane remembers the newest entry it has seen: if it disappears later, a warning says entries were removed (by someone with access to the storage, or by an older version of Shellvane that rewrote the file — update every member). The last 5,000 entries are kept. Using a login to connect is not recorded: each connection would have to rewrite the shared file.

Members and security

Admins add and remove members and change roles; a team keeps at least one admin.
The owner (who created the team, marked Owner in Members) is the only one who can delete the team, and no admin can remove or demote them. The owner can hand the team to another member with Make owner: that member becomes an admin and the new owner, and the previous owner stays an admin. The change is signed by the previous owner, so an admin cannot make themselves owner.
Removing a member changes the team key: from then on they cannot read the team. They may have kept what they saw before: change the passwords they knew.
The member list is signed by an admin, and every change of the shared items by the member who made it. Both carry a version number that only grows, and each computer remembers the highest it has seen: Shellvane refuses a file not signed by an admin it already trusts, and any older version put back on the storage (from the repository's history, or an old copy) — the team then shows your copy with Restore this copy. Invitations carry the current version, so a new member refuses an old copy too.
Delete team (the owner, in the team's header) deletes it for everyone: logins and notes are erased, and the file on the storage keeps only a signed note saying who deleted it, with a new key and no secret. Members see it the next time Shellvane opens the team, keep the shared groups as ordinary groups, and choose Leave on this computer. It cannot be undone, and a copy of the old file put back on the storage is refused. To stop using a team only on your computer, use Leave on this computer.
Two people editing different items at the same time both keep their changes; the last save wins on the same item.