Skip to content
MLReps
Sign in
Sign in
Back to the ways to connect

Connect with CLI

Two commands, in the project itself.

Your code stays on your machines; only the map of it is published. Add one package and run one command inside your project — on your laptop now, and later in the build pipeline you already have, so the map stays up to date as you merge.

Your CI — or your own laptop — runs the scan and sends only the graph it built; your code never leaves your machines. GitHub Actions, GitLab, Jenkins, CircleCI, Bitbucket or a terminal.

  1. Make a project key

    It belongs to an account, which is the one thing to do first: the card that mints it appears under these steps as soon as you have one. Make an account. It can send but never read: if it leaks, somebody could put a wrong picture in front of you, but could see nothing of yours. A publishing key is also refused by the address that takes telemetry, so it is of no use to anybody who finds it anywhere other than your pipeline.

  2. See it here now, from your own machine

    Two commands, in the project itself. The second one reads this folder’s git remote, opens your browser with a code to match, and asks you to approve this machine, for this one repository. Then it writes the key into .env.local, adds that file to .gitignore and publishes the first scan — you paste nothing.

    in your repository

    npm i -D mlreps

npx mlreps setup
    Or export the key and scan, by hand

    with a key you already have

    npm i -D mlreps

export MLREPS_KEY=<your project key>

npx mlreps scan . --publish

    Installed with npm i -D because nothing has been read yet — if your project uses pnpm, yarn or bun, change that first line, and this block says which once a scan has landed. You can skip the install entirely — npx mlreps scan . --publish fetches it for the one run. npx mlreps doctor says what it found on this machine.

    When it lands, the terminal prints the link and your repository is at your dashboard — what the scan found, the six indices, and the architecture one click along the rail. The key is for writing only: nothing on these screens can be read with it.

  3. Then keep it current, on every push

    This is the step that matters: it keeps the dashboard up to date, so you never need a terminal for this again. It runs on your main (default) branch only, on purpose — reports from every branch would make this a picture of whichever job finished last.

    .gitlab-ci.yml

    mlreps:
  image: node:24
  variables:
    GIT_DEPTH: 0
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  script:
    - npm install
    - npx mlreps scan . --publish
  # MLREPS_KEY goes in Settings → CI/CD → Variables, masked and protected

    The endpoint is /api/scan/v1/report, and the response to every publish is the diagnostic: what we stored, what we could not read, and what was swept out of it. --publish is what makes it appear here; without it the scan runs on your machine and sends nothing.

  4. Optional · see it running

    One command sets up the rest, and Runtime starts showing measured latency instead of not measured. On a Node.js or Next.js repository, npx mlreps telemetry writes the instrumentation file and mints the credential itself; what is left is one secret and a deploy.

    See that step

Pull-request checks, and what the CLI reads — reference, not a step. The same two lines also post a check: npx mlreps check . with the workflow on this page.

What is in your scrollback

Before publishing, the command prints the counts it is about to send, and ends on Published … and the link to it. Nothing is sent on a run without --publish.

If nothing arrives

Empty is three different things, and they have three different fixes — which one, and how to tell.

Where the workflow file lives

In your repository, reviewed in a pull request like any other change. We print it here; we do not write to your repository, and this path never gives us the ability to.

Want nothing to reach us at all? Run it in your own pipeline — checks only, no dashboard

The scan runs in your own build pipeline (CI), on code that is already checked out there, using the access your build job already has, and posts a check on your own pull requests. Nothing reaches us — not your source, not the findings, not a list of your files — because nothing on our side analyses it, so there is nowhere to send it. No account, no key.

  1. Try it where you are standing

    It prints what it found and always finishes with success (exit code zero), so it never breaks a build — including its own.

    in a terminal

    npx mlreps scan .
npx mlreps check . --dry-run

    --dry-run shows the check it would post on a pull request, without posting it, so you can read what your team would see.

  2. Add the workflow

    It already has the two lines people usually forget: the permissions block, without which the job cannot post its check, and the head commit, without which the check lands on a temporary merge commit and the pull request shows nothing.

    .github/workflows/codebase.yml

    name: MLReps

on:
  pull_request:

# Without this, GITHUB_TOKEN cannot write a check run and every run ends in a 403.
permissions:
  contents: read
  checks: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm install
      - run: npx mlreps check .
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # On a pull request, GITHUB_SHA is a merge commit that exists nowhere in
          # the repository — a check run posted against it is invisible.
          PLATFORM_HEAD_SHA: ${{ github.event.pull_request.head.sha }}

No dashboard, because we hold nothing

There is no architecture map, no findings history and no trends this way — we can only draw those from data of yours that reaches us, and this way nothing does. You get the check on each pull request. What appears, and where.

You can change your mind later

Publishing is one flag and one key away: the same scan, run the same way, with --publish added.

Nothing has arrived

Empty is three different things.

A single “no data” message would make you guess which one you are in. Here are all three, with the line that tells them apart. MLReps cannot tell you which one it is, because two of them happen on a machine it has never seen. Every example below is exactly what the command prints.

It ran, and nothing was sent

A scan with no --publish, or with nothing to prove whose scan it is, finishes on your machine and sends nothing — and says so in three lines.

what it printed instead
Nothing was sent: this ran on your machine only.
Add --publish to put this on your dashboard — the architecture map, the issues and the trends.
It needs a project key in MLREPS_KEY; make one at https://www.mlreps.com/start

A run that did reach us ends on these, and your scrollback has them or it does not:

the end of a publish that worked
Published acme/storefront at 8f2c1a9d.
See it: https://www.mlreps.com/platform?repo=acme%2Fstorefront
Next: open it signed in to the account that made this key.

It ran, and the publish was refused

The scan finished and we did not take it. Every refusal is one line beginning Not published: — so a search of a CI log for that phrase finds all of them — and the map stays as it was rather than half-updating. This is the one people meet: a folder with no git remote has no repository name to be filed under.

a refusal, in the product's own words
Not published: this checkout has no git remote, so the scan cannot be filed under a repository name — a folder name is not one. Add a remote (git remote add origin <url>), or publish from CI.

It arrived — under a different repository

A scan is filed under the git remote of the folder it ran in, not under the screen you were watching. The report is not lost — it is on that other repository.

how to tell
$ git remote -v
origin  https://github.com/acme/storefront-v2.git (fetch)

This is the one that looks like a bug and is not. Your repositories lists every one that has published — the scan is under one of them.

What we will not do while it is empty

Show an architecture with no commit on it, a zero where a measurement belongs, or a verdict about the whole repository computed from nothing. An empty screen that says which empty it is costs you one read; a confident wrong one costs you the next three decisions.