Build with ForgeUI. Help shape what comes next.
ForgeUI is developed in the open. Contribute firmware, board support, Studio features, documentation, testing or complete example projects.
Developer portal
Documentation and project paths
Start with the public guide, open the detailed code maps when you need implementation depth, or continue to a project contribution area.
Working product
Studio, generated runtime and target output
A concise view of the current workflow. Detailed architecture, ownership and validation records remain in the Document Centre.
Contribution areas
Ways to Contribute
Choose the layer you understand. Each contribution should include the evidence needed to review it safely.
Studio Development
React, TypeScript, editor workflow and UI systems.
Open guide →Embedded Runtime
ESP-IDF, LVGL, FreeRTOS and device integration.
Open guide →Board Support
Displays, touch controllers, BSPs and hardware ports.
Open guide →Components
Reusable interactive controls and generated APIs.
Open guide →Documentation
Guides, examples, troubleshooting and API reference.
Open guide →Testing
Browser, export, build, flash and physical hardware validation.
Open guide →Design
Themes, icons, workflows and embedded HMI usability.
Open guide →Example Projects
Real product demonstrations and reproducible starter projects.
Open guide →Pull request workflow
Start Contributing
Fork the product repository into your own GitHub account. Keep the branch focused and state exactly what you validated.
- Fork the repository
- Create a focused branch
- Read the relevant docs
- Make the change
- Add or update tests
- Validate locally
- Open a pull request
- Respond to review
git clone <your-fork-url>
git checkout -b feat/my-feature
git add .
git commit -m "feat: add my feature"
git push -u origin feat/my-featureReview baseline
Contribution Principles
A browser implementation is only one layer. Embedded changes must remain coherent through persistence, export, build and hardware.
Keep the change reviewable
Keep changes focused, follow existing naming and architecture, avoid unrelated refactors and document new behaviour. Never commit secrets.
Supply engineering evidence
Add tests, identify the hardware exercised, preserve proven behaviour and separate experimental results from officially supported features.
Respect ownership boundaries
Generated UI belongs in the Studio-managed layer. Product behaviour belongs in developer-owned hooks and normal ESP-IDF components.
Open guide →Complete the full path
Component definition → Studio palette → Canvas → Inspector → Preview → persistence → LVGL export → generated API → tests → docs.
Open guide →