Skip to content

Repositories

Every organization gets a private, managed Git namespace - no separate Git host to sign up for or connect. Create repositories, clone them over HTTPS or SSH, and mirror repositories in from (or out to) another host.

How your organization gets a Git namespace

Section titled “How your organization gets a Git namespace”

A Git namespace is provisioned automatically the first time your organization is created - you don’t request or configure it separately. Once it exists, Repositories (/gravity/git) lists every repository in the active organization, with the repository count, a search box, and a Public/Private filter.

If your organization was created a long time ago and this page shows no namespace at all, repositories can’t be created yet - contact support rather than waiting.

New repository opens a dialog with:

  • Name - letters, numbers, hyphens, underscores, and periods only.
  • Description (optional).
  • Private - on by default. A private repository is only reachable by members of your organization.
  • Initialize with README - adds a first commit so you can clone the repository immediately instead of pushing an empty one yourself.

Open a repository (/gravity/git/repo/[org]/[repo]) to reach its Overview tab, which shows both clone URLs side by side:

  • HTTPS - git clone <url>, with a one-click copy button.
  • SSH - the git@... form, also copyable.

An Open in editor section offers a one-click “VS Code (clone)” link (uses your operating system’s vscode:// handler to open the desktop app) and a “Copy git clone” button that puts the full git clone <https-url> command on your clipboard.

The same page’s Files tab lets you browse the repository tree and view individual files (binary files show a placeholder rather than garbled content) directly from the branch selector at the top of the page - useful for a quick look without cloning.

Access to a repository follows your organization membership: any member of the organization that owns a repository can browse, clone, and manage it. Sencai doesn’t currently offer a finer-grained, per-repository permission model - if you need to restrict a repository to a subset of your team, keep that team as a separate organization.

The Settings tab on a repository’s detail page has four sections:

  • General - name, description, website URL, private/public toggle, and whether Issues are enabled. Renaming a repository here also updates its URL.
  • Deploy Keys - add a public SSH key (with a title and a read-only toggle) to grant a single machine or CI job access to this one repository, without using a personal account’s credentials.
  • Webhooks - send an HTTP payload to an external URL on push, pull request, issues, release, or every event, with an optional secret for HMAC signing.
  • Secrets & Variables - values available to this repository’s CI pipelines: secrets are write-only once saved (you can replace but not read them back), variables are plain key/value pairs you can see and edit.

Deleting a repository is in the same tab’s danger zone - you must type the repository’s name to confirm, and it can’t be undone.

Mirrors (/gravity/git/mirrors) pulls an external repository (for example, from GitHub or GitLab) into your organization’s Git namespace on a schedule, so the rest of the platform - CI, packages, browsing - can treat it like any other repository.

Add mirror asks for:

  • Remote URL - the source repository’s clone URL.
  • Repository name - what to call it once mirrored in.
  • Access token (optional) - required for private source repositories.
  • Sync interval - every 8 hours, daily, every 3 days, or weekly.

A mirror is read-only - Sencai only pulls, it never pushes back to the source. If the source repository requires authentication and the token expires or is revoked, the mirror’s sync starts failing; update the token from the mirror’s row (or the repository’s own Settings → General, which shows the same “Mirror credentials” panel for mirrored repositories) to fix it, which also re-triggers a sync immediately.

Mirrors don’t trigger CI runs on sync - see CI & pipelines for why.

Sencai provisions and operates the Git hosting itself (storage, the Git service, backups) - you don’t manage any of that. What’s yours to manage: repository content, branch layout, who’s a member of the owning organization, webhooks, deploy keys, and CI/Actions secrets and variables.

  • CI & pipelines - running workflows against the repositories you create here
  • Container registry - where packages published from your repositories show up
  • Roles - how organization membership is structured
  • Audit log - every repository create/update/delete is recorded there