Configuration Overview
Core concepts
Section titled “Core concepts”Before you start clicking through the sidebar, it helps to understand the main levels in Forgecroft.
Organization
Section titled “Organization”Your organization is the top-level account boundary in Forgecroft.
It is where you manage:
- Members
- Shared configuration
- Controls
- API keys
- Organization-wide defaults
Most teams have one organization per company or internal platform account.
Project
Section titled “Project”A project groups related Systems together.
Use projects to separate things like:
- Production vs non-production
- Platform vs application teams
- Different business units
A project can also carry project-level settings such as:
- Members
- Default tool config
- Notification configs
System
Section titled “System”A System is a repository or deployable root that Forgecroft reads and maps. It is the root of one graph — its Components (modules, databases, endpoints, config files, infrastructure) across every layer, with the Controls that govern them.
Each System has its own:
- Source location (the connected repository)
- Component graph
- Controls and Evidence
- Notifications
If your repository contains several deployable roots, each one is usually its own System. A project owns one or more Systems; see Core Concepts for the full model.
How the hierarchy works
Section titled “How the hierarchy works”The normal model is:
- Your team works inside one organization
- You create one or more projects inside it
- Each project owns one or more Systems, populated when Forgecroft reads a repository
In practice:
- Organization is where shared configuration lives
- Project is how you group related work
- A System is one repository’s graph, the thing a change is evaluated against
For most teams, the fastest path is:
- Create a project
- Connect a repository (see the GitHub App)
- Let Forgecroft ingest the repository into a System graph
- Wire the CI gate so changes are evaluated on every pull request
Some sidebar sections are only visible to organization admins.
Projects
Section titled “Projects”Projects are the top-level way to organize related Systems.
From the Projects area, you can:
- Create a project
- Set its name and description
- Add or remove project members
- Choose a default tool configuration for that project
- Attach notification configs to the project
Use projects to separate environments, teams, or business domains.
Settings
Section titled “Settings”The Settings section controls organization-wide configuration.
General
Section titled “General”Use General to view basic organization details and update the organization name.
Members
Section titled “Members”Use Members to manage access to the organization.
You can:
- Invite new members by email
- Choose each member’s role
- Update existing member roles
- Remove members
- Review pending invites
Shared configuration
Section titled “Shared configuration”Shared settings define reusable building blocks that projects and Systems can reference.
Tool configs let you define named tool and version combinations.
You can configure:
- Name
- Tool type
- Version
- Scope
- Organization default tool config
Use this to standardize which OpenTofu or Terraform version Forgecroft reads your infrastructure code against across your environments. Terraform and OpenTofu are an input Forgecroft reads, not something it runs.
Notifications
Section titled “Notifications”Notification configs define where Forgecroft sends updates.
You can configure:
- Name
- Channel type
- Channel destination or hint
- Targets on the detail page
Projects and Systems can attach notification configs as needed.
API Keys
Section titled “API Keys”API keys are machine credentials for automation.
You can configure:
- Key name
- Expiry
- Scope and permissions (see API Keys)
The full key is shown once when created. Store it securely.
Controls
Section titled “Controls”A Control is a per-Component constraint that Forgecroft checks a change against at the merge gate. Controls are derived from your declared and enacted evidence and evaluated deterministically — a given diff always returns the same verdict.
You can configure:
- Name
- Description
- Enforcement mode
- Scope (which Systems or Components it covers)
- The constraint the Control enforces
Use Controls when you want to warn on a change, or require review automatically, before it merges. See How It Works for how a change is evaluated against them.
What most teams should configure first
Section titled “What most teams should configure first”If you want the shortest path to value, configure these in order:
- One project
- Connect a repository so Forgecroft can ingest it into a System
- Wire the CI gate so changes are evaluated on every pull request
- Optional notification config
- Controls, tightened over time as your evidence grows