Analyze a project without GitHub

When Deptools cannot read your repository, your pipeline sends the build files instead. You create a CI upload project, add one job to your pipeline, and every run produces an analysis identical to the one a GitHub project gets: same graph, same score, same dashboard.

Deptools only sees what a push delivers, and that push contains only your build files.

When you need this

Take this path when your code lives somewhere Deptools cannot reach:

• A self hosted GitLab, an internal Bitbucket, or any server closed to the outside.
• A platform Deptools does not integrate with yet.
• A repository your team will not grant access to, whatever the tool.

This path is Pro only. A CI upload project has no public repository behind it, so it is always private and always occupies one private slot. Organizations and plans explains what occupies a slot and what buying one bills you.

Create an organization without GitHub

A personal organization and a GitHub organization both accept upload projects, as soon as they are on Pro. You can stop reading this section and go create the project.

Create a separate organization when you want one of these:

• Team members, since a personal organization can never have any.
• A separate bill and separate plan for a client or a department.
• A clean split between what you analyze for yourself and what your team owns.

Open the organization switcher in the navbar, Add Organization, then the Create manually tab, and give it a name. No GitHub account is involved, and none can be attached later: the organization has no GitHub tab and holds upload projects only.

The three kinds of organization, and how the plan attaches to one, are covered in Organizations and plans.

Create an upload project

Open New project and choose Upload from CI. In an organization created manually and already on Pro, the form opens directly, since it is the only possible source there.

Two of those five are decided once. The build system and the dependency scopes cannot be changed: to correct either one, delete the project and create it again. The freed slot stays paid and reusable, so that costs nothing.

The subfolder is the opposite. Deptools has no files to look at yet, so nothing can be validated at creation. Enter your best guess: the first push checks it against your archive, and if it matches no module, the error lists the modules it did find. Change it in the project settings, and the next push uses the new value.

The project appears immediately, with no analysis. That is expected: there are no files yet. The first analysis comes from the first push.

Push your build files from your pipeline

Three things go into your pipeline: a key, two variables, and one job.

Get an API key

Two scopes are possible:

• A project key (dt_proj_...), valid on this project only. To create it, open the project, then the Integrations tab.
• An organization key (dt_org_...), valid on every project of the organization. Pick this one when several repositories push from the same CI, since one shared variable then serves them all. To create it, open the organization settings, then the API keys tab.

The key is shown once, at creation. You must be an owner or an admin. See Manage API keys for expiration and rotation.

Declare two variables

Add the scan job

Deptools serves a POSIX shell script that collects the build files, archives them and pushes them. It needs sh, tar and curl.

# One-off scan from your machine, the quickest way to test your setup
# Run from the repository root
curl -fsSL https://api.deptools.io/deptools-scan.sh -o deptools-scan.sh

DEPTOOLS_API_KEY="dt_proj_..." \
DEPTOOLS_PROJECT_UUID="b9c105b0-..." \
sh deptools-scan.sh --wait

deptools-scan:
  stage: test
  image: alpine:3.20
  before_script:
    - apk add --no-cache curl tar
  script:
    - curl -fsSL https://api.deptools.io/deptools-scan.sh -o deptools-scan.sh
    # add --wait to block until the result and use this job as a CI gate
    - sh deptools-scan.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

name: Deptools scan
on:
  push:
    branches: [main]
jobs:
  deptools-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # add --wait to block until the result and use this job as a CI gate
      - run: |
          curl -fsSL https://api.deptools.io/deptools-scan.sh -o deptools-scan.sh
          sh deptools-scan.sh
        env:
          DEPTOOLS_API_KEY: ${{ secrets.DEPTOOLS_API_KEY }}
          DEPTOOLS_PROJECT_UUID: ${{ vars.DEPTOOLS_PROJECT_UUID }}

stage('Deptools scan') {
  environment {
    DEPTOOLS_API_KEY = credentials('deptools-api-key')
    DEPTOOLS_PROJECT_UUID = 'your-project-uuid'
  }
  steps {
    sh 'curl -fsSL https://api.deptools.io/deptools-scan.sh -o deptools-scan.sh'
    sh 'sh deptools-scan.sh --wait'
  }
}

The script takes two options:

• --wait polls until the analysis ends and exits 1 if it fails, which turns the job into a pipeline gate. Without it, the job pushes and returns immediately.
• --dir <path> collects from another directory than the current one.

It also reads the branch and the commit SHA from GitLab CI, from GitHub Actions or from the local git checkout, and sends them as labels. DEPTOOLS_BRANCH and DEPTOOLS_COMMIT_SHA override that detection.

A cron job works as well as a pipeline. There is no cooldown on Pro, so you can push on every commit.

What gets collected

The script and the server apply the same allowlist. Everything else in the archive is discarded, so archiving too much is harmless, only slower to transfer.

The content of node_modules/, .git/, target/, build/ and vendor/ is never collected, at any depth, and neither are the macOS metadata files ._*.

Limits on the archive

The entry count is checked on the archive, before the allowlist runs. So prune node_modules/ on your side to keep a large project under the ceiling, even though the server would have discarded those files anyway.

Without the script

Any HTTP client works. The request is one multipart POST:

POST https://api.deptools.io/v1/projects/<uuid>/scan
Authorization: Bearer dt_org_...
Content-Type: multipart/form-data

# From the repository root: archive the build files
tar czf bundle.tar.gz $(git ls-files '*pom.xml' '*.gradle' '*.gradle.kts' \
  '*gradle.properties' '*libs.versions.toml' '*.sbt' '*project/*.scala' \
  '*project/build.properties' '*package.json' '*package-lock.json' \
  '*yarn.lock' '*pnpm-lock.yaml' '*pnpm-workspace.yaml' '*npm-shrinkwrap.json' \
  '*composer.json' '*composer.lock' \
  ':(exclude,glob)**/node_modules/**' ':(exclude,glob)**/vendor/**' \
  ':(exclude,glob)**/target/**' ':(exclude,glob)**/build/**')

# Push archive to Deptools
curl --fail-with-body -sS \
  -H "Authorization: Bearer $DEPTOOLS_API_KEY" \
  -F "bundle=@bundle.tar.gz" \
  -F "branch=$CI_COMMIT_REF_NAME" \
  -F "commitSha=$CI_COMMIT_SHA" \
  "https://api.deptools.io/v1/projects/$DEPTOOLS_PROJECT_UUID/scan"
# → 202 { "jobId": "abc123", "pollUrl": "/v1/scans/abc123/status" }

A 202 means the archive was accepted and the analysis started. Poll pollUrl with the same key to follow it. The response carries status, then a result block once it reads completed. Gate your pipeline on that block:

{
  "jobId": "abc123",
  "status": "completed",
  "createdAt": "2026-08-09T10:00:00.000Z",
  "result": {
    "overall_score": 7.4,
    "dependency_number": 182,
    "vulnerabilities_by_severity": { "CRITICAL": 0, "HIGH": 2, "MODERATE": 5, "LOW": 1 },
    "commercial_use": false,
    "direct_up_to_date": 84
  },
  "error": null
}

The push endpoint accepts 60 requests per hour and per IP address, the status endpoint 120.

What Deptools keeps from your archive

This is the only path where your files reach Deptools at all.

The archive is filtered as it arrives. It is never written to disk and never extracted into a directory tree: it is read as a stream, every entry outside the allowlist above is dropped immediately, and the rest is kept as text in a single snapshot. Nothing in it is ever executed.

That snapshot is deleted as soon as the analysis reaches a terminal state, whether it succeeded or failed. Deptools keeps the analysis result afterwards, the graph, the scores and the metrics, exactly as for a GitHub project.

So a source file that slipped into your archive is discarded before the analysis starts, and a build file is deleted when the analysis ends. See https://deptools.io/privacy for retention and personal data.

Check that the first push worked

The Integrations tab follows the setup end to end and updates on its own, no refresh needed. Its last step reports what happened to your first push: Waiting for your first push, then the analysis running, then First analysis received, or the failure and its reason.

Once the first analysis arrives, the project behaves like any other: the dashboard, the history and the exports all work the same way. One difference stays visible, and it is deliberate. Where a GitHub project offers a Run scan button, an upload project reads Scans are triggered from your CI. Deptools has no way to fetch your files on its own, so every analysis comes from a push.

When the push is refused

Rejections happen before the analysis starts, and the message names the cause. The script prints it, and prints the module list or the detected build systems when the response carries them.

An archive is never partly accepted. When one of these errors occurs, no analysis runs and no file is stored.

When the analysis itself fails

A 202 means the archive was accepted, not that the analysis will succeed. Two failures are specific to this path, and neither is a bug on your side:

• Maven parents and BOMs hosted on an internal registry cannot be reached from outside your network. They surface as analysis errors, and the rest of the analysis completes.
• Private packages, npm or otherwise, cannot be resolved from the public registry and are listed as skipped. A committed lockfile limits the loss, since the versions are then already pinned.

The other failures are the ordinary ones, and the project page names the cause.

Next steps

• Manage API keys to set an expiration and rotate a key without breaking a pipeline.
• Create many projects at once when a whole portfolio has to be connected.