Documentation
The repository web UI
The host that serves git over HTTP also serves a browser
surface over every hosted repository — one interface for the instance, not one
per repository. It comes up with the backend: /backends enable git-http plus a
host in git.http.vhost serves the transport, the browser surface and the
workflow runner protocol together, because they are one product on one host.
There is nothing to configure beyond that. What a visitor sees is decided by grants.
Pages
| Path | Page |
|---|---|
/ | repositories the viewer may read |
/-/login, /-/logout | sign in and out |
/-/new | create a repository |
/-/settings | instance settings, including runner registration |
/{repo} | home: root tree, README, clone URL |
/{repo}/src/branch/{branch}/{path} | a directory, or a file with syntax highlighting |
/{repo}/raw/branch/{branch}/{path} | the file's bytes |
/{repo}/commits/branch/{branch} | history |
/{repo}/commit/{oid} | one commit's diff |
/{repo}/branches | branches, with delete |
/{repo}/pulls | open pull requests |
/{repo}/pull/{slug}/{target} | one pull request, with merge and close |
/{repo}/workflows | what the repository runs, and its runs |
/{repo}/workflows/{run} | one run's jobs and logs |
/{repo}/settings | repository secrets, variables and retention |
Addresses follow Forgejo's. In place of branch/{branch}, tag/{tag} or
commit/{id} browses a tag or a commit, and a branch or tag keeps the slashes
in its name: /proj/src/branch/feature/login/README.md.
Pages are templates compiled into the binary and styled from the Everlock website's own tokens, so the browser surfaces read as one product. Syntax highlighting is shared with the site backend.
READMEs and other .md files are rendered as GitHub-flavoured Markdown:
tables, task lists, footnotes, > [!NOTE] alerts, bare URLs as links, and
heading anchors a table of contents can link to. Since anyone who can push
writes these files, raw HTML in them is dropped, and a link that would run
script (such as javascript:) keeps its text but goes nowhere. Every page
also tells the browser to run script only from the UI's own files.
What a visitor sees
Every page resolves the viewer's grants as it renders. An unauthenticated
visitor is evaluated as the built-in anon user, so public browsing is a grant
like any other:
/users grant anon */git/my-project reader
That repository is now readable without signing in. An instance that should show
nothing publicly is one that grants anon nothing.
Authorization runs before a repository is opened, so a repository the viewer may not see is indistinguishable from one that does not exist. The repository list shows only what the viewer may read.
Capabilities follow the same roles the rest of the Git backend uses:
reader— browse trees, blobs, history, pull requests and runs.writer— delete a branch, start a workflow run.owner— set repository secrets, variables and retention.
Starting a run takes writer because it is the same power as pushing a commit
that would have started one. Reading a run takes the same access as browsing the
repository, because a build log quotes the code that produced it.
Registering a workflow runner is instance administration rather than any one
repository's business, so it lives under /-/settings and is offered to an
instance administrator only.
Sessions
Signing in sets a cookie signed with a key generated at start and held only in memory, so a restart signs everyone out.
That is deliberate. A session proves identity and nothing else: because every
page re-resolves grants as it renders, revoking a grant takes effect on the next
request rather than at the next sign-in. The cookie is HttpOnly and
SameSite=Lax, and Secure wherever the host is not local.
Pull requests in the browser
A pull request page derives everything from its ref — there is no second copy of
the change in a database. From refs/pull/{slug}/{target} the page computes the
commits it adds, its diff against the commit it last shares with its target, and
a mergeability chip worked out on demand.
Opening one is a push, so it needs no account:
See Pull requests for the full scheme and the
matching /git pr commands.