Start with a read-only assessment.

What the assessment shows

• ✓ Coverage: which objects your repository defines, and which Flux object applies each one.
• ✓ Optional, with a snapshot from your cluster: whether Flux applied each object, and which Flux objects fail. You run one read-only command and send us the file. Without it, the assessment reads only your repository.
• ✓ Topology: how your repositories, Flux objects and clusters connect, including hub-and-spoke layouts.
• ✓ Platform-specific objects: which kinds your repository uses (for example OpenShift or Harvester objects), and which kinds no agent reads yet.
• ✓ Maintenance opportunities, counted by rules: for example deprecated API versions, containers without resource requests, or workloads without a disruption budget. The report names each file. It does not propose a fix.

See a sample report →

What it never does

• ✕ Connect to your cluster. It reads your repository, and the snapshot file if you send one.
• ✕ Change anything in your cluster.
• ✕ Open an MR, an issue or a comment.
• ✕ Send anything to an AI model. The assessment uses none.

What it does not include

The assessment is a map of your setup, not a list of fixes. Without an AI model, some work is not possible. These come later, in the dry run after onboarding:

• ✕ Upgrade proposals. They need the changelog read and the breaking changes checked.
• ✕ Resource sizing. It needs your usage metrics.
• ✕ Draft MRs or issues of any kind.
• ✕ An estimate of effort or cost.
• ✕ Objects that run in your cluster but are not in git. Finding them needs a full read of the cluster, which comes with onboarding.

From first contact to first MR

1. Reply and call.We reply within 3 business days. We confirm the fit and talk about your setup, your data rules and who reviews MRs. You get a one-page letter that lists every permission we ask for.
2. Read-only assessment.You invite our bot to one repository. Our target is 2 business days from read access to the report. You receive it and we walk through it with you.
3. Onboarding MR.One draft MR per deploy repository gives the bot read-only access to your cluster. Our target is 2 to 5 business days, and most of the work is on your side.
4. A dry run that writes nothing.The assistant runs the agents you chose and shows the proposals it would make: upgrades, resource sizing, monitoring gaps, availability risks.
5. First draft MRs.These start a day after you sign off the dry run. Small, labelled and capped per agent and per repository. One label pauses the bot at its next check.

Way 1: invite our bot

1. Invite.We send you the name of our bot account. Give it read access to one repository: Reporter on GitLab, Read on GitHub or Forgejo.
2. Tell us the branch.Tell us which branch your clusters deploy from. The census reads one fixed commit of that branch.
3. Remove the access.When you have the report, you can remove the bot again.

Way 2: send us a copy

1. Make one file.In a clone of the repository, run git archive --format=tar.gz -o assessment.tar.gz main. Use the branch your clusters deploy from. The file holds only that one commit, without the git history.
2. Send it.On the call, we agree how you send the file to us. No account and no access to your forge are necessary.