TaoSync for OpenList and AList Storage Synchronization

What TaoSync Synchronizes and Who It Is For

TaoSync addresses recurring file movement between local storage, cloud drives, FTP servers, and similar services. The README identifies synchronized backups and scheduled downloads as its main use cases. A backup job can scan a selected source directory on an interval, compare it with one or more destinations, and copy changed or missing content. A one-time job can be expressed through `cron`, which the documentation describes as useful for moving cloud files to local storage during off-peak periods.

The intended users are people who understand storage endpoints and credentials, or who want a self-hosted interface for OpenList v3+ and AList. TaoSync is not limited to those external applications because its built-in `TaoSync` engine is created automatically and cannot be removed. That engine supports local directories, SMB, FTP and FTPS, SFTP, and the Aliyun Drive Open Platform. External OpenList and AList engines remain supported when an installation needs additional drivers.

The project is written in Python on the backend and uses Vue for the frontend. The README lists releases for Windows, macOS, Linux, Android, and several CPU architectures, as well as a Docker image. This makes the project relevant to users who need a cross-platform desktop or self-hosted service. The application manages jobs, engines, schedules, task records, logs, exclusions, file-size filters, notifications, and retention settings through its interface.

TaoSync Engine and Storage Data Flow

Based on the repository layout, TaoSync has a Python application entry point, service modules, controllers, mappers, a web interface, and a packaged executable specification. The built-in engine is the central abstraction for storage access. It is created on first startup with no directories, after which the directory manager adds virtual directories backed by a supported storage type. The documentation describes these directories as the endpoints that jobs scan and compare.

For a local directory, the configured path must be visible to the TaoSync process. That requirement has a direct Docker consequence: the host directory must be mounted into the container. For SMB, TaoSync accepts a server, share, credentials, and an optional root. It can scan the `/24` networks associated with TaoSync's active private IPv4 addresses for devices accepting TCP 445, while manual entry remains possible.

FTP support depends on `MLSD`. TaoSync uses that command to distinguish files, directories, and unsafe link-like entries without leaving the configured root. SFTP configuration includes a server, port, username, and other connection settings described in the README. Jobs can run by interval, `cron`, or manual invocation. Their modes include Add only, Full sync, Move mode, and Source Directory Mode, which lets later jobs scan only the source and compare it with a database snapshot. The README does not document implementation-level behavior for conflict resolution, checksum validation, or partial files.

Scheduling, Filtering, and Task Controls

TaoSync treats synchronization as a managed job rather than a single file-copy command. A job can target a configured source and destination, exclude specified directories or files, and apply independent minimum and maximum file-size filters. These controls are useful when a storage endpoint contains logs, temporary uploads, archives, or files that should remain outside a backup. The README does not define whether filters affect directory traversal, comparisons, or deletion decisions, so operators should verify that behavior with representative files.

The three synchronization modes express different destination policies. Add only copies source files that are absent from the destination. Full sync is intended to make the destination match the source. Move mode is also available, but the README does not explain its exact deletion or post-transfer semantics. Source Directory Mode changes the comparison source for later jobs by using a database snapshot. That design can reduce repeated traversal of a source, but it also makes database retention and snapshot correctness important.

The interface is documented as showing per-file progress, overall progress, synchronization speed, the current file, and estimated completion time. Jobs can be created, deleted, enabled, disabled, edited, and run manually. Retention periods for task records and logs are configurable, which helps control storage use. DingTalk group bots and ServerChan can send notifications after a task succeeds or fails. The README does not document a rollback operation, retry policy, or a formal API for these controls.

Installing TaoSync and Creating a First Storage Configuration

The README points users to the GitHub releases and Docker Hub for obtaining TaoSync, but it does not give a complete installation command or a first-login procedure. The repository contains a Docker image definition. Its final image declares the data volume, runtime environment, exposed port, and default command:

FROM dr34m/tao-sync:not-for-use-alpine
VOLUME /app/data
WORKDIR /app
COPY --from=builder /app/dist/taoSync /app/
ENV TAO_PORT=8023 TAO_EXPIRES=2 TAO_LOG_LEVEL=1 TAO_CONSOLE_LEVEL=2 TAO_LOG_SAVE=7 TAO_TASK_SAVE=0 TAO_TASK_TIMEOUT=72 TZ=Asia/Shanghai
EXPOSE 8023
CMD ["./taoSync"]

This file shows that the executable is run as `./taoSync`, stores persistent data under `/app/data`, and uses port `8023` in the image configuration. The documented Docker image is available through the repository's Docker Hub link. The README does not provide the exact `docker run` or Compose command, so this article does not invent one.

For a first real use, obtain the release or image from those project locations, start it using the deployment method supplied with that distribution, and open the configured service on port `8023`. On first startup, the built-in `TaoSync` engine should appear automatically with no directories. Add an absolute local path through its directory manager, configure a job, and run the job manually before enabling a schedule. For Docker, mount the host directory into the container first. The README does not state the exact web route, default password, or API request needed to create the first job.

Operational Limits and Security Boundaries

The most explicit operational warning is that TaoSync should not be exposed directly to the public internet. The README says the project includes security measures but cannot guarantee absolute security. If external access is necessary, it recommends a strong password and `SSL`. That boundary matters because TaoSync manages storage credentials and can move files between network endpoints. The README also says login passwords are stored in the database using a one-way hash, while an initial password supplied through configuration or an environment variable must be protected carefully.

The built-in engine reduces the need to run OpenList, but it does not eliminate deployment responsibilities. Local paths must be visible to the process, and Docker users must arrange volume mounts. SMB discovery can scan private IPv4 `/24` networks for hosts accepting TCP 445, which may be undesirable where network discovery is restricted. FTP requires `MLSD`, so an older or non-compliant FTP server may not work. The README does not specify retries, resumable transfers, conflict prompts, or behavior when a destination becomes unavailable mid-task.

TaoSync is therefore a poor fit for an unattended internet-facing control plane without an external security layer. It is also a questionable choice when deletion semantics must be proven before Full sync or Move mode is enabled. The README does not describe a dry-run report, an approval gate, or a rollback command, so those checks cannot be assumed.

TaoSync Compared With Direct OpenList and AList Use

The practical alternative is using OpenList or AList directly as the storage interface and scheduling transfers with separate scripts or another automation system. That approach keeps the storage layer and synchronization policy separate. It can be easier to inspect when an engineer already has established scripts, but it requires implementing scheduling, progress reporting, exclusions, file-size rules, notifications, and task retention separately.

TaoSync takes a different approach by combining a browser interface, job management, scheduling, a built-in engine, and optional external OpenList and AList engines in one application. Its Source Directory Mode and managed task history are project-specific features that a direct storage listing does not provide automatically. The trade-off is that synchronization behavior is mediated by TaoSync and its database, while the README does not document all conflict, deletion, or retry semantics.

For a simple one-off copy, direct filesystem tools or a storage provider's native transfer command may require less configuration. TaoSync becomes more relevant when the same policy must run repeatedly across several endpoints, with schedules and failure notifications. The choice depends on whether an operator prefers a managed control plane or separate, fully visible scripts.

Maintenance, Packaging, and AGPL-3.0 Obligations

The repository is not archived, and its last push was on 2026-07-28. The listed releases include v0.4.0 on 2026-07-16, v0.3.2 on 2025-07-28, and v0.3.1 on 2025-06-14. That record shows releases in 2025 and 2026, but the README's maintenance claims should not be treated as a guarantee of compatibility for every OpenList or AList deployment.

The repository includes GitHub Actions build configuration, a `Dockerfile`, a PyInstaller specification, and packaged runtime dependencies in `requirements.txt`. The requirements file identifies a Python 3.11 runtime dependency set, including `APScheduler`, `paramiko`, `smbprotocol`, `PyYAML`, `tornado`, and `requests`. The README states that executables are built and released through GitHub Actions. It does not document an upgrade migration procedure, rollback procedure, or compatibility policy for existing task databases.

TaoSync is licensed under AGPL-3.0. That matters for organizations considering modification, network deployment, or distribution. The license text should be reviewed for the specific way the application is used and modified. This review is a licensing check, not legal advice. Upgrades also require attention to the `/app/data` volume because the Docker image declares it as persistent storage.

Editorial conclusion

Adopt TaoSync when you need scheduled file synchronization through its built-in engine or an external OpenList or AList instance. Do not expose it directly to the public internet, and do not treat it as a general-purpose backup replacement without verifying destination behavior, exclusions, retention, and credential handling. Review the AGPL-3.0 obligations and inspect the exact storage endpoints and Docker volume mapping before storing important files.

Frequently asked questions

Official sources

1. dr34m-cn/taosync on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases