# The Source guide

Set up Dbrij Source step by step: what you need, what to press, and how you know each step worked.

Canonical page: https://dbrij.com/products/source/guide

## Set up Source, step by step

By the end your code lives in private repos your team can reach, reviewed through pull requests and scanned for trouble.

Before you start, have these ready

- git on your machine.

1. ### Create a repository

  Private to you or the company. Start with a README for a first commit, or leave it empty to push a project you already have.
  [New repository](https://dbrij.com/source)
2. ### Make an access token

  Paste it when git asks for a password. It is shown once; copy it then.
  [Open tokens](https://dbrij.com/source/tokens)
3. ### Push your code

  `git push dbrij main`, after adding the repository as a remote named dbrij. When git asks for a password, paste the token.

  You will know it worked when your files show in the repository.
4. ### Open a pull request

  Review before it lands on main. Push a branch, then open a pull request from the repository page.
5. ### Run an AI scan

  Malware, backdoors, planted secrets. The scan reads main from the repository page, and can run on every push.

## How each part works

### [What Source is](#what-source-is)

Source hosts private git repositories. Tokens authenticate git over HTTPS. Pull requests carry review; the AI scan reads main for malicious or leaked code; Contributions and Badges count what lands on default branches.

Source is private git hosting for your code. It is real git, not an imitation: you clone, push and pull over HTTPS with the git you already have, so every tool you own already works. No plugin, no wrapper, no new commands to learn. Repositories follow the space switcher, so "my code" and "the company's code" are the same distinction here as everywhere else on the platform.

Keeping code on Dbrij buys two things a bare git host cannot show: a repository page that knows where this code is running right now on Hosting, and backups with a restore that is practised on a schedule rather than hoped for. A push to a connected repository is a deploy, with no third party in the loop.

### [Creating a repository](#creating-a-repository)

A repository exists the moment you create it. The one choice that matters is whether to seed it with a README: that gives it a first commit, so cloning it returns something. Leave it off when you are pushing a project you already have, and the repository shows "waiting for a first push" until your code arrives.

The repository page carries the file browser, commits, branches, pull requests and the README, plus the clone panel with your exact commands. Connection panels show where the code is running on Hosting, which project it belongs to, and the vault of sealed copies of what actually shipped.

### [Tokens, cloning and pushing](#tokens-and-cloning)

Git asks for a username and password. The username is your Dbrij handle, and the password is an access token. The clone panel on every repository page shows the exact commands with your clone URL, your branch and your username filled in; the shapes are:

Clone it

```
git clone <your clone URL>
```

Push a project you already have

```
git remote add dbrij <your clone URL>
git push -u dbrij main
```

Or skip the token entirely. Sign in once with the Dbrij command line and let it answer git for you: no token to make, copy or paste, and no password prompt waiting in another window.

Push with your Dbrij sign in

```
npx dbrij login
npx dbrij git setup
```

Tokens are built to be taken back:

- **Scope one to a single repository.** It is the safer default: if it leaks, only that repository is exposed. Or let it reach every repository you can.
- **Make it read only** for anywhere that only needs to clone, like a build that never writes back.
- **Give it an expiry**, and revoke it in one click the moment a laptop goes missing.
- **It is shown once.** Only a hash is stored, so nobody, including Dbrij, can read it back later.

Tokens belong to your account, not a company: one token opens whichever repositories you can reach, personal and company alike.

### [Push to deploy with Hosting](#push-to-deploy)

Point a Hosting service at a repository and every push to your branch ships it. Because Source and Hosting are the same platform, there is nothing to register, no webhook to fail, and no third party between your push and your deploy.

The connection reads back the other way too: the repository page shows which services are running this code right now, and every successful deploy seals a copy of exactly what shipped into the vault. Somebody who has lost a laptop and a repository knows, before they need it, that the platform still holds the code it deployed.

### [Running CI](#ci)

Add `.dbrij/ci.yml` to a repository and every push to a branch it names runs its jobs. Each job runs its steps one after another in the image it names, in a sandbox on the Hosting cluster, and the CI tab shows each run, each step, and the output. Pull requests show whether CI passed on their latest commit.

.dbrij/ci.yml

```
on:
  branches: [main]
jobs:
  test:
    image: node:22-bookworm
    steps:
      - npm ci
      - npm test
```

Values a job needs, like a deploy token, go in the repository’s CI secrets: they reach the steps only, never show again once saved, and are hidden in the output. To read Dbrij Secrets from a job with no stored token, give a machine a Source CI login for the repository and save its key there as DBRIJ_SECRETS_KEY.

CI minutes count against the Hosting plan of the repository’s space each month, and running CI needs a verified card or a paid plan, like a deploy.

### [Backups](#backups)

Every repository is bundled nightly to object storage, and the restore is an ordinary clone that Dbrij practises on a schedule, not on hope. Scheduled integrity checks confirm the bundles are actually restorable, which is the difference between a backup and a folder named backup.

On top of that, the deploy vault keeps sealed copies of everything that shipped, so the history of what ran in production survives independently of the repository itself.

### [Good to know](#good-to-know)

- Tokens belong to your account, not a company.
- Reviews are counted even though they leave no commit.
- Badges count your whole record, not one year.

- The subscription includes private repositories with real git over HTTPS, push to deploy straight into Dbrij Hosting, scoped access tokens you can expire and revoke, and nightly backup bundles with scheduled integrity checks.
- [Contributions](https://dbrij.com/source/contributions) shows your activity across repositories as a calendar graph.
- If you have not set a username, your git handle is generated for you; set one in your profile settings and it becomes your handle, while existing clone URLs keep working.
- Access is granted per person on the [Access](https://dbrij.com/product-access/source) page; the owner always has it.