Project · Arion
Community
Where the Arion community talks and how to contribute.
Arion is developed, mostly in the open on GitHub.
Discussing Arion
- GitHub Discussions is the home of the community: questions, configuration help, ideas and what you are building. Public answers become documentation for the next person.
- GitHub issues track bugs and focused feature requests.
- The blog carries announcements and engineering posts, with a feed to subscribe to.
Security reports are the one exception: never post a suspected vulnerability publicly. Use the private route instead.
How Arion is built
Arion is maintained by a small core team that designs and carefully reviews all code. The types of contributions that help us the most are:
- Tell us what you run. A description of your traffic, your control plane and what you need or what problem you are trying to solve.
- Report bugs well. A version, a minimal config and the expected and actual behaviour helps us to evaluate address the issue more quickly.
- Propose features as problems. Describe the requirement and the constraints; we would rather design the solution together than review one that arrives fully formed.
- Improve the docs. Tell us where a page lost you, or tell us what you are trying to figure out.
Before writing code, open a discussion or an issue. We are careful about what lands on the data path and our review bandwidth is limited, so we prefer to capture the requirement in the open, agree on a design, and often we may prefer to implement it ourselves. Small, obvious fixes — typos, documentation corrections, clearly broken behaviour — are always welcome as direct pull requests. Large, unannounced pull requests will be rejected. No slop.
The repository's CONTRIBUTING.md has the full policy.
AI-assisted & Agentic Development
We clearly understand the advantages of AI and use it a lot day to day. A small team like ours could not build and maintain a system like Arion at the speed we do, without it. We are equally clear about its limitations.
Building a data plane with Arion's performance and flexibility requires discipline and a lot of deep work. It involves many small decisions whose effects compound, and we cannot outsource those decisions to AI. Arion's combination of performance and programmability is somewhat unique in the ecosystem. We believe staying deep in the code and making those decisions ourselves is absolutely essential to preserving it.
Not all code changes are equal. There are code paths in every system that are more critical than others. Regardless, of the change, we always read the code when authoring and then go through a conventional code review process. In particular, we throughly review all code on the data path slowly and carefully. Code review bandwidth is our most constrained resource, which is why we favour feature requests and discussion over code submissions. Large code contributions will almost certainly be refused, whether written with AI or by hand. Small, obvious fixes remain welcome, as described above.
What helps us most is direct interaction with the community: use cases, bug reports, feature requests and design discussions. That input helps the maintainers consider changes across the whole system and take them forward through design and implementation.
What a good report contains
Whichever route you take, a small, complete case gets the fastest answer:
- Arion version and deployment mode
- The smallest configuration that reproduces the problem
- Expected and actual behaviour
- Sanitised logs, with secrets or any sensitive data removed
The support page lists every route to help, including working with the core maintainers directly.