So you’re looking to contribute to Dify - that’s awesome, we can’t wait to see what you do. As a startup with limited headcount and funding, we have grand ambitions to design the most intuitive workflow for building and managing LLM applications. Any help from the community counts, truly.

We need to be nimble and ship fast given where we are, but we also want to make sure that contributors like you get as smooth an experience at contributing as possible. We’ve assembled this contribution guide for that purpose, aiming at getting you familiarized with the codebase & how we work with contributors, so you could quickly jump to the fun part.

This guide, like Dify itself, is a constant work in progress. We highly appreciate your understanding if at times it lags behind the actual project, and welcome any feedback for us to improve.

In terms of licensing, please take a minute to read our short License and Contributor Agreement. The community also adheres to the code of conduct.

​
Before you jump in

Find an existing issue, or open a new one. We categorize issues into 2 types:

​
Feature requests:

  • If you’re opening a new feature request, we’d like you to explain what the proposed feature achieves, and include as much context as possible. @perzeusss has made a solid Feature Request Copilot that helps you draft out your needs. Feel free to give it a try.

  • If you want to pick one up from the existing issues, simply drop a comment below it saying so.

    A team member working in the related direction will be looped in. If all looks good, they will give the go-ahead for you to start coding. We ask that you hold off working on the feature until then, so none of your work goes to waste should we propose changes.

    Depending on whichever area the proposed feature falls under, you might talk to different team members. Here’s rundown of the areas each our team members are working on at the moment:

    MemberScope
    @yeuolyArchitecting Agents
    @jyongRAG pipeline design
    @GarfieldDaiBuilding workflow orchestrations
    @iamjoel & @zxhlyhMaking our frontend a breeze to use
    @guchenhe & @crazywoolaDeveloper experience, points of contact for anything
    @takatostOverall product direction and architecture

    How we prioritize:

    Feature TypePriority
    High-Priority Features as being labeled by a team memberHigh Priority
    Popular feature requests from our community feedback boardMedium Priority
    Non-core features and minor enhancementsLow Priority
    Valuable but not immediateFuture-Feature

​
Anything else (e.g. bug report, performance optimization, typo correction):

  • Start coding right away.

    How we prioritize:

    Issue TypePriority
    Bugs in core functions (cannot login, applications not working, security loopholes)Critical
    Non-critical bugs, performance boostsMedium Priority
    Minor fixes (typos, confusing but working UI)Low Priority

​
Installing

Here are the steps to set up Dify for development:

​
1. Fork this repository

​
2. Clone the repo

Clone the forked repository from your terminal:

git clone git@github.com:<github_username>/dify.git

​
3. Verify dependencies

Dify requires the following dependencies to build, make sure they’re installed on your system:

​
4. Installations

Dify is composed of a backend and a frontend. Navigate to the backend directory by cd api/, then follow the Backend README to install it. In a separate terminal, navigate to the frontend directory by cd web/, then follow the Frontend README to install.

Check the installation FAQ for a list of common issues and steps to troubleshoot.

​
5. Visit dify in your browser

To validate your set up, head over to http://localhost:3000 (the default, or your self-configured URL and port) in your browser. You should now see Dify up and running.

​
Developing

If you are adding a model provider,this guide is for you.

If you are adding tools used in Agent Assistants and Workflows, this guide is for you.

Note : If you want to contribute to a new tool, please make sure you’ve left your contact information on the tool’s ‘YAML’ file, and submitted a corresponding docs PR in the Dify-docs repository.

To help you quickly navigate where your contribution fits, a brief, annotated outline of Dify’s backend & frontend is as follows:

​
Backend

Dify’s backend is written in Python using Flask. It uses SQLAlchemy for ORM and Celery for task queueing. Authorization logic goes via Flask-login.

[api/]
├── constants             // Constant settings used throughout code base.
├── controllers           // API route definitions and request handling logic.           
├── core                  // Core application orchestration, model integrations, and tools.
├── docker                // Docker & containerization related configurations.
├── events                // Event handling and processing
├── extensions            // Extensions with 3rd party frameworks/platforms.
├── fields                // field definitions for serialization/marshalling.
├── libs                  // Reusable libraries and helpers.
├── migrations            // Scripts for database migration.
├── models                // Database models & schema definitions.
├── services              // Specifies business logic.
├── storage               // Private key storage.      
├── tasks                 // Handling of async tasks and background jobs.
└── tests

​
Frontend

The website is bootstrapped on Next.js boilerplate in Typescript and uses Tailwind CSS for styling. React-i18next is used for internationalization.

[web/]
├── app                   // layouts, pages, and components
│   ├── (commonLayout)    // common layout used throughout the app
│   ├── (shareLayout)     // layouts specifically shared across token-specific sessions 
│   ├── activate          // activate page
│   ├── components        // shared by pages and layouts
│   ├── install           // install page
│   ├── signin            // signin page
│   └── styles            // globally shared styles
├── assets                // Static assets
├── bin                   // scripts ran at build step
├── config                // adjustable settings and options 
├── context               // shared contexts used by different portions of the app
├── dictionaries          // Language-specific translate files 
├── docker                // container configurations
├── hooks                 // Reusable hooks
├── i18n                  // Internationalization configuration
├── models                // describes data models & shapes of API responses
├── public                // meta assets like favicon
├── service               // specifies shapes of API actions
├── test                  
├── types                 // descriptions of function params and return values
└── utils                 // Shared utility functions

​
Submitting your PR

At last, time to open a pull request (PR) to our repo. For major features, we first merge them into the deploy/dev branch for testing, before they go into the main branch. If you run into issues like merge conflicts or don’t know how to open a pull request, check out GitHub’s pull request tutorial.

And that’s it! Once your PR is merged, you will be featured as a contributor in our README.

​
Getting Help

If you ever get stuck or got a burning question while contributing, simply shoot your queries our way via the related GitHub issue, or hop onto our Discord for a quick chat.

Edit this page | Report an issue