tduck-survey-form: an open source Chinese survey platform built for private deployment
为企业提供「免费」表单问卷能力，「开箱即用」快速赋能业务 A questionnaire system that can be privatized and deployed - 填鸭表单问卷系统（tduck-survey-form）表单系统-问卷系统
At a glance
- What is it?
- TDuck is a Java questionnaire system that gives enterprises a drag-and-drop form builder, per-respondent limits, WeChat integration and webhook data sync, with a community edition whose backend is open source and two paid editions that differ mainly in source access and enterprise features.
- Who is it for?
- TDuck fits a Chinese enterprise that has to keep its form data on its own servers, that already runs a Java stack, and that wants WeChat distribution rather than an email-and-link survey tool. It is a poor fit if you want a hosted product with no infrastructure to run, and a poor fit if your requirement is a simple multi-page form, since the platform is a full system with dashboards, reports and account management.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why the project exists: data control for a regulated buyer
TDuck is positioned as an enterprise form and data collection platform, with drag-and-drop form design, private deployment and open integration, intended to let a business build a data entry point and collect data efficiently. The comparison the project draws is against traditional SaaS form products, and the argument is about data control and deployment freedom rather than about the forms themselves.
The three versions are the key to understanding the product. The form system has three versions, community, Pro and TDuckX, and the README links a capability comparison table. The community edition is the one in this repository, and the table is where the differences are laid out honestly.
On deployment, the community edition supports private deployment and the enterprise source edition adds privatised and domestic-technology deployment. On data storage, the community edition puts data on the enterprise's own servers, and the table gives the same for the enterprise edition. On source openness, the community edition does not open the source, the enterprise edition gives complete commercial source delivery, and the table marks source opening as available for the community edition's backend. On secondary development, the community edition requires you to extend it yourself and the enterprise edition supports deep customisation and source-level development. On integration, the community edition offers WebHook and the enterprise edition adds API, WebHook, a user system and business system integration. On organisation and permissions, the community edition has user management and the enterprise edition has an enterprise organisation, role and permission system. On SSO, the community edition requires you to build it and the enterprise edition supports integration to enterprise requirements. On vendor dependency, the traditional SaaS is rated high, the community edition low and the enterprise edition controllable. And on operating responsibility, the SaaS leaves it to the vendor while the community edition leaves it to the enterprise.
That last row is the honest centre of the product. The community edition moves the operational burden to you in exchange for the data staying inside your perimeter, and the paid editions exist for organisations that want that perimeter without the burden.
The project is MIT licensed, the primary language is Java, the last push was on 2026-10-14, and there are no published GitHub releases. The homepage is tduckcloud.com.
The component set, and the feature list that goes with it
The feature list is long, and the items that matter for an adoption decision are the ones that are unusual for a survey tool.
There are more than 27 custom components for drag-and-drop form building. The named ones include single-line text, multi-line text, date, dropdown, radio, file upload, sorting, cascading, carousel, one-tap positioning, phone number verification, matrix scale and sub-form, and there is also bulk import of form components from text and settings for question show and hide logic.
The response controls are the part that stands out. Every WeChat, account, IP, device and answer count can be limited, there are settings for the allowed filling window, and it records WeChat personal information. For a Chinese business running a public survey, a limit of one response per person is a hard requirement rather than a nice-to-have, and the combination of device, IP and WeChat identity is a reasonably thorough answer to the duplicate-response problem.
Then the integration surface. There is a data sync API for full data, and data WebHook push with subscribable events for create, update and delete. There is email, WeChat official account template push for reminders, and a template centre where forms can be saved and reused. File storage is configurable across Aliyun, Qiniu, Upyun, local and generic S3 protocol uploads. And email, SMS through Aliyun, Tencent Cloud and Zhongyun Weixin, plus WeChat official account parameters, can be configured.
Reporting is present too. Reports do real-time statistical analysis on the questions and present the output as bar, line and pie charts, with PNG export, and there is configuration for TReport visual large-screen display for showing the data. The data side supports add, edit, export, print, preview and packaged download of attachments, and there is a recycle centre for quickly restoring a questionnaire.
The module list at the top of the repository shows how this is split in Java: tduck-account, tduck-ai, tduck-api, tduck-common, tduck-form, tduck-storage, tduck-webhook and tduck-wx-mp, with a pom.xml at the root, a docker/ directory and a doc/ directory.
The Java module layout, and the WeChat surface that defines the product
The repository top level shows a Maven multi-module project, with pom.xml at the root and the modules named for what they do: tduck-account for accounts, tduck-ai, tduck-api, tduck-common for shared code, tduck-form for the form engine itself, tduck-storage for file storage, tduck-webhook for the event push side and tduck-wx-mp for the WeChat official account integration. There is a docker/ directory for the container build and a doc/ directory for documentation, and the readmeImages/ directory holds the screenshots used in the README.
The WeChat module is the one that explains the response controls. The feature list ties limits to WeChat, accounts, IPs, devices and answer counts, and there is a separate WeChat official account template push for reminders, plus WeChat personal information being recorded. There is a small-program plugin documented as well, which is the WeChat mini-program variant of the same survey.
So the product has two distribution channels in China: the ordinary web form with a link, and a WeChat-native path where the respondent is identified, the official account can push a reminder, and the response can be tied to a person. That combination is what an enterprise doing customer feedback inside WeChat needs, and it is why the response limiting is per WeChat identity rather than only per IP.
The tduck-ai module is present in the tree, and the screenshots in the preview section include entries for AI configuration and AI form building, so the AI features are part of the application rather than a separate service. The README's feature list itself does not describe them, which means the documentation of what they do lives elsewhere, in the product site and the deployment documentation.
The front end is not in this repository. It is a separate project, and the deployment section lists a separated front-end and back-end deployment route for teams that need to run the two independently.
Deployment, and the default credentials you must change
There are four documented deployment routes, and they are aimed at different levels of operator.
The first is one-click installation through the BaoTa panel, which the README marks as the recommended route and links a guide for beginners. The second is a quick start with Docker. The third is deploying the project with BaoTa, and the fourth is a separated front-end and back-end deployment for people who need to run the two tiers separately.
The Docker route and the separated deployment route are the ones to look at if you are running this properly rather than trialling it, and the front-end project lives in a separate repository, with the small-program plugin documented separately as well.
The detail that has to be read is the deployment account. The administrator account is [email protected] and the default password is 123456. That is stated plainly in the README as a deployment note, which is unusual candour, and it is also the first thing you have to change.
The two deployment routes imply two different operational profiles. The BaoTa route gives you a panel, a database and a Java process managed for you, which suits a team that already runs BaoTa for other sites. The separated deployment means you are running the API and the front end yourself, which is what you need if the front end has to sit behind your own gateway, and the front-end repository is on Gitee alongside the main community, so a team without access to that hosting has a problem to solve.
The product also runs a hosted preview at tduckcloud.com, and the README links a Gitee issue tracker as the user community, with a Bilibili channel as well.
The three-way version split, and what the community edition leaves you
The version structure deserves one more pass, because the decision is not simply open source versus paid.
The table's dimension list runs from deployment and data storage through data control, source openness, secondary development, system integration, organisation and permissions, SSO, project delivery, deployment environment adaptability, domestic technology adaptation, operating responsibility, upgrade path, vendor dependency, long-term cost and suitable scenarios.
Two rows are the ones that decide it for most buyers. The long-term cost row says the SaaS is a continuous subscription, the community edition has a low software cost with development and operations cost borne by the enterprise, and the enterprise edition is software licensing plus controllable technical service. And the suitable scenarios row says the SaaS is for fast online use, the community edition for a technical team building it themselves, and the enterprise edition for enterprise informatisation, private deployment projects, system integration and commercial delivery.
So the community edition is aimed squarely at a team with Java skills and willingness to operate the system, and the enterprise edition at a team that wants the same thing with support attached.
The README also notes that data from all versions can be integrated into the large-screen display through WebHook, with a tutorial linked, which means the choice of edition does not lock you out of the reporting side. And it closes with a warning that if you are evaluating the form system for a commercial project or a private deployment delivery, you should look closely at source licensing and the long-term cost structure, which is a reasonable thing for a project with a mixed open and commercial offering to say about itself.
For a self-hosted evaluation, the practical entry point is the Docker route, since it does not require a BaoTa panel or a Gitee-hosted front-end to try out.
Editorial conclusion
TDuck fits a Chinese enterprise that has to keep its form data on its own servers, that already runs a Java stack, and that wants WeChat distribution rather than an email-and-link survey tool. It is a poor fit if you want a hosted product with no infrastructure to run, and a poor fit if your requirement is a simple multi-page form, since the platform is a full system with dashboards, reports and account management. Before adopting, plan the file storage backend, since the configuration lists Aliyun, Qiniu, Upyun, local and generic S3 uploads, and change the deployment defaults, because the documented administrator account ships with a fixed password.
Frequently asked questions
What is TDuck and what is it for?
TDuck is an enterprise form and data collection platform with drag-and-drop form design, private deployment and open integration, meant to give a business a controlled data entry point. The repository holds the community edition, whose backend is open source and which is aimed at teams that want the data on their own servers.
How do I deploy TDuck?
There are four documented routes: one-click installation through the BaoTa panel, which the README recommends, a quick start with Docker, a BaoTa deployment of the project, and a separated front-end and back-end deployment. The front-end project is in a separate repository, and the small-program plugin is documented separately.
What are the default deployment credentials?
The administrator account is [email protected] and the default password is 123456. The README states these as deployment notes, and they need to be changed before the instance is reachable by anyone else.
What are the differences between the community, Pro and TDuckX editions?
The community edition is MIT licensed, supports private deployment with data on your own servers, offers WebHook integration and user management, and leaves secondary development and SSO to you. The Pro and TDuckX editions add full commercial source delivery, deep customisation, API and user system integration, an enterprise organisation and role model, SSO integration, project delivery, domestic technology adaptation, vendor support and an enterprise upgrade path.
Which file storage backends can TDuck use?
File storage is configurable across Aliyun, Qiniu, Upyun, local and generic S3 protocol uploads, so you can keep the uploaded attachments wherever your data residency rules require.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/tduckcloud-tduck-survey-form)Was this useful?