> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Gitea

> Connect your self-hosted Gitea server to Oleria to discover its users, bots, organizations, teams, roles, repositories and who can reach them, non-human identities, and repository activity.

Connect Gitea to Oleria to see who can reach your self-hosted Gitea server and its repositories: users and bots, organizations and teams, site administrators and organization owners, every path that grants access to a repository, and the keys, tokens, runners, webhooks, and secrets that act as non-human identities (NHIs). Oleria connects with an access token of a Gitea site administrator, and can also suspend users, change team, organization, and role membership, remove direct repository collaborators and external accounts, create teams, and disable or delete NHIs.

> [!NOTE]
>
> This integration supports Gitea 1.24 or later. Forgejo and Codeberg aren't supported: Oleria detects Forgejo from the version the server reports and refuses the connection. Each integration connects one Gitea server. If you have more than one, add an integration for each. See [Multi-instance support](/integrations/overview.md#multi-instance-support).

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Gitea server:

* **Accounts** - every user on the server, with username, full name, email, creation date, and last sign-in. Oleria also shows:
  * **Status** - a user is enabled when they're active and not prohibited from signing in. Gitea refuses a suspended or inactive user's sign-ins, tokens, and git access.
  * **Account role** - **Site administrator**, **User**, **Restricted user**, or **Bot**. Site administrators are marked as administrators.
  * **MFA** - on Gitea 1.26 or later, users enrolled in TOTP two-factor authentication show MFA as required, and other local users as not required. See [Known limitations](#known-limitations).
  * **Single sign-on (SSO)** - users who sign in through an authentication source configured in Gitea, such as LDAP or OAuth2, show SSO as required, with their login name. Local users show SSO as not configured.
  * An **Anonymous (not signed in)** account, which Oleria adds to stand for visitors who aren't signed in.
* **Groups** - every organization, and every team in each organization, with the team's organization, permission, and per-unit permissions. Each organization's **Owners** team is marked as built in. Oleria also adds two groups, **All signed-in users** and **All signed-in non-restricted users**, to show who gets access from a repository's visibility. The members of an organization's **Owners** team are shown as the people who manage the organization and each of its teams.
* **Roles**:
  * **Site administrator** - held by every site administrator, with owner access to every repository and organization.
  * **Owner of** *organization* - one per organization, held by the members of its **Owners** team, and by any team with owner permission.
  * **Team admin access**, **Team write access**, and **Team read access** - held by the teams with that permission. A team with per-unit permissions holds none of these: its unit levels appear on its repository access instead.
* **Memberships** - which users belong to which teams, which teams belong to which organizations, and who holds each role. Gitea has no organization membership outside teams.
* **Resources** - every repository on the server, with its visibility, owner, and whether it's archived, a mirror, a fork, a template, or empty. Each organization also appears as a resource that contains its repositories. A repository's owner, or its organization's owners, are shown as the people who manage it.
* **Repository access** - one access entry for each way someone can reach a repository, with the level it grants:

  | Access path | Who | Level |
  | :- | :- | :- |
  | Owner | The user who owns a repository in their own namespace | Owner |
  | Organization owners | The organization's **Owners** team, on every repository of the organization | Owner |
  | Team | Each team that holds the repository, including teams with access to all the organization's repositories | The team's permission (read, write, or admin). For a team with per-unit permissions, its level on each unit enabled on the repository, such as code, issues, or pull requests. |
  | Direct collaborator | Each user or bot added as a collaborator on the repository | The collaborator's own level (see below) |
  | Visibility | **Anonymous (not signed in)** and **All signed-in users** for public repositories, or **All signed-in non-restricted users** when the server requires sign-in to view. **All signed-in non-restricted users** for repositories of a limited-visibility owner. The organization's own group for public repositories of a private organization. | Read |
  | Site administrator | The **Site administrator** role, on every repository | Owner |
  | Deploy key or token | Each deploy key or deploy token on the repository | Write, or read for a read-only key |

  Gitea's API doesn't return a direct collaborator's own level, only their effective level. When a team or site administrator grant hides it, Oleria shows the collaborator at read, as a lower bound, and the team or role entry shows the real access. To find out whether the server requires sign-in to view, Oleria makes one request to the server without credentials.
* **Non-human identities (NHIs):**

  | Identity | Shown as |
  | :- | :- |
  | Bots | Service account. Gitea has bot users from Gitea 28. |
  | SSH keys | SSH key, with its owner, title, key type, fingerprint, creation date, last use, and whether it's read-only. |
  | Access tokens | Personal access token (PAT), with its owner, scopes, creation date, and last use. Needs the optional **Admin username** and **Admin password** (see [Optional settings](#optional-settings)). |
  | OAuth2 applications | Application, with its owner, client ID, redirect origins, and creation date. A confidential client also shows its client secret as a credential. By default, only the OAuth2 applications of the connection's own user appear. See [Optional settings](#optional-settings). |
  | Actions runners | System identity, with its labels, status, and whether it's ephemeral or disabled. A runner registered to one organization shows that organization as its owner. |
  | Webhooks | Application, for system and default webhooks, organization webhooks, and repository webhooks, with its events, branch filter, and target. Oleria keeps only the target's scheme, host, and port. |
  | Deploy keys and deploy tokens | SSH key or API token, scoped to its repository, with read or write access. Gitea has deploy tokens from Gitea 28. |
  | Actions secrets | Secret, for organization and repository Actions secrets, by name only. Oleria never reads secret values. |

  SSH keys and access tokens of a user who is suspended or inactive show as disabled, because Gitea refuses them. Each SSH key, access token, deploy key or token, and secret also appears as a credential, and so does a confidential OAuth2 application's client secret. A user's SSH keys, access tokens, and OAuth2 applications show that user as their owner.
* **Activity** - repository events from each user's activity feed, attributed to the user who performed them and linked to the repository: pushes, tags, branch deletions, mirror syncs, issues and comments, pull requests opened, closed, reopened, merged, and reviewed, releases, repositories created, renamed, and transferred, and stars and watches. Every event keeps its Gitea event name. Oleria doesn't store commit messages or comment text.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model).

> [!NOTE]
>
> Gitea has no AI agent objects, so none appear. Actions runners and bots are shown as NHIs.

## Prerequisites

* A Gitea server running Gitea 1.24 or later, reachable from the internet over HTTPS on port `443`, by a host name that resolves to a public IP address. IP addresses, other ports, and on-premises agents aren't supported.
* The server's host on Oleria's egress allowlist. Before you connect, contact [support@oleria.com](mailto:support@oleria.com) with the server's host name, such as `gitea.example.com`, and ask for it to be allowlisted.
* A Gitea site administrator, to create a dedicated administrator account for Oleria and its access token. Oleria needs a site administrator's token to read every user, organization, and repository. Shared hosted services where you aren't a site administrator, such as gitea.com and Codeberg, can't be connected.
* Optional: the server's TLS certificate, or the CA certificate that issued it, in PEM format, if the server doesn't use a publicly trusted certificate. Oleria always verifies the server's certificate.
* Admin access on the Oleria platform to add a new integration.

> [!WARNING]
>
> A site administrator's token with write scopes can change anything on the server. Oleria uses the same token for discovery and [remediation actions](#remediation-actions), so give Oleria its own administrator account, grant only the scopes you need, and store the token securely.

## Create the Oleria account and access token in Gitea

**1. Create a dedicated administrator account**

In Gitea, go to **Site Administration** and create a local user for Oleria, such as `oleria-governance`. Then edit the user and make it a site administrator. Using a dedicated account means Oleria's access doesn't depend on a person's account, and Oleria can refuse actions against it.

**2. Generate an access token**

Sign in as the new account and go to **Settings** > **Applications**. Under the access token section, enter a token name, such as `Oleria`, and set the repository and organization access to all repositories, not public only. Then select these permissions and select **Generate Token**:

| Use | Token scopes |
| :- | :- |
| Discovery (required) | `read:admin`, `read:organization`, `read:user`, `read:repository` |
| [Remediation actions](#remediation-actions) (optional) | Also `write:admin`, `write:organization`, and `write:repository`. Add `write:user` to revoke access tokens. |

In Gitea, a write scope includes the matching read scope. Copy the token. Gitea shows it only once.

> [!WARNING]
>
> Don't create the token with public-only access. A public-only token hides private users, organizations, and repositories, and Oleria refuses it.

**3. Get the server allowlisted**

If you haven't already, send the server's host name to [support@oleria.com](mailto:support@oleria.com) and wait for confirmation that it's on Oleria's egress allowlist. If the server uses a self-signed or private certificate, export the server's certificate or its issuing CA certificate in PEM format.

### Optional settings

* **Access token inventory and revocation.** Gitea lists and deletes other users' access tokens only for a request signed in with a username and password. It refuses an access token for this, even a site administrator's. To discover access tokens, and to revoke them with **Disable NHI accounts**, enter the username and password of a site administrator in **Admin username** and **Admin password**. That administrator must not use two-factor authentication, and Basic authentication (`ENABLE_BASIC_AUTHENTICATION`) must be enabled on the server. Oleria uses the password only to list and revoke access tokens, and uses the access token for everything else. Without it, access tokens don't appear, and Oleria can't revoke them.
* **OAuth2 applications of every user.** Gitea lists a user's OAuth2 applications only to that user. To discover the OAuth2 applications of every enabled user, select **Inventory OAuth2 apps of all users (Sudo)**. Oleria then reads each user's applications by acting as that user with Gitea's `Sudo` header, one request per user on every sync. On Gitea 28 with audit logging turned on, each request writes an impersonation event to Gitea's audit log. Without it, only the connection's own user's OAuth2 applications appear.

> [!WARNING]
>
> A site administrator password without two-factor authentication is a sensitive credential. Use it only if you need access token inventory or revocation, give it to a dedicated account, and store it securely.

## Connect Gitea to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations** -> select **Gitea**.

**2. Complete the connection form**

Provide the following:

| Field | Notes |
| :- | :- |
| **Gitea URL** | Required. Your server's address, its `ROOT_URL`, for example `https://gitea.example.com`. Include any sub-path, if Gitea is served under one. It must use `https`, a host name rather than an IP address, and port `443`, with no query or fragment. If you paste an address ending in `/api/v1`, Oleria removes it. You can't change this field later. |
| **Access token** | Required. The token you generated for the dedicated administrator account. |
| **Trusted certificate (PEM)** | Optional. One PEM-encoded certificate, from `-----BEGIN CERTIFICATE-----` to `-----END CERTIFICATE-----`, for a server without a publicly trusted certificate. Paste either the server's own certificate, which Oleria then trusts exactly, or the CA certificate that issued it, which Oleria checks the server's certificate and host name against. Oleria trusts it for this integration only. |
| **Admin username** | Optional. A site administrator without two-factor authentication, to discover and revoke access tokens. See [Optional settings](#optional-settings). |
| **Admin password** | Required with **Admin username**. That administrator's password. |
| **Inventory OAuth2 apps of all users (Sudo)** | Optional, off by default. Discovers every enabled user's OAuth2 applications. See [Optional settings](#optional-settings). |

**3. Authenticate**

Select **Authenticate**. Before it saves anything, Oleria:

* reads the server's version, and refuses Forgejo and Gitea versions before 1.24;
* checks that the token's user is a site administrator;
* reads the server's users, organizations, and repositories;
* with **Admin username** and **Admin password**, reads that administrator's access tokens, signed in with the password;
* on Gitea 1.27 or later, reads the token's scopes, and refuses a public-only token or one missing a read scope.

Find the newly connected server on the **Connected** tab of your Oleria **Integrations** page, named **Gitea (*host*)**.

If **Authenticate** fails, the message says what's wrong:

* **Gitea rejected the access token (HTTP 401)** - check the token, and that its user isn't suspended.
* **The token's user ... must be a Gitea site administrator** - make the token's user a site administrator, or generate the token as a site administrator.
* **Gitea denied the request (HTTP 403)** - the message gives Gitea's reason. Usually the token lacks a scope Oleria needs, so generate a token with `read:admin`, `read:organization`, `read:user`, and `read:repository`. Gitea also returns this when the token's user is prohibited from signing in.
* **Gitea refused the token's user (HTTP 403)** - Gitea refused the request for another reason, given in the message.
* **The access token has the public-only scope** - generate a token with access to all repositories, not public only.
* **The access token lacks** *scopes* - generate a token with `read:admin`, `read:organization`, `read:user`, and `read:repository`.
* **Gitea refused the admin username and password** - check the username and password. Basic authentication may be disabled on the server, or the administrator may use two-factor authentication.
* **Forgejo is not supported by the Gitea connector yet** - the server runs Forgejo. Forgejo isn't supported.
* **Gitea ... is not supported; the connector needs Gitea 1.24 or later** - upgrade the server, then try again.
* **Gitea API not found (HTTP 404)** - check that **Gitea URL** is the server's `ROOT_URL`, including any sub-path.
* **The Gitea server's TLS certificate is not trusted** - paste the server's certificate or its issuing CA certificate into **Trusted certificate (PEM)**, or install a publicly trusted certificate on the server.
* **Gitea server ... is not reachable from Oleria** - check that the server is reachable over public HTTPS on port `443` by host name, and that Oleria support has added its host to the egress allowlist. This message also appears when the server's certificate has expired.
* **Gitea URL should be https\://... on port 443** on the form, or **Hostname resolves to private or loopback IP** - enter the server's `https` address by host name, on port `443`. The host name must resolve to a public IP address.
* **trustedCertificatePem must be one PEM-encoded CERTIFICATE block**, **must hold exactly one certificate**, or **is not a valid certificate** - paste exactly one certificate, with nothing else, such as a private key or a second certificate.

**Authenticate** needs all four read scopes, because it reads users, organizations, and repositories. Before Gitea 1.27, Gitea can't report a token's scopes, so Oleria finds out only from those reads: check the scopes when you generate the token.

### Edit the integration

When you edit the integration, you can change **Access token**, **Trusted certificate (PEM)**, **Admin username**, **Admin password**, and **Inventory OAuth2 apps of all users (Sudo)**. **Gitea URL** can't be changed. To connect a different server, add a new integration.

* Leave **Access token** or **Admin password** blank to keep the stored value.
* Clear **Admin username** to stop discovering and revoking access tokens. Clear **Trusted certificate (PEM)** to remove the stored certificate.

Select **Update** to save. Oleria runs the same checks as **Authenticate**.

If the password in **Admin password** later stops working, for example because it was changed or the administrator turned on two-factor authentication, the integration stays healthy: Oleria logs a warning, and access tokens stop appearing and can't be revoked until you update the password.

## Verify the integration

Confirm the server appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered accounts, organizations, teams, roles, repositories and their access, NHIs, and activity in your Oleria workspace.

In the integration's **Capabilities and operation readiness** section, **Read users**, **Read groups**, and **Read roles** show **Available**. If one shows **Needs permission**, check that the token's user is still a site administrator, and that the token has `read:admin` and, for groups and roles, `read:organization`.

If Gitea refuses one kind of data, such as SSH keys, OAuth2 applications, runners, webhooks, or organization secrets, Oleria skips it and syncs everything else. If Gitea returns errors for a few repositories or users, for example because the server is overloaded, Oleria skips them and syncs the rest. If more than 5% of repositories (while reading collaborators, deploy keys, webhooks, or secrets), users (while reading SSH keys, access tokens, or OAuth2 applications), or user-days of activity are skipped, that part of the sync fails, so incomplete data is never reported as complete.

## Remediation actions

Oleria can take these actions in Gitea. Each needs the token's user to be a site administrator, and the token to hold these scopes:

| Action | Token scopes |
| :- | :- |
| Disable user accounts, Enable user accounts | `read:user`, `read:admin`, `write:admin` |
| Add user to group, Remove user from group, Create group | `read:user`, `read:admin`, `read:organization`, `write:organization` |
| Add user to role, Remove user from role | `read:user`, `read:admin`, `read:organization`, `write:admin`, `write:organization` |
| Revoke permission to resource instance, Remove access for external accounts | `read:user`, `read:admin`, `read:organization`, `read:repository`, `write:repository` |
| Disable NHI accounts - bot, runner, or SSH key | `read:user`, `read:admin`, `write:admin` |
| Disable NHI accounts - deploy key or deploy token | `read:user`, `read:repository`, `write:repository` |
| Disable NHI accounts - access token | `read:user`, `read:admin`, `write:user`, and the **Admin username** and **Admin password** |

On Gitea 1.27 or later, Oleria checks the token's scopes before an action and names any that are missing. On earlier versions, Gitea refuses the action instead.

| Action | What it does | Revert |
| :- | :- | :- |
| Disable user accounts | Prohibits the user from signing in. Gitea then also refuses the user's access tokens, SSH keys, and git access. | Supported - allows the user to sign in again. |
| Enable user accounts | Allows the user to sign in again. If the user is also inactive, for example because their email isn't confirmed, they still can't sign in, and the action's result says so. | Supported - prohibits sign-in again. |
| Add user to group | Adds the user to a team. | Supported - removes the user from the team. |
| Remove user from group | For a team, removes the user from the team. For an organization, removes the user from the organization, and so from all its teams. Oleria records the teams the user was in. Repositories the user owns, and their direct collaborator grants on the organization's repositories, aren't changed. | Supported - adds the user back to the team, or to each recorded team that still exists. The result lists any teams that no longer exist. |
| Add user to role | For **Site administrator**, makes the user a site administrator. For **Owner of** *organization*, adds the user to the organization's **Owners** team. | Supported - removes the role again. |
| Remove user from role | For **Site administrator**, removes the user's site administrator status. For **Owner of** *organization*, removes the user from the **Owners** team. | Supported - gives the role back. |
| Revoke permission to resource instance | Removes a direct collaborator from a repository. Oleria records the collaborator's level first. | Supported - adds the collaborator back at the recorded level. Watches, and issue and pull request assignments, that the user lost aren't restored. If the repository's owner has blocked the user, Gitea refuses to add them back. |
| Remove access for external accounts | Removes an external account's direct collaborator access to a repository, in the same way as **Revoke permission to resource instance**. An external account is a restricted user, or, on an organization's repository, a user who isn't a member of that organization. | Supported - adds the collaborator back at the recorded level. |
| Create group | Creates a team in an organization. Enter the name as *organization*/*team*. The team gets read access to code, issues, pull requests, releases, wiki, projects, and packages, and no repositories. | Supported - deletes the team, but only while it has no members and no repositories. |
| Disable NHI accounts | Disables or deletes the NHI, depending on its type. See the table below. | Depends on the type. |

**Disable NHI accounts** works as follows:

| NHI | What it does | Revert |
| :- | :- | :- |
| Bot | Prohibits the bot from signing in. For a person, use **Disable user accounts**. | Supported - allows the bot to sign in again. |
| Actions runner | Disables the runner, on Gitea 1.26 or later. Earlier versions can only delete a runner, so Oleria refuses. | Supported - enables the runner again. |
| SSH key | Deletes the key. | Supported - adds the same public key back to the user, with the same title and read-only setting, under a new ID. |
| Deploy key | Deletes the key from the repository. | Supported - adds the same public key back to the repository under a new ID. |
| Deploy token | Deletes the token. | Not supported. A deleted deploy token can't be restored. |
| Access token | Revokes the token. Needs **Admin username** and **Admin password**. | Not supported. A revoked access token can't be restored, so its owner must create a new one. |
| Webhook, OAuth2 application, or Actions secret | Not supported. Gitea's webhook API would rewrite a webhook's events, branch filter, and authorization header, and deleting an OAuth2 application or a secret can't be undone. | - |

> [!NOTE]
>
> The **Remediations** page offers **Revert** only for **Disable user accounts**, **Remove user from group**, and **Disable NHI accounts**. The integration supports the other reverts in these tables, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed.

> [!WARNING]
>
> Revoking an access token or deleting a deploy token can't be undone. Anything that uses it stops working immediately. **Remove user from group** on an organization removes the user from every team in it.

Keep these limits in mind when you use these actions:

* Oleria refuses to suspend, remove from a team or organization, remove a role from, or remove as a collaborator the user this integration connects as, and the user in **Admin username**. It also refuses to revoke the access token this integration uses. If it can't identify its own user or token, it refuses rather than risk cutting off its own access. Deleting their SSH keys is allowed, because SSH keys don't carry Oleria's API access.
* Oleria refuses to remove an organization's last owner, from the **Owners** team or from the organization. Gitea also refuses to remove the last site administrator.
* **Add user to group** and **Remove user from group** refuse the **Owners** team, because it grants organization ownership. Use **Add user to role** or **Remove user from role** with **Owner of** *organization* instead. **Add user to group** also refuses an organization, because Gitea has no organization membership outside teams: add the user to one of its teams.
* **Add user to role** and **Remove user from role** accept only **Site administrator** and **Owner of** *organization*. The team access roles describe what teams grant: add the user to a team instead.
* **Revoke permission to resource instance** works only for a direct collaborator. If the user isn't one, the message names where their access comes from: owning the repository, being a site administrator, a team, or the repository's visibility. If a team or site administrator grant hides the collaborator's own level, Oleria refuses, because it couldn't add them back at the same level. Change it in Gitea.
* **Remove access for external accounts** refuses an account that isn't external: an unrestricted user on a personal repository, or an unrestricted member of the repository's organization. Use **Revoke permission to resource instance** instead. Otherwise it has the same limits as **Revoke permission to resource instance**.
* **Create group** refuses the name **Owners**, and fails without creating anything if a team with the same name, ignoring upper and lower case, already exists in the organization.
* The **All signed-in users**, **All signed-in non-restricted users**, and **Anonymous (not signed in)** entries are added by Oleria, so actions on them are refused.
* If the user, team, membership, or NHI is already in the state the action asks for, Oleria makes no change, and reverting the action makes no change either. A target that no longer exists fails the action, because Oleria can't tell it apart from a wrong ID.
* After each change, Oleria reads the target again. If the read doesn't show the change, the action fails and says the change wasn't confirmed: check the target in Gitea.
* Reverting an action changes only what the action changed. If the target has changed since, or no longer exists, the revert makes no change and says why.

## Known limitations

* **No sign-in, permission-change, or audit events.** Activity comes from users' activity feeds, which record repository events only. Gitea's audit log has no API that accepts a token, so sign-ins, failed sign-ins, membership and permission changes, and token and key changes don't appear as activity. Gitea Enterprise's audit log export isn't used.
* **Last activity is the last interactive sign-in.** Gitea updates a user's last sign-in when they sign in, not when they use an access token, an SSH key, or git. Newer events in their activity feed don't change it.
* **No password change date.** Gitea's API doesn't report when a user last changed their password.
* **MFA is TOTP only.** Gitea's API reports only TOTP enrollment, from Gitea 1.26. A user who uses only WebAuthn security keys shows MFA as not required. Before Gitea 1.26, and for users from an authentication source, MFA shows as unavailable.
* **Authentication sources aren't discovered.** Gitea manages LDAP, OAuth2, and other authentication sources only in its web interface and command line, so Oleria shows only each user's source ID and login name.
* **Access tokens need a password.** Without **Admin username** and **Admin password**, access tokens don't appear and can't be revoked.
* **OAuth2 applications.** Without the Sudo option, only the connection's own user's OAuth2 applications appear. Organization and instance-wide OAuth2 applications have no API, so they never appear.
* **Secrets and variables.** Actions secrets appear by name only. Actions variables don't appear, because Gitea returns their values when they're listed. Runner registration tokens are never requested.
* **Direct collaborator levels.** When a team or site administrator grant hides a direct collaborator's own level, the collaborator shows read access, as a lower bound, and **Revoke permission to resource instance** refuses them.
* **Activity history.** When you connect, Oleria reads up to 30 days of activity, one request per user per day, so the first activity sync of a large server can take a while. Gitea's feeds filter by day in the server's time zone, which Oleria learns from the newest user's creation time. Oleria reads a little more than each day, so a daylight saving change can't hide events.
* **Some actions aren't available.** Oleria can't change a collaborator's level, remove a team's access to a repository, make a repository private, create or delete users, or end a user's sessions. Creating and deleting users and making a repository private are left out on purpose. Gitea has no API to end sessions. Disabling a user stops every request they make.
* **Actions job tokens aren't shown.** Gitea creates one for each workflow job, and it's valid only while the job runs.
* **Version-dependent data.** MFA and disabling runners need Gitea 1.26 or later. Checking the token's scopes needs Gitea 1.27 or later. Bots and deploy tokens exist from Gitea 28.
* **Network access.** Oleria connects only over public HTTPS on port `443`, to a server host that Oleria support has added to the egress allowlist. Each server's host is allowlisted separately, and there's no on-premises agent option. Oleria paces its requests to each server, so the first sync of a server with many repositories can take a while.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.