Sealrepo
Sign inStart free
Get started

Connect your repo to a dashboard project

Locking and unlocking on your own needs nothing but the free CLI and your free account. But to share access with a teammate, run a CI build, or recover a lost key — you need a project entry on the dashboard. Five seconds; one form.

What is a "project"?
A project is just a row in our database that gives this repo a name, a list of people who can use it, and a place to drop access codes and CI tokens. We never see your master key or your source — it all stays encrypted on your machine.

  1. Create the project in the dashboard

    Open sealrepo.dev/app, click New project, give it a name and a short description.

    sealrepo.dev/app

    New project

    Each project represents one repository sealed with the CLI.

    acme-billing
    Stripe webhooks + fraud rules
    Create project

  2. Copy the project ID

    After creation, the project URL on the dashboard has the form sealrepo.dev/app/projects/prj_xxxxxxxxxxxx. That last part — prj_xxxxxxxxxxxx — is your project ID.

  3. Link the local repo

    From inside the repo on your machine, after you've run sealrepo init:

    In your-repo/
    $sealrepo link prj_4f9a8b2c1d0e
    ✓Linked /Users/you/your-repo to “acme-billing” (prj_4f9a8b2c1d0e). Bound 1:1 to this repository.

    The link is written into the link block of your .sealreporc.json. From now on, every command that involves the dashboard (share, CI tokens, escrow — the optional cloud backup of your key) knows which project to talk to.

    Commit the .sealreporc.json
    .sealreporc.json is safe to commit. It contains your include / exclude patterns, the project ID, and an opaque hash of your local vault salt (used by the server to bind this project 1:1 to this repo — explained below). None of those are secrets. Committing the file means a teammate who clones the repo can run sealrepo unlock directly without re-running sealrepo link.

One project, one repo

Each project record on sealrepo.dev is permanently bound to a single local repository — the one you first ran sealrepo link from. The CLI sends an opaque hash of your vault salt the first time; the server pins it on the project row. From then on:

  • Teammates cloning the same repo share the same salt, so their sealrepo link returns match and Just Works.
  • A different local repo trying to link the same project is rejected with HTTP 409 project_repo_mismatch. This is the guard that keeps one paid project slot from being reused across multiple unrelated codebases.
  • Genuinely migrating to a new repo? The project owner can re-pin with sealrepo link --force prj_…. Force-relink is owner-only and is audit-logged as project.link.force on the dashboard.
Don't try to game the binding
We made the failure mode loud on purpose. If your team is running a monorepo or multiple microservices, each one should be its own project on the dashboard — that's how grants, audit logs, and billing stay aligned with how your code is actually structured. sealrepo init already refuses at the root of a monorepo to nudge you in that direction.

Unlinking vs. removing

There are three different “undo” actions; each does something different:

  • sealrepo link --remove only forgets the dashboard association on this checkout. The vault on disk is untouched, the server still has the project, the paid slot is still consumed. Useful when retiring a single machine.
  • Delete project on the dashboard releases the paid slot and the server-side repo binding. The local vault is left untouched. Owner-only.
  • sealrepo remove permanently uninstalls sealrepo from this repo: decrypts files back to plaintext, deletes vendor/ and the config, and (when linked) emails the project owner immediately. See the Remove sealrepo doc.
Next
Share access with a contractor
→