Last updated April 21, 2026
Organization Settings
Your organization settings define the shared vocabulary and visual language everyone on your team uses when building boards. Getting these right early saves you from inconsistency later — and they're easy to evolve as your architecture grows.
All settings are managed from Settings in the sidebar.
Configure your organization
Run through this checklist when setting up a new organization:
- Define your core element archetypes (Service, Database, API Gateway, etc.)
- Create context tags for cross-cutting concerns (team ownership, compliance scope, lifecycle status)
- Set up roles for your team members
- Add field templates for custom metadata you want to track on nodes
- Upload icons for your archetypes (or use the built-in icon library)
- Configure insight skills if you plan to use AI-powered analysis
Settings categories
Element archetypes
Archetypes define the types of elements (nodes and edges) you can place on boards. Each archetype controls:
| Property | What it does |
|---|---|
| Name | Identifier used across the platform (e.g., "Service", "Database", "API Gateway") |
| Description | Explains what this archetype represents |
| Visual primitive | The shape type — node, container, region, or edge |
| Icon | Custom icon displayed on board elements |
| Color / styling | Default appearance when placed on a board |
| Containment rules | Which archetypes this one can contain (e.g., a "System" can contain "Services") |
Archetypes keep your boards consistent. When a plugin pushes data via Board Builder, it references archetypes by name so elements render correctly.
Context tags
Tags are taxonomy labels you attach to nodes and edges for filtering and grouping. Think of them as cross-cutting categories — "team-payments", "deprecated", "pci-scope" — that let you slice your architecture in different ways.
Tags are organization-wide and available across all workspaces and boards.
Advanced config
Containment rules
Archetypes support containment rules that define parent-child relationships between element types. This is how you model logical nesting — a "System" archetype can contain "Service" archetypes, a "Region" can contain "Availability Zones", and so on.
Containment rules are enforced when elements are placed on boards, both through the UI and when plugins push data via Board Builder. If a plugin tries to nest an element inside an archetype that doesn't allow it, the operation will be rejected.
Visual primitives control rendering behavior:
| Primitive | Behavior |
|---|---|
| Node | Standard element — fixed size, icon + label |
| Container | Expandable group — can hold child nodes inside it |
| Region | Background zone — visual grouping without strict containment |
| Edge | Connection between nodes — line with optional label |
Icon storage backends (self-hosted)
For self-hosted deployments, icons can be stored locally or in S3. The backend is selected via the ICON_STORAGE_BACKEND environment variable.
Local filesystem (default — good for development):
BASH# Defaults to public/icons relative to the server root ICON_STORAGE_PATH=public/icons
AWS S3 (recommended for production / ECS deployments):
BASHICON_STORAGE_BACKEND=s3 AWS_BUCKET_NAME=your-bucket-name AWS_REGION=us-east-1 # When running in ECS, credentials are auto-discovered from the task IAM role. # Explicit keys are only needed for local dev with S3: # AWS_ACCESS_KEY_ID=... # AWS_SECRET_ACCESS_KEY=...
SVGs are stored organized by {provider}/{version}/{filename} (e.g., aws/2024-01/s3.svg) and served with aggressive CDN caching headers in production.
Start with a few core archetypes and tags — you can always add more later. Over-configuring upfront usually means half your archetypes go unused.