Brainboard's documentation
Website 🏛️Go to the app ↗
  • Welcome
  • Getting started
    • Fast track
    • Start with a template
    • Start with AI
    • Use cases videos
    • Brainboard philosophy
  • Cloud design
    • Left bar
      • Cloud resources
      • Input & output
    • Design area
      • Node
      • ID card
      • Connectors
      • Versioning
      • Graphical options
    • One action
    • Code Edition
  • Data
    • Data structure
      • Project
      • Environment
      • Cloud architecture
        • Terraform files
        • Readme file
        • Architecture Synchronization
        • Remote backend
      • Template
    • Cloud providers
      • Supported cloud providers
      • Customize provider configuration
      • Unsupported cloud providers
    • Terraform / OpenTofu
      • Modules
        • Module
        • Import modules
        • Manage module
        • Terraform registry credentials
        • Use modules
    • Disaster recovery
  • Automation
    • CI/CD engine
    • Supported plugins
      • Terraform
      • Security
        • Trivy
        • Tfsec
        • Terrascan
        • OPA
        • Checkov
      • Infracost
      • Notifications
        • Email
        • Slack
        • Microsoft Teams
      • Webhooks
    • Pipelines
    • Workflow templates
    • Drift detection
      • Types of drift
      • Remediation
    • Self-Hosted Runner
      • Deploy runner with Kubernetes
      • Deploy runner with docker-compose
  • Settings
    • Overview
    • Authentication
      • Login into Brainboard
      • Single sign-on (SSO)
    • Account management
    • Organization
    • Members
    • Teams
    • Roles & Permissions (RBAC)
      • Level of access
      • Organization RBAC
      • Project RBAC
    • Integrations
      • Git configuration
        • GitHub
        • Azure DevOps (ADO)
        • Bitbucket
        • GitLab
        • How to use
      • Cloud providers
        • AWS
        • Azure
        • GCP
        • OCI
  • Security
    • Data managed by Brainboard
    • SOC 2 Type II
    • Role Based Access Control
  • Help & FAQ
    • Shortcuts
    • FAQ
    • Migration
      • Import from AWS
    • Support
    • Glossary
  • Changelog
Powered by GitBook
On this page
  • Settings
  • Overview
  • Accessing Settings
  • Hierarchical Settings Management

Was this helpful?

Edit on GitHub
  1. Settings

Overview

Settings

Settings in Brainboard provides a flexible and hierarchical configuration system allowing you to manage settings at different levels of your organization.

Overview

Settings in Brainboard are organized in a hierarchical structure that follows this inheritance pattern:

Organization → Project → Environment → Architecture

This hierarchical approach ensures that configurations that are shared across the hierarchy can be managed efficiently while allowing for specific overrides at any level when needed.

Accessing Settings

Organization Settings

You can access Organization settings pages from the home page through the left navigation menu:

  1. Go to the Home page (click on Brainboard logo in the top-left corner)

  2. Click on the Settings icon in the left sidebar

  3. Select Organization

Project Settings

You can access Project settings pages from the home page through the left navigation menu:

  1. Go to the Home page (click on Brainboard logo in the top-left corner)

  2. Click on the Settings icon in the left sidebar

  3. Click on Projects

  4. Open the project menu using the 3-dots button, and click on "Change settings"

Environment Settings

You can access the Environment settings pages from the Project settings pages:

  1. Access the Project settings following the instructions above

  2. Click on an environment chip button from the environments list to access its specific settings

Architecture Settings

  1. Open your architecture

  2. Switch to the settings tab (using the tab selector in the middle of the topbar)

Hierarchical Settings Management

Inheritance chain

Settings follow a clear inheritance structure:

  1. Organization Level: The highest level, affects all projects, environments, and architectures.

  1. Project Level: Overrides organization settings for all environments and architectures within the project

  1. Environment Level: Overrides organization and project settings for all architectures within the environment

  1. Architecture Level: The most specific level, overrides all higher-level settings for a particular architecture

Visual Indicators

When viewing settings at any level, you'll see visual indicators showing:

PreviousDeploy runner with docker-composeNextAuthentication

Last updated 2 months ago

Was this helpful?

When a setting is locked at higher level (with the source of the lock)

When a setting is overridden at your level (the reset button shows that the value is set at this level)

When a setting is locked at your level preventing any lower levels update

Access Project settings page
Access Environment settings page
Access Architecture settings page
Settings defined at organization level and not overridden at any lower level
Setting defined at organization level being overridden at a project level
Setting defined at organization level being overridden at a project level and again at an environment level
Setting defined at organization level being overridden at a project level , then overridden again at an environment level and finally at the architecture level