Contribution Guide
Dynamo is an open-source distributed inference platform, built by a growing community of contributors. The project is licensed under Apache 2.0 and welcomes contributions of all sizes — from typo fixes to major features. Community contributions have shaped core areas of Dynamo including backend integrations, documentation, deployment tooling, and performance improvements.
With 200+ external contributors, 220+ merged community PRs, and new contributors joining every month, Dynamo is one of the fastest-growing open-source inference projects. Check out our commit activity and GitHub stars. This guide will help you get started.
Join the community:
- CNCF Slack (
#ai-dynamo) — join CNCF Slack and find us in#ai-dynamo - Discord
- GitHub Discussions
TL;DR
For experienced contributors:
- Fork and clone the repo
- For changes ≥100 lines or new features, open an issue first
- Create a branch:
git checkout -b yourname/fix-router-timeout - Make changes, run
pre-commit run - Commit with DCO sign-off:
git commit -s -m "fix: description" - Open a PR targeting
main
Ways to Contribute
Report a Bug
Found something broken? Open a bug report with:
- Steps to reproduce
- Expected vs. actual behavior
- Environment details (OS, GPU, Python version, Dynamo version)
Improve Documentation
Documentation improvements are always welcome:
- Fixing typos or unclear explanations
- Adding examples or tutorials
- Improving API documentation
Small doc fixes can be submitted directly as PRs without an issue.
Propose a Feature
Have an idea? Open a feature request to discuss it with maintainers before implementation.
Contribute Code
Ready to write code? See the Contribution Workflow section below.
Help the Community
Not all contributions are code. You can also:
- Answer questions on Discord or CNCF Slack
- Review pull requests
- Share how you’re using Dynamo — blog posts, talks, or social media
- Star the repository
Getting Started
Find an Issue
Browse open issues or look for:
Fork and Clone
- Fork the repository on GitHub
- Clone your fork:
Building from Source
Full build instructions are included below. Expand the accordion to set up your local development environment.
Expand build instructions
1. Install System Libraries
Ubuntu:
macOS:
2. Install Rust
3. Create a Python Virtual Environment
Install uv if you don’t have it:
Create and activate a virtual environment:
4. Install Build Tools
Maturin is the Rust-Python bindings build tool.
5. Build the Rust Bindings
6. Install GPU Memory Service
7. Install the Wheel
8. Verify the Build
VSCode and Cursor users can use the .devcontainer folder for a pre-configured development environment. See the devcontainer README for details.
Set Up Pre-commit Hooks
You’re all set up! Get curious — explore the codebase, experiment with the examples, and see how the pieces fit together. When you’re ready, pick an issue from the Good First Issues board or read on for the full contribution workflow.
Contribution Workflow
The contribution process depends on the size and scope of your change. Even when not required, opening an issue is a great way to start a conversation with Dynamo maintainers before investing time in a PR.
Small changes (under 100 lines): Submit a PR directly — no issue needed. This includes typos, simple bug fixes, and formatting. If your PR addresses an existing approved issue, link it with “Fixes #123”.
Larger changes (≥100 lines): Open a Contribution Request issue first and wait for the approved-for-pr label before submitting a PR.
Architecture changes: Changes that affect multiple components, introduce or modify public APIs, alter communication plane architecture, or affect backend integration contracts require a Dynamo Enhancement Proposal (DEP). Open a DEP in the ai-dynamo/enhancements repo before starting implementation.
Submitting a Pull Request
-
Create a GitHub Issue (if required) — Open a Contribution Request and describe what you’re solving, your proposed approach, estimated PR size, and files affected.
-
Get Approval — Wait for maintainers to review and apply the
approved-for-prlabel. -
Submit a Pull Request — Open a PR that references the issue using GitHub keywords (e.g., “Fixes #123”).
-
Address Code Rabbit Review — Respond to automated Code Rabbit suggestions, including nitpicks.
-
Trigger CI Tests — For external contributors, a maintainer must comment
/ok to test COMMIT-IDto run the full CI suite, whereCOMMIT-IDis the short SHA of your latest commit. Fix any failing tests before requesting human review. -
Request Review — Add the person who approved your issue as a reviewer. Check CODEOWNERS for required approvers based on files modified.
AI-Generated Code: While we encourage using AI tools, you must fully understand every change in your PR. Inability to explain submitted code will result in rejection.
Branch Naming
Use a descriptive branch name that identifies you and the change:
Examples:
Code Style & Quality
Maintainers assess contribution quality based on code style, test coverage, architecture alignment, and review responsiveness. Consistent, high-quality contributions are the foundation for building trust in the project.
Pre-commit Hooks
All PRs are checked against pre-commit hooks. After installing pre-commit, run checks locally:
Commit Message Conventions
Use conventional commit prefixes:
Examples:
Language Conventions
Testing
Run the test suite before submitting a PR:
For Rust components:
For the Kubernetes operator (Go):
General Guidelines
- Keep PRs focused — one concern per PR
- Write clean, well-documented code that future contributors can understand
- Include tests for new functionality and bug fixes
- Ensure clean builds (no warnings or errors)
- All tests must pass
- No commented-out code
- Respond to review feedback promptly and constructively
Running GitHub Actions Locally
Use act to run workflows locally:
Or use the GitHub Local Actions VS Code extension.
What to Expect
Status Labels
Response Times
We aim to:
- Respond to new issues within a few business days
- Triage high-priority issues within a week
Issues with no activity for 30 days may be auto-closed (can be reopened).
Review Process
After you submit a PR and complete the steps in Submitting a Pull Request:
- The reviewer will provide feedback — please respond to all comments within a reasonable timeframe
- If changes are requested, address them and ping the reviewer for re-review
- If your PR hasn’t been reviewed within 7 days, feel free to ping the reviewer or leave a comment
Good First Issues
Issues labeled good-first-issue are sized for new contributors. We provide extra guidance on these — look for clear acceptance criteria and a suggested approach in the issue description.
DCO & Licensing
Developer Certificate of Origin
Dynamo requires all contributions to be signed off with the Developer Certificate of Origin (DCO). This certifies that you have the right to submit your contribution under the project’s Apache 2.0 license.
Each commit must include a sign-off line:
Add this automatically with the -s flag:
Requirements:
- Use your real name (no pseudonyms or anonymous contributions)
- Your
user.nameanduser.emailmust be configured in git
DCO Check Failed? See our DCO Troubleshooting Guide for step-by-step instructions to fix it.
License
By contributing, you agree that your contributions will be licensed under the Apache 2.0 License.
Code of Conduct
We are committed to providing a welcoming and inclusive environment. All participants are expected to abide by our Code of Conduct.
Security
If you discover a security vulnerability, please follow the instructions in our Security Policy. Do not open a public issue for security vulnerabilities.
Getting Help
- CNCF Slack: Join CNCF Slack and find us in
#ai-dynamo - Discord: Join our community
- Discussions: GitHub Discussions
- Documentation: docs.nvidia.com/dynamo
Thank you for contributing to Dynamo!