Introduction

Unbe gives your team one encrypted source of truth for application secrets, scoped to the exact service and environment that needs them.

What is Unbe?

Unbe replaces copied .env files, credentials in chat, and manually maintained deployment values with a shared secrets workflow. People manage access and history in the dashboard; local processes and automation receive values through the CLI.

The key idea

Your application receives secrets as environment variables at runtime. The secret file does not need to become the source of truth.

How secrets are organized

Unbe resource hierarchy

Workspace
└── Project
    ├── development
    │   ├── DATABASE_URL
    │   └── RESEND_API_KEY
    └── production
        ├── DATABASE_URL
        └── RESEND_API_KEY

Workspace

The team boundary for members, projects, tokens, billing, and audit history.

Project

One deployable app or service, such as an API, web app, or worker.

Environment

An isolated set of values for a release lane such as development or production.

Secret

A named encrypted value with a safe preview, version history, and audit events.

Ways to use Unbe

Dashboard

Create resources, edit secrets, invite teammates, issue tokens, roll back versions, and inspect audit history.

CLI

Select a target, pull or import values, and run local commands with secrets injected into their environment.

Recommended structure

Start with one workspace per team or organization. Create one project per independently deployed service, then mirror the environments that service actually uses. Avoid one giant project shared by unrelated applications; it makes access scopes and audit history less useful.