quark-auto-save: scheduled Quark Drive transfers with regex renaming

The chore quark-auto-save was built to remove

Some Quark Drive shares keep getting new episodes or new files. The README states the problem plainly: for a resource that keeps updating, going back to re-save it every so often is a nuisance. quark-auto-save is the scheduled replacement for that manual loop. It is aimed at people who already keep a media server and a cloud-drive workflow, not at casual users who occasionally save a single file. The feature list covers the whole chain: check-in for storage space, automatic re-saving of a share link, filename cleanup with regular expressions, push notifications, and a media-library refresh. The README also positions it next to SmartStrm and OpenList as the pieces that, combined with Emby, produce an automatic catch-up effect for ongoing series. The intended user is therefore someone comfortable with Docker, a config volume, and writing a regex. If you want a one-click consumer app, this is the wrong shape of tool.

How the scheduled transfer and rename pipeline works

The repository layout is small and readable. quark_auto_save.py sits at the top level, the Flask application lives under app/, notification code is in notify.py, and optional integrations are directories under plugins/. The Dockerfile builds on python:3.13-alpine, copies the repository into /app, installs requirements.txt, writes build.json from the BUILD_SHA and BUILD_TAG arguments, runs app/_clean_plugins.py once, and starts the service with python ./app/run.py on port 5005. The dependency list is five packages: flask, apscheduler, requests, treelib and natsort. That tells you the shape of the thing: Flask serves the WebUI, APScheduler drives the periodic jobs, requests talks to Quark, and treelib plus natsort handle the file tree and natural ordering of names. The data flow per task is: read the share link, walk into a subdirectory of the share if one is configured, apply a regex filter to decide which filenames to save, save them into a target directory that is created if missing, then apply a second regex as a replacement to rename what landed. Files already saved are skipped, and dead share links are recorded and skipped on later runs. Renaming is the part worth reading the Wiki for: the README shows a table of pattern and replace pairs, and notes that a pattern beginning with $ and an empty replacement triggers a preset, which the project calls magic matching, while curly braces mark magic variables such as {TASKNAME}. Task-level controls include an end date after which a task stops running, and per-subtask weekday scheduling.

Docker install and a first transfer task

The README gives a single docker run command. The environment variables WEBUI_USERNAME and WEBUI_PASSWORD set the admin credentials, the config volume is marked as required for persistence, and the media volume is optional and used by the alist_strm_gen module for generated .strm files. The published port is 5005, and the README notes that only the part before the colon may be changed.

docker run -d \
  --name quark-auto-save \
  -p 5005:5005 \
  -e WEBUI_USERNAME=admin \
  -e WEBUI_PASSWORD=admin123 \
  -v ./quark-auto-save/config:/app/config \
  -v ./quark-auto-save/media:/media \
  --network bridge \
  --restart unless-stopped \
  cp0204/quark-auto-save:latest

If you prefer Compose, the README ships an equivalent file. The image, port, restart policy and the two volumes match the run command above, so pick one and do not run both.

name: quark-auto-save
services:
  quark-auto-save:
    image: cp0204/quark-auto-save:latest
    container_name: quark-auto-save
    network_mode: bridge
    ports:
      - 5005:5005
    restart: unless-stopped
    environment:
      WEBUI_USERNAME: "admin"
      WEBUI_PASSWORD: "admin123"
    volumes:
      - ./quark-auto-save/config:/app/config
      - ./quark-auto-save/media:/media

After the container is up, open http://yourhost:5005 and log in with the credentials you passed. The README documents five environment variables: WEBUI_USERNAME, WEBUI_PASSWORD, PORT, PLUGIN_FLAGS and TASK_TIMEOUT, the last defaulting to 1800 seconds and ending a task that overruns. PLUGIN_FLAGS takes values such as -emby,-aria2 to disable individual plugins. For the first task, create one in the WebUI with a share link and a target directory, and set the filter and rename regex. The README's own example table is the safest starting point: the pattern .*\.mp4$ with an empty replacement saves only .mp4 files and renames nothing, and the pair ^(\d+)\.mp4 with S02E\1.mp4 turns 01.mp4 into S02E01.mp4. Run it once and read the log before you put it on a timer. Updates are done by pulling the image; the README offers watchtower for that.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower -cR quark-auto-save

Where quark-auto-save breaks or does not fit

The README carries a caution banner that is unusual in how direct it is: resources do not update every moment, and setting an overly high schedule frequency is forbidden, because of account risk control and load on Quark's servers. That is a real design constraint, not a footnote. A tight cron interval is the fastest way to get the account flagged, and the project explicitly refuses to protect you from that choice. There is also no rollback story in the README. If a rename regex is wrong, the files have already been renamed in the target directory, and nothing in the documented material describes undoing a task run. Test a regex on one folder before applying it broadly. The same caution applies to the account model: the feature list says multiple accounts are supported, but only the first account performs transfers, so multi-account does not mean parallel transfers. Finally, the README states that the developer is not customer support and that the Wiki is the first place to look. If you need a vendor to answer within a day, this project is not that. It is also a poor fit if the share you care about is a one-off: a scheduled task adds moving parts for no benefit when a manual save would do.

quark-auto-save against a generic cron plus CLI script

The obvious alternative is a shell script that calls a Quark CLI on a cron schedule. The difference is where the logic lives. A cron script gives you full control and no WebUI, but you write the file-tree walk, the skip-if-already-saved check, the natural sort, the regex pipeline and the notification fan-out yourself. quark-auto-save packages exactly those pieces: treelib and natsort in requirements.txt exist because the project sorts and traverses the share tree, and the plugin directory exists so that a media-library refresh or a .strm generation step is a module rather than a line in your script. The trade is that you inherit its scheduling model and its caution about frequency, and you configure through the WebUI instead of editing a file. Within the same ecosystem, the README names SmartStrm and OpenList as the companions for turning the saved files into something Emby can read; those handle the library side, while quark-auto-save handles the transfer and rename side. If you already run OpenList, the question is whether you want this tool's task and regex layer in front of it or your own.

Maintenance cost, licence and the update path

The repository is not archived, and the last push was on 2026-07-09, the same day as the v0.8.7 release. Releases are spaced out rather than weekly: v0.8.5 on 2026-04-18, v0.8.6 on 2026-04-29, v0.8.7 on 2026-07-09. Plan for a handful of updates a year, not a stream. Upgrading is a container image pull, and the README's watchtower command automates it, but that command mounts the Docker socket, which is a meaningful privilege to hand to any container. Running watchtower by hand when you decide to update avoids that. Configuration lives in the /app/config volume, so keep it backed up before an update; the README marks that volume as required for persistence but does not document a migration step between versions. The project is licensed AGPL-3.0. If you run it as a network service, that licence carries source-availability obligations that differ from permissive licences, and if you modify and redistribute it those obligations extend further. This is a description of the licence, not legal advice; read the LICENSE file in the repository and talk to a lawyer if you plan to build on it commercially.

Editorial conclusion

Adopt quark-auto-save if you already run Docker and want an updating Quark share re-saved and renamed without touching it, and you accept that the project's own README warns against frequent schedules. Do not adopt it if you need a documented rollback path, a stable public API, or support beyond the Wiki and Issues. Before trusting it with a library, verify three things on your own instance: that your Quark account survives the check-in and transfer calls, that your regex pair produces the filenames you expect on one known folder, and that the plugin flags you need are actually enabled in your container.

Frequently asked questions

Official sources

1. Cp0204/quark-auto-save on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases