DooTask: self-hosted task management, IM and documents in one Docker stack

What DooTask replaces, and for whom

DooTask is an online project and task management tool that also ships document collaboration, online mind maps, online flowcharts, instant messaging and file management. The repository description also states that the messaging feature uses asymmetric encryption. That combination is the point: a team that would otherwise run a task tracker, a separate chat tool and a file share can put one application behind one port.

The intended user is a team willing to run its own server. The README lists installation requirements of Docker v20.10+ and Docker Compose v2.0+, supported systems of CentOS, Debian, Ubuntu and macOS plus other Linux/Unix systems, and a hardware recommendation of 2 or more cores and 4GB or more memory. Windows users are told to install a Linux environment using WSL2 first. If your team has no one who can keep a Docker host patched and backed up, this is the wrong shape of product regardless of features.

The container topology behind a DooTask install

The docker-compose.yml in the repository defines separate services rather than one monolith image. A php service runs image kuaifan/php:swoole-8.4.27 and mounts the project at /var/www, with MYSQL_HOST, MYSQL_PORT, MYSQL_DB_NAME, MYSQL_USERNAME and MYSQL_PASSWORD passed in from environment variables. It declares depends_on for mariadb and redis with condition: service_healthy, and its own healthcheck curls http://localhost:${LARAVELS_LISTEN_PORT}/health. The nginx service uses nginx:alpine, publishes ${APP_PORT}:80 and ${APP_SSL_PORT:-0}:443, and waits on php being healthy before it starts.

Two consequences follow from that layout. First, the database is part of the stack: the README states MariaDB is provided by the default Docker Compose mariadb service, so there is no external database to point at out of the box. Second, nginx waits for the php healthcheck before it starts, and the README tells you to run ./cmd reup after an upgrade if you see 502 errors. The php.ini, php.conf, crontab.conf and license.conf files are bind-mounted from the docker/ directory, so configuration changes are file edits followed by a restart, not dashboard clicks.

Installing DooTask with the one-line script or a manual clone

The README gives two deployment paths. The recommended one is a shell script that clones and installs automatically when run in an empty directory, and checks and upgrades when run inside an existing installation:

curl -fsSL https://raw.githubusercontent.com/kuaifan/dootask/pro/bin/install | bash

Because the same command installs and upgrades, the directory you run it in decides what happens. Run it in an empty directory for a fresh install.

The manual path clones the repository and calls the bundled cmd script:

git clone --depth=1 https://github.com/kuaifan/dootask.git
cd dootask
./cmd install

The README notes that a custom port can be passed as ./cmd install --port 80. A Gitee mirror is documented as an alternative clone source at https://gitee.com/aipaw/dootask.git. After installation the default administrator password can be reset with ./cmd repassword, and the HTTP port changed later with ./cmd port 80, which the README says does not affect the HTTPS port.

Day-to-day operations: ports, TLS and service control

Service control goes through the same cmd script. ./cmd down stops the stack and ./cmd up starts it. For TLS the README offers two methods. The automatic one runs:

./cmd https

The proxy method expects you to add X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-For headers in your own Nginx configuration and then run ./cmd https agent; ./cmd https close cancels that proxy configuration. The APP_SCHEME environment variable in .env.example defaults to auto, and docker-compose.yml passes it to the nginx container.

Upgrades are the part to plan around. The README states plainly that you should back up your data before upgrading, and gives two routes: rerun the one-line script inside the existing installation, or run ./cmd update locally. If the upgrade leaves you with 502 errors, ./cmd reup restarts the services. There is no documented rollback command, so the documented migration process also requires preserving the appstore and uploads directories alongside the database backup.

Moving a DooTask instance and what the backup actually contains

The migration instructions are the clearest statement of where state lives. On the old instance you run ./cmd mysql backup, which the README describes as a CLI subcommand that backs up against the MariaDB container. You then copy three things to the same paths on the new instance: the database backup file, the docker/appstore directory, and public/uploads. On the new instance you run ./cmd mysql recovery.

That means a database-only backup is incomplete. Files uploaded through the file management and document features live under public/uploads, and docker/appstore is copied separately, so any backup routine you build has to cover all three. The README does not document a rollback procedure or a point-in-time recovery option for the database, and it does not describe how to verify a restored instance beyond running the recovery command. Uninstalling is a single ./cmd uninstall; the README does not say whether that removes volumes or leaves them behind.

Where DooTask is the wrong tool

The AGPL-3.0 licence is the first constraint. If you intend to offer a modified DooTask as a network service to users outside your organization, the licence's source-availability obligations apply to your modified version. Teams that want to embed a task tracker inside a closed product should not start here.

Operationally, the stack assumes a persistent Linux host with Docker. The README recommends 2 or more cores and 4GB or more memory, and the php service requests shm_size: 2G, so a small VPS will be tight. There is no documented managed hosting, no documented horizontal scaling, and no documented multi-node setup; the compose file is a single-host arrangement. A team of two who wants a hosted board with zero maintenance should use a hosted product instead.

Development has its own prerequisite. The README states that building requires NodeJs 20 or later, with ./cmd dev for development mode and ./cmd prod for the web client build. Desktop application builds are not covered by ./cmd prod; the README points to .github/workflows/publish.yml instead. If you only want to run DooTask, none of this matters. If you plan to modify the front end, it does.

How DooTask differs from Orangescrum and other trackers

Against Orangescrum, the difference is scope rather than features. Orangescrum is a project and task management product; DooTask's repository description lists document collaboration, online mind maps, online flowcharts, project management, task distribution, instant messaging and file management in the same application, with messaging using asymmetric encryption. Choosing DooTask means accepting one deployment that covers chat and files as well as tasks, instead of wiring several self-hosted services together.

The cost of that breadth shows in the install. DooTask expects Docker Compose, MariaDB, Redis and Nginx containers, and its own cmd wrapper for install, upgrade, backup and TLS. A single-binary or SQLite-backed tracker asks far less of the host. The trade is that you get one backup and one upgrade path for everything, which the migration steps make concrete: database dump, docker/appstore, public/uploads.

Licence and the cost of staying current

DooTask is licensed AGPL-3.0. AGPL section 13 addresses users interacting over a network with a modified version; distribution has additional conditions. Assess the obligations for the version and deployment you actually use. This is not legal advice; read the licence text against your own deployment model before you build on it.

Upgrade cost is real but bounded. Releases are frequent: v1.10.38 on 2026-10-29, v1.10.12 on 2026-10-22, v1.9.66 on 2026-10-10, and the last push to the default branch was on 2026-10-29. Each upgrade is a rerun of the installer or ./cmd update, preceded by a backup and followed by ./cmd reup if 502 errors appear. The README does not publish a support window or a long-term release branch, so pinning to an old version means forgoing fixes with no stated end-of-life date. Budget the backup step as part of the upgrade, not as an optional extra.

Editorial conclusion

Adopt DooTask if you want task management, chat and document collaboration on hardware you control and you accept the AGPL-3.0 obligations that come with the code. Do not adopt it if you need a managed service with a support contract, or if your team cannot run MariaDB, Redis and Docker Compose. Before committing, verify that the one-line installer's default ports do not collide with anything already listening, confirm your backup path covers docker/appstore and public/uploads as well as the MariaDB dump, and read the AGPL-3.0 text against how you intend to expose the instance to users outside your organization.

Frequently asked questions

Official sources

1. kuaifan/dootask on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases