Services and Tools

Note: If you cannot access one or more ASF repositories or services, your IP address may have been blocked. Before contacting Infra, review Abuse and Connectivity Issues at the ASF (ABC). The page lists the common overuse (or abuse) issues that affect our site's work and cause an automatic IP address block, and recommends steps to get such a block removed. ABC also provides a channel to contact Infra if you need more information than the page provides.

Infra maintains a wide range of tools for PMCs, project committers, and the Apache Board and its committees to use. Parts of our toolkit are only available to people who have specific duties or roles. Others, like the monitoring tools that show the status of various parts of the Apache infrastructure, are available to everyone.

Services for Top-Level Projects (TLPs)

Websites

Email

ASF self-service platform

One of Infra's goals is to empower ASF members, PMCs, and committers to do much of what they need to do without having to request help from Infra. The Self-Service Platform, for example, provides a number of handy tools that people who have an Apache email address (basically, project committers, PMC members, and ASF Members) can use to:

  • Create a Jira or Confluence project, Git repository, or email list (PMC Chairs and Infra members).
  • Edit your ASF identity or update your ASF password. If you are updating your password, you need access to the email account associated with your Apache account. A reset key is only valid for 15 minutes, so be sure to use it as soon as it arrives.
  • Synchronize Git repositories.
  • Use the OTP Calculator to generate one-time passwords for the OTP or S/Key one-time-password systems (generally, PMC members).
  • Archive a Confluence Wiki space and make it read-only.

People who are not part of the ASF community but wish to file a Jira ticket about an ASF project's product can use the platform to request a Jira account.

ASF account management

ASF account management provides guidance if you want to update your account details, or have lost access to your account.

Getting notices of infrastructure events

You can subscribe to notices of infrastructure events that you want to know about, ranging from Subversion commits to emails to specific lists. Learn more here.

LDAP-enabled services

Infra supports many ASF LDAP-enabled services. You can log in to them with your LDAP credentials.

Services for incubating projects (podlings)

Infra supports incubating projects, or podlings.

Tools for ASF projects

Infra supports an array of tools and services to help projects develop and support both their applications and their community, including:

  • Every project can use a dedicated space on the Confluence wiki.
  • Reporter provides activity statistics and other information about your project, and editing tools to help you write and submit your project's quarterly Board reports.
  • You can create and run a project blog.
  • You can establish a Slack channel for real-time team discussions. Once you have your Slack channel, Infra can set up a Slack-Jira bridge so that you get notices in your channel of new or updated Jira tickets. Open a Jira ticket for INFRA to get this feature for your TLP's Slack channel.
  • Teams can conduct and record meetings through Internet Relay Chat (IRC) using ASFBot. However, you must conduct formal votes on decisions in the appropriate project email list, following the Apache voting process.
  • Localization tools.
  • The Apache Release Audit Tool (RAT) can help you confirm that your proposed product release complies with all ASF requirements.
  • The ASF OAuth system provides a focal point for services wishing to make use of authentication without security implications around storing sensitive user data. Many Apache services use it to validate that the user requesting access is a committer within the project and has lawful access to the systems in question. Read more about Apache OAuth.

Version control

Apache provides, and Infra maintains, code repositories that Apache projects can use to keep their project code safe, accessible to team members, and under version control.

Issue tracking and feature requests

The ASF supports these options for tracking issues and feature requests:

For historical reasons, some projects use Bugzilla. We continue to support Bugzilla, but will not set it up for projects that do not already use it.

Apache Allura is another issue-tracking option. If you feel it may meet your project's needs, consult directly with the Allura project through their users@allura.apache.org email list.

See issues.apache.org for a list of what each project uses.

Here is how to request a bug and issue tracker for your project.

Here are some guidelines for writing a good bug report.

Integrating your repository with Jira tickets

Infra can activate a Subversion and Git integration with Jira tickets for your project.

Source repository publisher/subscriber services

Build services

Apache supports and models continuous integration and continuous deployment, or CI/CD. The ASF build and supported services page provides information about, and links to, the CI services the ASF provides and/or supports.

Other tools to consider:

GitHub Actions

GitHub Actions (GHA) runners are a shared resource: every ASF project draws on the same pool of GitHub-hosted runners. Queue time is therefore a community concern rather than a per-project one. See GitHub Actions secrets for credential handling.

GitHub Actions Policy

The GitHub Actions Policy sets out the rules every ASF workflow must follow, including job concurrency limits, weekly and five-day runner-minute budgets, pinning external actions to a specific git hash, avoiding the pull_request_target trigger where credentials are exposed, and the dependency management described below. Projects whose builds consistently cross the maximum use limits can lose access to GitHub Actions until they fix their build configurations.

Dependabot and dependency management

Dependabot automatically keeps your project's dependencies up to date and free of known vulnerabilities. It is required for the github-actions ecosystem (see the GitHub Actions Policy), and recommended for all other ecosystems your project uses.

Why queues build up

Sometimes GitHub CI queues many workflows, leading to long wait times (with AI-generated contributions likely contributing significantly). In other cases, build misconfigurations or local spikes from cherry-picked or re-run jobs create noisy-neighbour issues for other projects.

Dependency updates are a growing share of that load. Every project repository is now scanned by GitHub's Dependabot alerts and by the scanners that downstream users and their employers run against ASF project releases, so we now see many more security updates than we used to. Projects rush to fix what the scanners report as quickly as they can.

That response has a cost: by default, a groups block applies only to version updates, so security updates open one pull request per alert, each with a full CI run behind it. This can add hundreds of builds into the shared GitHub Actions queue.

How your project can help

Here are ways you and your PMC can help mitigate this issue:

  • Optimize PR workflows: Run full test suites periodically on main merges or via scheduled "canary" builds rather than on every PR. Use paths: filters in GitHub Actions YAML, write custom scripts to determine dynamic build matrix outputs, or utilize tools like Apache Yetus or Develocity (develocity.apache.org) for predictive test selection. Contact Infra via a Jira ticket or by email to users@infra for advice on the best approach for your project.
  • Review workflows for anomalies: Check for deprecated labels like macos-13, which cause workers to hang in "waiting for runner" status and artificially inflate queue sizes. Also, review custom parallelism settings that might block valid jobs. The GitHub Actions Policy requires a job concurrency level of 20 or less per workflow, and recommends staying at or below 15.
  • Group your dependency updates: An ungrouped Dependabot configuration opens one pull request and one full CI run per dependency. Combine them with groups, and add applies-to: security-updates so that security fixes are batched as well instead of arriving as a stream of single-dependency PRs. See grouping security updates for the configuration.
  • Pin first-party actions to a major version tag: The GitHub Actions Policy requires a specific git hash only for external actions; actions in the apache/*, github/* and actions/* namespaces may be used without that restriction. Pinning those to a major version tag rather than to a hash lets a patch or minor release arrive without a pull request, which removes a large share of the Dependabot traffic a project sees. External actions still MUST be pinned to a specific git hash.
  • Reuse workflows across repositories: A project with several repositories can keep its shared CI in reusable workflows in one repository and call them from the rest. An action or dependency update is then reviewed and tested once rather than once per repository, which cuts both the number of Dependabot pull requests and the CI runs behind them.
  • Use lightweight runners: For small, short jobs, consider using runs-on: ubuntu-slim. These provide 1 vCPU, 5GB RAM, no Docker engine, and a 15-minute hard limit. They churn much more quickly during peak times, allowing you to bypass the standard ubuntu-latest queue while freeing up capacity for others.
  • Explore self-hosted runners: Speak with the Infra team about setting up project-specific self-hosted runners, particularly if you have targeted donations or cloud credits available.

Product naming

See guidance for choosing a product name

Code signing

Code quality

SonarCloud is a code quality and security tool that is free to open-source projects. It permits continuous inspection of code quality so your project can perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities in 20+ programming languages.

You can check the status of many Apache project repositories.

Guidance for using SonarCloud with an ASF project is here.

Code distribution

Use the ASF Nexus Repository Manager to browse for and review code distributions by ASF projects.

Distributions

Virtual servers

Infra can provide Ubuntu virtual machines for projects. See:

Use of nightlies.a.o

nightlies, as implied by its name, is designed as a 'short term' storage solution. See the nightlies use policy.

Online voting

Projects can use the Apache STeVe voting system instance (offline when not in use). The tool name refers to the single transferable vote system that is one of its voting options. Open a Jira ticket for Infra to provide assistance in preparing STeVe for your project's use.

Other tools

DNS

Infra manages the ASF DNS, which is registered with Namecheap.

URL shortener

URL shortener

Infra Reporting Dashboard

The ASF Infrastructure Reporting Dashboard contains a collection of reports on the overall health and activity of the infrastructure at the ASF. Some reports are available only for ASF Members and Infra team members.

Machine list

Host Keys and Fingerprints

Copyright 2026, The Apache Software Foundation, Licensed under the Apache License, Version 2.0.
Apache® and the Apache logo are trademarks of The Apache Software Foundation.