Skip to main content

Getting Started Overview

Cloudgeni is not one monolithic workflow. It is a small set of connected surfaces:
SurfaceWhat it doesWhat it depends on
Git integrationsBrings in repositories, enables repository settings, and creates the PR path for changesA connected Git provider
Cloud integrationsGives Cloudgeni live account context and resource inventoryA connected cloud account
Scans and findingsProduces repository or cloud findings to review and act onA selected repository or cloud account
Agent sessionsLets you ask for changes, continue remediation work, or import resources into IaCUsually Git, often cloud, sometimes documentation context

The Practical Setup Order

For a new organization, the useful order is:
  1. Connect a Git provider
  2. Connect a cloud account
  3. Pick one workflow
  4. Expand only after the first workflow is working
That order lines up with the onboarding step model in the backend. The first two completion checks are active Git integration and active cloud integration.

Choose A First Workflow

If you want code-side feedback first

Start with Static Analysis. You only need a Git integration and a selected repository. This is the fastest way to see file-level findings and validate that repository access is working.

If you want live cloud visibility first

Start with Cloud Compliance or Cloud Monitors. These workflows use a connected cloud account and focus on live infrastructure state rather than repository content.

If you want an agent to make changes

Start with AI DevOps. Agent sessions can be launched directly, but they become more useful once you already have the Git and cloud context available to attach.

If you want to recover IaC from existing infrastructure

Start with Cloud Resource Import. That workflow comes from the Cloud Resources area and hands off into the same agent-session system used for other guided changes.

How Changes Actually Land

Cloudgeni is Git-first for change delivery. Even when you start from a finding, a drift, or a cloud resource import, the end state is still a repository change path: branch, pull request, and review. The product is not designed around direct mutation of your cloud environment.

What To Ignore At The Start

Do not try to turn on every feature at once. You do not need to set up:
  • PR reviews before you have a repository worth reviewing
  • Configuration drift before you trust the repository and cloud mapping
  • Custom policies before the default flows are already useful

Next

Connect Git

Set up repository access and repository-level features.

Connect Cloud

Choose the least-complex cloud access pattern that still supports your use case.