Setup

Set up MLReps

Two steps, the same whatever your code is built with: connect your code, and turn on checks. MLReps reads your code with the CLI, in your pipeline or on your laptop, so your CI and where you deploy change nothing — they only change which snippet a step shows you. Telemetry (data from your running app) is a third thing you can add later, and the product works without it.

What you get· an example repository, not yours

1 Connect a repository
2 MLReps reads the code
3 See how it fits together, and what to fix

Step 1 · your first repository

How do you want to connect?

Choose one to get started. You can add the other later, per repository.

Compare the ways in — and whether your code leaves your machine

	From your terminal or CI	GitHub App	Run it yourself
Does your code leave your machine?	No — only the result travels	Yes, a read-only copy	No — nothing is sent at all
What we end up storing	The same thing either way: nodes, edges, findings, counts and the commit they came from. Never your source, and never trained on.		Nothing — there is no account and no key on this one
Who has to approve it	You, for this one repository	Whoever may install an App on the organisation	You, plus whoever reviews a workflow file
Checks on pull requests	Posted by your CI, with your own token	Posted by the App, on every pull request	Posted by your CI — and that is the whole path
Time to the first map	About two minutes, from your own machine	One push after installing	There is no map on this one
Runtime, measured	A separate, optional step in either. Until it is set, Runtime reads not measured — and shows no numbers rather than zeros.		Not possible: there is nothing of yours here to attach it to

Not sure? Take the first. It is the only one where you can see exactly what was sent, in your own scrollback, before anything reaches us.

Not sure yet?

Check a public repository first

No account needed. Paste a public repository and it says, before you install anything, how much of your code each way reads — then opens a demo of its Optimize, Architecture and Findings, scanned for real.

Public repositories only. The check reads GitHub’s language counts and file names; the demo that opens after it scans the public code in our sandbox, and keeps the result for a day.

Setup is done without this

See it runningoptional

Your running app sends us data about its requests through OpenTelemetry (a standard way to report what an app is doing), and each request is placed on the route and the files it ran through. It takes a package, a few environment variables and a deploy — nothing above depends on it: the architecture, the issues and the pull-request checks all work without it.

On a Node.js or Next.js repository, npx mlreps telemetry does all of it except the deploy — it creates the key and writes it into the instrumentation file.

It needs a key that sends telemetry, which this page makes once you have an organisation.

Set up telemetry

The command line never writes to your repository

No commit, no branch, no pull request — `npx mlreps telemetry` holds no credential of ours that could. What it does, running on your own machine, is offer to put those lines into your compose file or your Kubernetes manifest: it prints the diff, asks, and leaves the change in your working tree for you to review and commit like any other. Terraform it names and does not edit, because an ECS task definition carries its environment inside a JSON string and a wrong edit to your infrastructure is worse than none.

What arrives, and what does not

Not collected by MLReps: logs, exception messages, URLs, query text, container and custom metrics. They stay where you already collect them.

The line is drawn when a batch arrives, not inside your process: of what your SDK sent, MLReps reads a fixed list of fields — each one checked to be the kind of thing it claims to be, so a query statement in a field meant to hold SELECT is refused — and never reads the rest. An exporter of ours that would apply that list before a batch leaves your network is not built.