Overview

This section is an basic overview of the core Stashbase functionality and features.

Workspaces

Workpace is a place where you can store all your projects, environments and secrets etc. Each workspace has it's own members. Every user can be a member of multiple workspaces and each subscription (e.g. free, startup, enterprise) is tied to an individual workspace.

When you create your account, you will be asked to name your workspace and you will be automatically assigned as an admin.

Workspace users

Users can be invited to join a workspace via email or with link. Each user in the workspace has one of the following roles based on the permissions they have: member, admin or owner.

Member role

Members can can view and interact with projects and environments they have granted access to. Member cannot promote/delete users in the workspace.

Admin role

Admins have full access to all projects and environments and can promote and delete users in the workspace.

Owner role

This highest role is automatically assigned to the user who created the workspace. Owners have the same permissions as an admin but thye also have the ability to change and manage workspace subscription (e.g. changing subscription plan, managing payment details).

Teams

Organizing access for individual users can be tedious and error-prone. With Stashbase you can organize access for multiple users in one place using teams. Those teams can be created in any workspace with shared access permissions set for all team members. For example your workspace can have team Frontend, Backend and Devops with access permissions to individual projects and environments set for all team members.

Projects

The whole project access design follows the principle of least privilege.

A project is a container for multiple environments and it's secrets and other resources like webhooks and integrations. Each user or team can be granted with an access to a project and its environments.

Workspace Owner and Admins have automatic access to all projects and environments. Project creator also has full access to the project by default.

Workspace members can access project environments by explicitly granting them access to the project (individually or through a team).

Only users with full project access (e.g. workspace owner, admin or project creator) can create/update/delete environments and manage user/team project access.

Environments

Each project can have multiple environments. Those environments are used to manage secrets and other resources like webhooks and integrations.

Each environment has it's own unique name within the project.

The ability to create own name together with the use of environment groups give you the freedom to have different environments for different purposes (like different apps in monorepo) within one project.

Users can be granted with environment access individually to each environment or through a team. Users and teams can also be granted with access to all environments in a project.

Each user or team with granted access to an environments can have one of the following roles: Viewer, Editor or Admin.

• Viewer can only view the environment secrets, no access to the webhooks and integrations, can only create environemnt account with permissions secrets.read.
• Editor can view and edit the environment secrets, read-only access to the webhooks and integrations, can create environemnt account with permissions secrets.read, secrets.write and webhooks.read.
• Admin can view, edit and delete the environment secrets, full read/write access to the webhooks and integrations, can create environemnt account with all permissions.

Secrets

In each environment you can store secrets like API Keys, database credentials, etc. Each secret consists of a key and a value and optional description. Every change you make to the secret's key or value will be tracked and persisted in the changelog. You can easily revert those changes later. All secrets are encrypted and securely stored in the database.

Using the web dasbhoard you can edit the secrets using a form or as a plain file in dotenv format with optional vim mode (I use vim btw). You can also easily copy the secrets to clipboard in a dotenv or json format.