Vectrum
Sign In
VectrumPublic
Like1 likeFork0 forks
JjohannSoLet repository admins transfer a repository to an organizationHistory
PreviewCode
36 lines · 8.6 KB
Raw

Features

  • Accounts: sign up, sign in, profiles, password change (PocketBase auth: bcrypt-hashed passwords, token sessions)
  • Two-factor authentication with an authenticator app (TOTP: 1Password, Google Authenticator, Authy…): set up under Settings → Two-factor auth by scanning a QR code, with ten one-time recovery codes for a lost device. It guards signing in with a password, on the website and in the Android app; SSH keys, API tokens and connected apps work as before
  • Repositories: public or private, rename, transfer to an organization (or back to your account), delete, optional README on creation
  • Collaborators: give other users push access to a repository
  • Organizations, like on GitHub: accounts that own repositories for a team, at /<org>/<repo>. Whoever creates one is its owner and invites people by username (Settings → Organizations, or the organization's Members settings). Invited people accept or decline from their dashboard. Each member has a role that applies to all of the organization's repositories: Read (sees them, private ones too), Write (pushes, manages issues and pull requests), Admin (also creates repositories, changes their settings and deletes them) or Owner (also manages the organization, its members and invitations). Owners change roles and remove members at any time; an organization always keeps at least one owner. Single repositories can still add outside collaborators. Agents can create repositories in organizations where their person is an admin or owner (create_repository with owner)
  • Forks: anyone who can read a repository can fork it (the Fork button) into a copy of their own, of its default branch or all branches. Forks carry a Fork label and a "forked from" link everywhere they're listed, and the original lists them under Forks. A fork's front page says how far it is ahead of and behind the original, with Sync Fork (a fast-forward, or a merge commit if the fork has commits of its own) and Contribute (a pull request back). Forks of private repositories stay private
  • Git over SSH: built-in SSH server (default port 2222). Add public keys under Settings → SSH keys
  • Git over HTTPS: smart HTTP protocol (v0 and v2). Authenticate with API tokens
  • Container registry: every repository is also a Docker/OCI registry, like ghcr.io. docker push <host>/<owner>/<repo> (or <host>/<owner>/<repo>/<name> for more images per repository) with the same visibility, collaborators and API tokens as the code. Multi-platform images, cross-repository blob mounts, chunked uploads and the referrers API (signatures, SBOMs) are supported. Images are listed under the repository's Packages tab, where writers can delete versions
  • Releases: publish a version from a tag, with markdown notes and files to download (binaries, installers, checksums) of any size, plus the source code as zip and tar.gz. Drafts and pre-releases; a release made for a new tag creates it and starts the workflows a push of it would. Files can be uploaded from scripts and CI with curl, and /releases/latest/download/<file> always links the newest version
  • Wikis, like GitHub's: Markdown pages written in the browser (with preview, page history, old revisions and their diffs) or cloned and pushed as a git repository of their own, <repo>.wiki.git. [[Page Name]] links, a custom _Sidebar and _Footer, and images and other files from the wiki's repository. Collaborators edit, readers read; the owner can turn the wiki off under Settings
  • API tokens: read-only or read & write, for all repositories or selected ones, with expiry. Only a hash is stored
  • Web editor: CodeMirror with syntax highlighting and markdown preview. Create, edit, rename, upload and delete files, committing to the current branch or to a new one, which then goes straight to opening a pull request
  • Code browsing: file tree, highlighting (Shiki), rendered READMEs (sanitized HTML), raw files, image previews
  • History: commit log per branch or file, commit diffs, recent-activity dashboard
  • Branches: create a branch from any other on the Branches page, and delete branches there
  • Issues as a Linear-style project tracker, per repository:
    • Workflow statuses (Backlog → Todo → In Progress → In Review → Done / Canceled), priorities, assignees, labels, estimates and due dates
    • List view grouped by status, priority or assignee, and a kanban board with drag and drop
    • Filters (assignee, priority, label, "My issues"), scopes (All / Active / Backlog) and orderings, kept in the URL so views can be shared
    • Quick-create dialog and keyboard shortcuts: C new issue, J/K move, Enter open, S/P/A/L set status, priority, assignee, labels
    • Inline editing of every property, with an activity feed of changes next to the markdown comments
    • Anyone who can read a repository can open issues and comment, but only collaborators and the owner can change an issue (title, description, status and all other properties). Only an issue's creator and the repository owner can delete it. Labels are managed under Settings → Labels or created from the label menu
  • Actions with self-hosted runners: workflows in .vectrum/workflows/*.yml (a subset of GitHub Actions syntax) run on push or by hand, on runners you register for one repository or for all of yours. Live logs, cancel and re-run, and CI status marks in the commit list
  • Pull requests: propose merging a branch into another, of the same repository or from a fork, with a conversation, reviews (approve, request changes, comment), comments on lines of the changes in threads that can be resolved, checks from workflow runs, and merging as a merge commit or squashed. The author and collaborators can edit the title, description and base branch, mark it as a draft, close and reopen it. "Fixes #12" links an issue, which moves to In Review when the pull request opens and to Done when it's merged into the default branch. Pushed branches without a pull request (yours, and your forks') are suggested on the repository's front page and Pull Requests tab
  • Branch protection: rules by branch name or pattern (main, release/*) that require pull requests, a number of approvals of the latest commit, passing checks, and block force pushes and deletion. They hold for git pushes (through a pre-receive hook), the web editor, agents and merges alike
  • Agents as actors: what an agent does is recorded as the agent's, done for its person: commits name it as committer, comments, reviews, issue changes and workflow runs say "Claude Code for alice". Issues can be assigned to agents. By default agents push wherever their person may, main included; a repository can instead keep them to branches under agent/, so their work arrives through pull requests that people review. They can't approve, and only merge where a rule lets them. Their commits carry an Agent label in the history, with a Revert button there and on the commit's page; Settings → Agent activity lists everything your agents did and undoes a whole push
  • Events and webhooks: every push, branch and tag, issue change, comment, pull request, review and finished workflow run goes into the repository's event feed. Agents read it from a cursor (and can wait for the next event); webhooks POST it as JSON, signed with HMAC-SHA256 (GitHub-compatible headers), with retries and a delivery log under Settings → Webhooks
  • MCP server for AI agents: agents like Claude Code connect to /mcp and sign in with OAuth 2.1. You approve each one, read-only or read & write, for all repositories or selected ones. They can read, search and change code (exact replacements, patches or whole files), open and update pull requests, review and answer reviews, merge where allowed, manage branches, issues, labels and releases, create repositories, follow events, and run, wait for and debug workflows. Manage connected apps under Settings → Connected apps
  • Command line: vectrum, one Node.js file served at /vectrum.mjs, works like GitHub's gh for people and agents in a shell, signs in with OAuth, and is a git credential helper so pushes count as the agent's
  • Pages for agents: every page is also Markdown (Accept: text/markdown or ?format=md), and /llms.txt and /<owner>/<repo>/llms.txt describe the server and a repository (with its AGENTS.md/CLAUDE.md)
  • Code search in a repository's files, for people (the Search code box) and agents (search_code)
  • Android app: repositories, code, issues, pull requests (review and merge), commits, workflow runs and releases on your phone, in the website's look. See mobile.md
  • Light and dark mode