Sign in

Search issue titles and bodies, change requests and comments. Private repositories you cannot read are not included.
vole
Clone

Read only, no credentials:

https://rodent.software/git/vole.git

Write over SSH with a registered key:

git clone ssh://git@0.0.0.0:2222/vole.git

A free and open-source forge that lives in your Git repo.

Code

392 commit(s) on main

Compare History
Merge change request 01M70WES5ZZDJ6RP226WB11BBZ: Let people rename and remove their own passkeys keenan · 6m ago 4b8c9e1d
source preview history blame raw 3.9 KiB

Vole documentation

Vole is a forge that lives in your Git repo. It is for developers and small teams who want their repository to keep working even when someone else’s cloud does not.

New to Vole? Start with Getting started. It takes you from a source checkout to a repository you can clone.

After that, pick the page that matches what you want to do.

Everyday use

Page What it helps you do
Getting started Build Vole, create an account, and make your first repository
Issues Track bugs and tasks, comment on them, and edit them
Change requests Ask for a change request to be reviewed, approved, and merged
Workflows Add workflows, define jobs, and publish artifacts
Runners Start a machine, execute jobs, and report results
LFS Store large files and lock files that Git cannot merge
Releases Publish a release with notes, source archives, and binaries
Sites Serve a repository branch as a website
Go modules Import a public repository with go get, with no vanity service in front of the forge

Reference

Page What it helps you do
Workflow reference Look up every workflow field, limit, and default
Image reference Look up every .vole/images field, limit, and default

Running an instance

Page What it helps you do
Deploying Put an instance on a server with a first-boot file
Configuration Change addresses, limits, and site settings
Accounts and access Add accounts, manage SSH keys, and set permissions
Operations Back up, recover, and clean up an instance
Load testing Measure throughput and latency on a real instance
Packages Build, install, and upgrade a .deb or .rpm
CLI reference Look up a command or option

Design

Architecture explains how trust, storage, and the code are organized.

Terminology

Use one word for each concept, in the interface and the guides:

  • account: the identity that owns keys, passkeys, sessions, and roles. The CLI spells its commands vole admin account ...; vole admin user ... remains as an alias. The database file is data/users.db; in prose it is still an account.
  • repository: the Git repository and what belongs to it. The CLI uses repo, URLs use /<name>, and the forge’s own pages live under /-/; do not call it a project.
  • change request: a proposed branch reviewed before landing. The CLI uses change and the route is /changes.
  • enrollment link: the one-time link that lets someone register a passkey and sign in. The CLI command is vole admin account invite, and some code calls it an invite.
  • instance admin: the instance-wide admin role. Say “instance admin”, not “administrator”, when that is what you mean.
  • sign in / sign out: the browser action. login and logout remain in routes, setting names, and code.

The data/users.db filename and the user command aliases keep their historical spellings; everything the interface and documentation say uses the words above.

A few conventions

  • Examples assume vole is on your PATH, or that you are running ./vole from the repository root.
  • Use --remote <name> when a clone has more than one remote. The default is origin.
  • Commands accept options in the same styles Git does: --long value, --long=value, -o value, -ovalue, repeated options, and -- to stop option parsing.
  • Commands that write data need a Git remote. Read-only commands such as vole issue list work from a clone without network access.