Architecture

Security is a core part of Stashbase. The platform is designed around a simple principle: secrets management should improve security without slowing developers down.

This page provides a high-level overview of how Stashbase secures secrets, credentials, integrations, and infrastructure.

Overview

Stashbase uses a layered security architecture designed around workspace isolation, scoped encryption, and least-privilege access.

Secrets and sensitive credentials are encrypted before being stored and move through isolated encryption and access-control layers throughout the platform.

Encryption Hierarchy

Stashbase uses a layered encryption hierarchy designed to isolate workspaces, integrations, and sensitive resources.

At a high level:

Master Key Material
        ↓
Workspace Encryption Keys
        ↓
Derived Encryption Contexts
        ↓
Encryption / Decryption Operations

Workspace encryption keys are isolated per workspace and are used to derive additional encryption contexts for different parts of the platform such as:

• secrets
• integration credentials
• access tokens
• synchronization metadata

This layered architecture helps minimize blast radius, improve isolation between workspaces and services, and support secure separation between different categories of sensitive data.

Integration Isolation

Integration credentials are isolated from normal secret storage using separate encryption flows and integration-specific encryption contexts.

Workspace Encryption Keys
        ↓
Integration Encryption Context
        ↓
Encrypted Provider Credentials
        ↓
GitHub / AWS / Vercel / etc.

This separation helps reduce reuse of encryption material across systems and limits the impact of potential credential exposure.

Provider credentials used for integrations such as GitHub, Vercel, AWS, and other supported platforms are stored using dedicated encryption flows designed to isolate integration access from the rest of the workspace.

Integration access tokens are rotated and refreshed when supported by the provider.

Service Isolation

Stashbase separates responsibilities across internal services and infrastructure boundaries.

Only selected private services are permitted to perform sensitive encryption or credential operations following the principle of least privilege (PoLP).

Infrastructure components use isolated permissions and dedicated access controls wherever possible to reduce unnecessary exposure between systems.

Encryption Architecture

Stashbase encrypts secrets and sensitive credentials before they are stored in the database.

Workspace-specific encryption keys are used as part of a layered encryption model to protect secrets, integration credentials, and other sensitive data.

Encryption keys are managed using a dedicated key hierarchy designed to minimize blast radius and reduce unnecessary exposure between systems and workspaces.

Only selected private services have access to encryption operations following the principle of least privilege (PoLP).

Key Derivation

Stashbase uses key derivation techniques to separate encryption domains across different parts of the platform.

For example, integration credentials can use independently derived encryption contexts scoped to a specific provider or integration instead of reusing the same encryption material across the entire workspace.

This architecture helps isolate sensitive systems and reduce cross-system exposure.

Encryption at Rest

All production databases use encryption at rest.

Sensitive credentials and secrets remain encrypted while stored in the database and are only decrypted when required for authorized operations.

Secure Transmission

All communication with Stashbase uses HTTPS and TLS encryption.

Traffic between clients, APIs, integrations, and internal services is encrypted in transit to help protect against interception and unauthorized access.

Infrastructure Security

Stashbase infrastructure is designed around isolation, least privilege, and managed cloud security controls.

Security practices include:

• encrypted infrastructure services
• private internal services
• role-based access controls
• managed TLS certificates
• network-level protections
• continuous monitoring and logging

Infrastructure access is restricted to authorized systems and operators only.

Logging & Auditability

Stashbase maintains structured internal security and operational logs for important system events such as:

• authentication events
• API key usage
• permission changes
• integration activity
• synchronization failures
• security-related operations

Logs are used to monitor platform integrity, troubleshoot issues, and investigate suspicious activity.

Sensitive secret values are excluded from logs.

Security Boundaries

Stashbase is designed to minimize unnecessary exposure to plaintext secrets and sensitive credentials.

However, like most managed secrets platforms, some server-side operations may require authorized services to perform encryption or decryption operations in order to support integrations, synchronization, or runtime secret delivery.

We aim to be transparent about these boundaries and continuously improve isolation and security controls across the platform.