Contribute

We value contributions from the Portainer community and encourage developers to propose fixes, improvements, and new ideas.

The following guidelines outline our engineering workflows, please review these before making a contribution to ensure any changes can be integrated smoothly.

Contributing to the Portainer CE codebase

The Portainer CE codebase is available in GitHub. Please follow our build instructions and the following guidelines when making a contribution.

Repository structure

• Our main development occurs in private repositories, which are mirrored to public GitHub repos (e.g. portainer/portainer).

• The develop and release/* branches in public repositories are read-only: merges into these branches are blocked to preserve synchronisation with our internal repositories.

• We maintain a separate community branch in each public repository to accept and review external contributions.

Contribution process

1. Fork the repository

   • Create your own fork of the relevant Portainer public repository.

2. Create a feature branch

   • Base your changes on the current develop branch (not main, release/*, or community). This ensures you are working off the latest version of the codebase.

3. Submit a Pull Request (PR)

   • Open your PR against the develop branch.

   • Portainer engineers will update the target branch to community when the contribution is ready to be merged.

4. Review and feedback

   • Contributions will be reviewed by Portainer engineers.

   • We may request changes to align with coding standards, tests, or design decisions.

   • In some cases, we may adapt or refactor a contribution before merging.

5. Integration

   • Once approved and merged into community, Portainer engineers will cherry-pick contributions into the upstream private repository.

   • These changes will then flow into develop and subsequent releases through our normal sync process.

   • Not all contributions will be integrated upstream. Decisions will be based on roadmap alignment, technical fit, and quality.

Contribution expectations

• Coding standards: Please follow existing project style and conventions.

• Tests: Include tests where applicable. Contributions without tests may be delayed.

• Documentation: Update relevant docs (e.g. README, usage notes) when changing functionality.

• Scope: Focus on well-defined features, fixes, or improvements. Large architectural changes should be discussed in an issue first.

Communication

• For significant changes or new features, use GitHub Discussions to start a discussion before starting the change.

• PR discussions are the best place for clarifications on specific contributions.

Reporting bugs

If you find a bug, please tell us so we can triage it. All bugs are managed in the GitHub issues repo. When you click through, our template makes it easy to record all of the details. Check the list of open bugs before reporting to avoid duplicates.

This article covers how we prioritize bug fixes.

Feature requests

You can request new features by posting an Idea in our GitHub Discussions forum. Please check to see if someone has already requested the feature you want, and give it an upvote if so.

Learn how we prioritize feature development in this article.