Skip to content
CodeQuay

Platform

Everything you need to host code that matters

The git hosting your team already knows, with rules the server always enforces. Here is what the platform offers.

Example of the CodeQuay console: the acme/portal/api repository with the maintainer role, the HTTPS clone URL, the protected main branch, the file list and the README.

Every day

The git you know, with no surprises

Nothing changes for developers: clone, branch, push and tag just like today. The server is what makes the difference.

  • File browser

    Syntax highlighting and README preview.

  • History and blame

    Paginated history, line-by-line blame, branch comparison.

  • Compare

    Diffs between branches, tags and commits, even on long histories.

  • Search

    Across the repositories you can access, and only those.

  • Organizations and projects

    Inherited roles and per-user restrictions.

  • HTTPS and SSH

    Clone and push over the protocol your team already uses.

Server-side protections

Rules nobody can bypass, not even owners and admins

Protections are checked by the server before any push is accepted. They don't depend on hooks installed on developers' machines, and no role can override them.

  • Branches protected by pattern

    main, release/*, develop: for each pattern, choose the minimum role allowed to push. Force-pushes and deletions are blocked.

  • Immutable release tags

    A tag like v2.4.0 is created once and can never be moved or deleted: the same version number always points to the same code.

  • Rejections explained in your language

    Anyone attempting a blocked operation sees, right in their terminal, which rule stopped them and what to do next, in English or Italian according to their preference.

  • Per-user restrictions

    Limit a single user's role on a repository, for example read-only access for a contractor.

Example of the CodeQuay console: protections for the main, release/* and develop branches, with no force-push and no deletion; push policy with immutable v* tags, a 50 MB file size limit and secret blocking turned on.
git push --force origin v2.4.0
Example: moving the v2.4.0 tag is rejected because the tag is immutable; the server suggests publishing a new version instead.
~/projects/api $ git push --force origin v2.4.0remote:remote: CodeQuay: push REJECTEDremote:   - refs/tags/v2.4.0: tag 'v2.4.0' is immutableremote:     (pattern v*) and cannot be moved; to ship aremote:     fix, publish a new versionremote: ! [remote rejected] v2.4.0 -> v2.4.0 (pre-receive hook declined)

Secrets and push policies

Credentials are stopped before they enter your history

Once a key committed by mistake lands in the history, it has to be treated as compromised. CodeQuay scans the new files in every push and rejects those containing recognizable credentials.

Detected credentials

  • PEM private keys (RSA, EC, DSA, OpenSSH, PGP)
  • AWS access keys
  • Google API keys
  • Stripe live keys
  • GitHub tokens, including fine-grained
  • Slack tokens
  • CodeQuay personal tokens

Company content rules

  • Commit message format enforced with a regular expression, for example feat|fix|docs: ….
  • Maximum file size: heavy binaries stay out of the repository.
  • The audit log records the rule that was violated, never the secret itself.
git push origin feature/payments
Example: a push containing an AWS access key in config/prod.env is rejected; the server points to the file and line, shows only the beginning of the key and asks you to remove it from the history and revoke it.
~/projects/api $ git push origin feature/paymentsWriting objects: 100% (7/7), 2.31 KiB | 2.31 MiB/s, done.remote:remote: CodeQuay: push REJECTEDremote:   - possible secret in 'config/prod.env' line 12:remote:     AWS access key (AKIA7Q2M…(20 characters));remote:     remove it from the history (a later commit isremote:     not enough) and revoke the credentialremote: ! [remote rejected] feature/payments -> feature/payments   (pre-receive hook declined)

Modern access

Strong identities, for people and for scripts

Users sign in the way they prefer; scripts use credentials limited in time and scope.

Passkeys
Sign in with your fingerprint, face or device PIN, with no password to remember.
Authenticator apps
Two-factor authentication set up with a QR code, with recovery codes.
Single sign-on
Google, Apple, Microsoft 365 and OIDC-compatible company identity providers.
Tokens with mandatory expiry
Separate scopes for API and git, one-year maximum lifetime, instant revocation.
HTTPS and SSH
Clone and push over the protocol your team already uses, under the same rules.
Brute-force protection
Rate limits and temporary lockout after repeated failed sign-ins.
New device verification
Signing in with just a password from a device never used before requires a code sent by email.
Security emails
Alerts for sign-ins from unrecognized devices, passkey and 2FA changes, password or email changes, new tokens and SSH keys.
Example of the CodeQuay console, account security settings: two registered passkeys, two-factor authentication setup with the QR code to scan with an authenticator app, and linked Google and Microsoft 365 accounts.
Example of the CodeQuay console: personal tokens with limited scopes and mandatory expiry, shown as active, expiring soon or expired; sign-in with two-factor authentication and company providers.

Teams and collaboration

The right people, on the right code

Separate spaces for personal and company work, invitations that expire, and access limited to a single repository when that's what you need.

  • Personal and company spaces

    Every account has a personal space for tests and experiments, visible only to you and the people you invite. Work code lives in company organizations, under the administrators' control.

  • Invite by email or username

    Owners and maintainers invite a colleague with a role never higher than their own. Invitations last 7 days and can be resent or revoked.

  • Collaborators on a single repository

    A contractor can work on one repository without seeing the project's other repositories.

  • Sign-up under control

    Administrators decide whether sign-up is open, limited to company domains or closed. An invitation is always enough to join.

  • In English and Italian

    Console, emails and git messages in the language each user chooses.

  • Per-repository mirror to GitHub

    Maintainers turn on automatic replication of every push to GitHub from the repository settings.

Performance

Fast, even with a long history

Code browsing, history, blame and diffs stay smooth even on very large repositories. Git indexes are maintained every night, with no action needed on your side.

< 2 s

p95 for history, diff and blame

100k

commits in the test repository used for the benchmark

Example of the CodeQuay console: a commit diff, with added and removed lines highlighted.

CodeQuay Actions

Built-in CI/CD, with GitHub Actions syntax

Workflows in .github/workflows run on CodeQuay runners, right next to the code and under the same rules. The syntax is the one your team already knows: usually only the registry, secrets and runner labels change.

Triggers
Pushes to branches and tags with path filters, manual runs with inputs, scheduled runs and reusable workflows.
Encrypted secrets and variables
Per organization, project, repository and environment. Never returned by the API, masked in the logs.
Environments with approvals
A production deployment starts only after approval, and only from allowed branches or tags.
Artifacts and cache
upload-artifact and cache work as on GitHub; artifacts can be downloaded from the console.
Actions from an internal mirror
Public actions are served from a mirror on CodeQuay: runs don't depend on github.com.
Containers or the runner host
Jobs run in Docker containers or directly on the runner host, for deployments with ssh, helm or kubectl.

Execution is built on act (nektos/act), which is open source. In the console: per-step logs, re-running failed jobs, cancelling, approving deployments.

.github/workflows/release.yml
Example workflow: on every v* tag, a job runs on the self-hosted runner in the production environment with approval, checks out the code and runs the deploy script with the tag name.
on:  push:    tags: ["v*"]jobs:  deploy:    runs-on: [self-hosted, linux]    environment: production    steps:      - uses: actions/checkout@v4      - run: ./deploy.sh ${{ github.ref_name }}

Migration

From GitHub to CodeQuay, without stopping your CI

The import brings over branches and tags and scans the entire history for secrets. The mirror then replicates every push to GitHub, where your GitHub Actions CI can keep running. The format stays standard git: no lock-in. Or move your workflows to CodeQuay Actions, with the same syntax.

How migration works
Example of the CodeQuay console, a repository mirror to GitHub: in sync, last successful sync 40 seconds ago, with the toggle on and a Sync now button.

Why CodeQuay

More of what sets CodeQuay apart

All strengths

Want to see the protections at work on your own repositories?

Create your account and start free. For a dedicated instance or a custom contract, contact us: the people who build CodeQuay will get back to you.

Start free Contact us