Catalog Settings¶

The catalog settings describe the projects of one organization. They are in the <Org> Admin group of the Admin menu. <Org> is the organization that you select in the top bar. Each setting belongs to that organization.

The Admin item shows only for platform administrators. A blueprint can add fields to environments and project types. The forms show those fields below the standard fields.

Permissions¶

Default Settings saves to the organization, so it needs organization:update. These routes are not organization routes. They use the union of your roles in all your organizations. See Permissions across organizations.

Environments¶

An environment is a place where a project runs, for example testing, staging, or production. Deployments, the release train, and the promotion pipeline use environments.

Create an environment¶

1. Open Admin > <Org> Admin > Environments.
2. Click New Environment.
3. Enter the fields in the table below.
4. Click Create Environment.

Allow Autonomous Deployments is one of the bounds of ADR 0017. The deploy and rollback steps of workflows need it.

Deploy and promote flags¶

Allow Direct Deploys and Allow Promotion are the can_deploy and can_promote fields of the environment:

Delete an environment¶

Click the delete action in the environment list. Imbi does not check if projects use the environment. It removes the environment and every relationship to it.

Project types¶

A project type is a kind of project, for example REST API or Library. Each project has a project type. Blueprints, scoring policies, document templates, and version formats can apply to some project types only.

Create a project type¶

1. Open Admin > <Org> Admin > Project Types.
2. Click New Project Type.
3. Enter the fields in the table below.
4. Click Create Project Type.

Deployable and Releasable are mutually exclusive. A project type can have one of them, or neither.

Delete a project type¶

Click the delete action in the list. Imbi does not check if projects use the project type. It removes the project type and every relationship to it, so those projects have no type.

Link definitions¶

A link definition is a type of link that a project can have, for example GitHub Repository or Grafana Dashboard. The Links card of a project offers each link definition of the organization.

1. Open Admin > <Org> Admin > Link Definitions.
2. Click New Link Definition.
3. Enter the fields in the table below.
4. Save.

The project link editor shows the URL Template as the placeholder text of the URL field. Imbi does not replace the placeholders in curly braces. The user enters the full URL.

A scoring policy of the type Link Presence checks that a project has a link of one link definition.

Imbi does not check if projects use a link definition before it deletes it.

Version formats¶

A version format is a regular expression that a release tag must match. Imbi checks the tag when a user cuts a release or promotes a release. The draft of the release notes also uses the formats to suggest the next version.

The organization has a list of formats on Admin > <Org> Admin > Default Settings. A project type can override the list.

Organization formats¶

1. Open Admin > <Org> Admin > Default Settings.
2. Under Supported version formats, turn on the formats to accept.
3. Optional: click Add custom format. Enter a name, and a pattern or a calendar scheme (see Calendar schemes). Use the test field to try a version. Click Save format.
4. Click Save changes.

The built-in formats are:

A format list saved before this release keeps the old semantic versioning pattern, which rejects a leading v. The list shows it as the built-in row with the new pattern, and Save changes is enabled. Until you save, Imbi uses the old pattern, but the test field uses the new one. To store the new pattern, click Save changes. For a project type, turn Semantic versioning off and on again, then save the project type.

A format list saved before this release can also keep the old calendar versioning pattern. The new pattern rejects tags such as 2026.09 that the old pattern accepts, so Imbi does not change it. The list shows the old pattern as a custom row, and the built-in Calendar versioning row is off. A save keeps the old pattern. To use the new pattern, turn on Calendar versioning, delete the custom row, and save.

Use Test a version string to see which enabled formats accept a version.

Calendar schemes¶

The built-in Calendar versioning format accepts year, month, and day, with an optional suffix. For a different calendar scheme, add a custom format and enter the scheme in calver.org notation in Calendar scheme. Imbi then makes the pattern from the scheme and uses the scheme to suggest the next tag.

Separate the tokens with ., -, or _. You can put the last segment in brackets to make it optional, for example YYYY.0M.0D[.MICRO].

The rules are:

• A scheme has one year token.
• A day needs a month. A week cannot have a month or a day.
• Each token can occur one time only.
• MODIFIER must be the optional last segment, for example YYYY-0M-0D[.MODIFIER].
• Only MINOR, MICRO, or MODIFIER can be optional.
• MM, WW, and DD are old spellings of M, W, and D.

The next tag that Imbi suggests:

• In a new calendar period (a new year, month, week, or day of the scheme), the counters go back to 0. An optional counter is left out.
• In the same period, a minor or major bump increments MINOR when the scheme has it. Else the last counter in the scheme increments, and the counters after it go back to 0.
• Imbi does not suggest a MODIFIER.
• A scheme with no counter gives the same tag for two releases in one period.

Examples, for a release on 17 April 2026:

Project type formats¶

1. Open the project type.
2. Under Version formats, turn on the override switch.
3. Turn on the formats to accept, or add custom formats.
4. Save the project type.

When the switch is off, the project type uses the formats of the organization.

How Imbi applies the formats¶

1. If one or more project types of the project have formats, Imbi uses the formats of all those project types together.
2. If not, Imbi uses the formats of the organization.
3. If neither has formats, Imbi accepts any tag.

A tag is valid when it matches one of the formats. Imbi matches the whole tag. When a user cuts a release with a tag that matches no format, Imbi refuses it with 400. A promote accepts a Git commit SHA (7 to 40 lowercase hexadecimal characters) as well as a matching tag.

Document templates¶

A document template is starter content for a new document. When a user creates a document from a template, Imbi copies the title, the content, and the tags of the template.

1. Open Admin > <Org> Admin > Document Templates.
2. Click New Document Template.
3. Enter the fields in the table below.
4. Click Save.

A template also has a type. It sets where Imbi offers the template:

The form does not show the type. A template that you make in the form has the type project. To set another type, send it in POST /organizations/{org}/document-templates or change it with PATCH. The organization documents page offers templates of every type.

Related pages¶

• Blueprints
• Scoring Policies
• Releases and Deployments
• Documents and Reports