Governance Policy
Last updated on May 23, 2026
Authelia is free from any outside parties directly influencing its decision and architecture process and is entirely governed as outlined on this page.
To date no party that has contributed financially or otherwise to the project has been directly involved in the design or implementation of the project or has attempted to influence the project in any way that we’re aware of. Our promise is that if this changes we will publish the name of the party and the details of attempt transparently on this page.
Our affiliations with external companies will be transparently communicated on this page and the sponsors section.
This policy outlines how the Authelia project is governed and the various processes that are in place to ensure that the project is run in a safe and sustainable manner.
Roles and Responsibilities
The following describes the roles within the Authelia project and their associated responsibilities.
Maintainers
The Maintainer Team are traditional repository maintainers.
Responsibilities
- Review and merge pull requests from external parties
- Respond to bug reports, feature requests, discussions, and support chat rooms
- Ensuring contributions meet the project guidelines
- Maintain code quality and test coverage
- Participate in project discussions and decision-making
Members
Core Team
The Core Team are effectively members of the Maintainers Team with extra responsibilities.
Responsibilities
- All responsibilities of the Maintainers Team
- Strategic direction and long-term planning for the project
- Review and merge pull requests from all other teams
- Reviewing and approving escalated permissions for contributors
- Handle vulnerability and security related bug reports
- Handle project governance unanimously
- Maintain the project roadmap
- Release and versioning management
- Coordinate collaboration
- Maintain the continuous integration and delivery pipelines and related mechanisms
Members
Sensitive Resource Access
The following table summarizes which sensitive resources each role has access to. For the list of current members in each role see the Maintainers and Core Team sections above.
The table only describes the default sensitive resources the role has access to, while there is no divergence at this stage there may be in the future.
| Sensitive Resource | Maintainers | Core Team |
|---|---|---|
| Repository write access (commit and merge) | Y | Y |
| CI/CD pipeline unblock/approval | Y | Y |
| CI/CD pipeline secrets | Y | |
| CI/CD pipeline configuration | Y | |
| Package registry publishing credentials | Y | |
| Infrastructure access | Y | |
| Organization-level administrative access | Y |
Access Control Enforcement
The following technical controls are enforced at the platform level to protect the project’s version control system and sensitive resources.
Multi-Factor Authentication
The GitHub organization requires multi-factor authentication (MFA) for all members. Any user who attempts to access sensitive resources in the version control system must have completed MFA enrollment. Members who disable or fail to configure MFA are automatically removed from the organization by GitHub.
Members are also not permitted to have less secure multi-factor authentication (MFA) methods such as SMS. See the GitHub documentation for more details.
Primary Branch Protection
The project’s primary branch (master) is protected by a
GitHub repository ruleset. This ruleset enforces the following:
- Direct commits to the primary branch are blocked. All changes must be submitted via a pull request and pass the required review process.
- Deletion of the primary branch is prevented. Any attempt to delete the primary branch is rejected by the ruleset.
Public Discussion and Communication
The project maintains several mechanisms for public discussion about proposed changes, usage obstacles, and general community interaction:
- GitHub Issues: for bug reports and feature requests.
- GitHub Discussions: for ideas, questions, support requests, and sharing configuration or setups.
- Matrix and Discord: real-time community chat with dedicated rooms for support, contributing/development, and off-topic discussion.
For full details see the contact page.
Contributing
The project welcomes contributions from anyone. The contribution process and requirements for acceptable contributions are documented in the contributing section. In summary:
- Contributors should discuss their intended changes in advance to ensure it aligns with the governed direction via GitHub Issues, GitHub Discussions, or chat.
- Fork the repository and create a pull request following the pull request guidelines.
- All contributions must adhere to the project guidelines, which include requirements for commit messages, code style, testing, and documentation.
- All status checks must pass and test coverage must not regress.
- At least one maintainer must review and approve the pull request before it is merged.
- Pull requests are squash-merged by maintainers.
Contributor Access and Escalated Permissions
Contributors are reviewed prior to being granted escalated permissions to sensitive resources either directly or via the Roles and Responsibilities. Access to sensitive resources are reviewed on a case-by-case basis, and each contributor granted access to one sensitive resource is re-reviewed should they need or want access to any additional sensitive resource. Sensitive resources include but are not limited to:
- Repository write access (commit and merge permissions)
- CI/CD pipeline:
- Secrets
- Configuration
- Unblock/Approval Permission
- Package registry publishing credentials
- Infrastructure access
- Organization-level administrative permissions
Review Requirements
Before a contributor may be granted escalated permissions to any sensitive resource, the following requirements must be satisfied:
- The contributor must have a minimum of six months of active, consistent contributions to the project.
- At least one existing member of the core team who holds the relevant access level must review and approve the escalation in discussion with one other member of the core team.
- The review must evaluate:
- The quality and consistency of the contributor’s contribution history.
- Adherence to project coding standards, guidelines, and review processes.
- Alignment with the goals and direction of the project.
- Demonstrated security awareness, including no history of introducing known vulnerabilities and an understanding of responsible disclosure practices.
Default Permissions
The GitHub organization base permission is set to read-only. When a new collaborator is added to the organization they receive no write access by default. All escalated permissions including repository write access are granted exclusively through manual team assignment by a core team member after the review requirements have been satisfied.
Granting Process
Escalated permissions are granted only after the review requirements above are met. The core team member approving the escalation is responsible for ensuring the review has been conducted thoroughly. Permissions are scoped to the minimum level necessary for the contributor’s role and responsibilities.
Revocation
Escalated permissions may be revoked at any time by the core team if a contributor is found to have violated project policies, acted in bad faith, or is no longer actively contributing to the project.