Quickstart

This guide follows BIMP’s seven-step onboarding flow. By the end, you will have an organization, an owning team and routine, a connected code provider, at least one tracked repository, and a first policy decision to review.

Before you begin

You need:

• an account allowed to sign in to your BIMP environment;
• permission to create or onboard an organization;
• access to a GitHub organization or GitLab namespace that contains a suitable repository; and
• a repository with a supported Dockerfile, Compose file, devcontainer definition, or conventional Helm values image declaration.

Provider installation or connection may require an administrator in GitHub or GitLab. If that is someone else, invite them before the coffee goes cold.

1. Create the organization

Sign in and choose Create organization. Enter the customer-facing organization name and continue.

BIMP keeps an incomplete organization inside the onboarding flow until an owner finishes or explicitly skips setup. This prevents a half-configured organization from looking ready for policy work.

2. Create the first team

Enter the team that will own the first selected repositories. Teams provide an operational home for repository ownership, routines, and notification routing. They do not replace organization roles or grant policy authority by themselves.

Use a name people already recognise, such as Platform Engineering, rather than inventing a BIMP-only team structure.

3. Schedule a routine

Choose how often BIMP should push routine fixes to the team. Set:

• a positive whole-number frequency in days;
• the UTC start date; and
• a routine time from the available 15-minute UTC intervals.

BIMP shows the next due date in your browser timezone while retaining the selected UTC schedule. The default interval is 28 days at 04:00 UTC. You can pause or revise the routine later under Settings → Operations → Teams.

4. Connect a code provider

Choose GitHub or GitLab and complete the provider flow:

• GitHub uses the BIMP GitHub App installation and returns you to repository selection after a successful installation.
• GitLab opens a connection dialog for the required provider details and returns you to repository selection after validation.

Provider credentials and webhook secrets are managed through the product. Do not copy them into policy reasons, repository files, or support messages.

5. Select repositories and branches

Choose one or more repositories. Visibility appears beside each repository name, and tracked branches are selected from the repository row.

BIMP scans the default branch and any branches you explicitly track. Repository ownership and routine assignment apply at repository level; tracked branches inherit that assignment while remaining visible as scan and remediation context.

After selection, BIMP scans the supported files and replaces the setup card with an in-flow results panel. Review the repositories, source artifacts, and base images detected before continuing.

No images found?

Confirm that the selected branch contains a supported file and that the provider connection can read it. A clean result is useful only when BIMP had something to inspect.

6. Create the first policy mapping

In the inline policy form, choose an observed source image and enter the target image your organization approves.

If Docker Hub recommendations are enabled, BIMP can suggest a current Docker Official Image target. A suggestion is advisory. It does not become policy until you select it, save the mapping, and publish the policy.

Add a concise reason that will still make sense during a later review. For example:

Move application builds to the organization-supported Node 22 Alpine line.

7. Review and remediate

BIMP shows the affected repository artifacts and the recommended images before anything becomes live. Check each source artifact, branch, affected image, and remediation timing.

Choose one of the publish paths:

• Publish makes the policy live and waits until the next routine date for routine remediation.
• Publish and remediate makes the policy live and queues immediate remediation for affected artifacts. BIMP asks for a second confirmation because this path can create pull or merge requests now.

Security Administrators and Owners can identify an urgent publish as a security incident. In that mode, affected rows show immediate remediation and provider pull or merge requests receive the security-incident label.

Confirm the result

After publishing:

1. Open Repositories and select the tracked repository.
2. Confirm the source artifact and detected base image.
3. Check the policy-derived state and approved target.
4. If you remediated immediately, open the linked pull or merge request and review the proposed source change.

BIMP creates the change path. Your existing review, CI, approval, and deployment controls still decide whether that change ships.

Continue operating

• Learn how drafts and versions work in Policy management.
• Tune ownership and delivery in Remediation and routines.
• Prepare reviewers with Exception workflows.