copyparty: один скрипт вместо пяти серверов

Сценарий, знакомый каждому, кто хоть раз пересылал файлы самому себе: вложение в email упирается в лимит 25 МБ, облако требует загрузить, подождать, потом скачать с другого устройства. Автор copyparty, норвежский инженер под ником 9001, решил эту проблему радикально — написал файловый сервер, который помещается в один Python-скрипт и запускается одной командой.

python3 copyparty-sfx.py — и текущая директория уже доступна по HTTP на порту 3923. Терминал печатает IP-адрес и QR-код: наводишь камеру телефона, открываешь страницу и перетаскиваешь файлы. Всё это работает на любом устройстве с Python, включая Raspberry Pi.

Что делает один скрипт

Вместо того чтобы поднимать отдельные демоны для каждого протокола, copyparty обслуживает HTTP/HTTPS, WebDAV, SFTP, FTP/FTPS, TFTP, SMB/CIFS и WOPI из одного процесса. Плюс zeroconf-объявление сервисов в локальной сети — устройства видят сервер без ручной настройки. Один скрипт заменяет пять отдельных серверов, и это главное архитектурное решение проекта.

Ключевой механизм — протокол загрузки up2k. Файл передаётся чанками с хеш-проверкой каждого фрагмента. Если соединение обрывается, сервер не начинает передачу заново: он запрашивает только недостающие куски. Ограничения на размер файла нет, и разработчик утверждает, что загрузка через Cloudflare, который обычно жёстко лимитирует размер передач, тоже проходит без проблем.

С up2k связана дедупликация: если загрузить на сервер файл, который там уже есть, операция завершится мгновенно — идентичные файлы заменяются симлинками, а не хранятся повторно. Правда, для этого нужно включить индексирование файлов.

Производительность заявлена серьёзная: около 8 GiB/s на скачивание и 1 GiB/s на загрузку при настройках по умолчанию. SFTP заметно медленнее — примерно 700 MiB/s. Если скорость критична, выбор протокола имеет значение.

Есть и необычные функции, которых нет у конкурентов. «Race the beam» позволяет скачивать файл, пока он ещё загружается на сервер. Write-only папки дают внешним сторонам возможность загружать файлы, не видя содержимое директории — практичный сценарий для приёма документов от клиентов. Self-destruct загрузок задаёт файлам срок жизни, после которого сервер их удаляет.

Где это ломается

Простота запуска обманчива. Для постоянного использования нужно разобраться в конфигурации: учётные данные хранятся в открытом текстовом конфиг-файле, веб-панели администрирования аккаунтов нет. При масштабировании на множество пользователей это становится реальной проблемой — все изменения вносятся вручную.

SMB-сервер в README прямо помечен как «unsafe, slow, not recommended for wan». Это не скрытый недостаток, а задокументированное ограничение: функция существует, но автор сам предупреждает, что для интернет-использования она не годится.

Напряжение между простотой и сложностью — главная особенность проекта. Одна команда для запуска, но огромный список флагов, плагинов и опций для полноценного использования. Обзор Wares.gg формулирует это прямо: «Many features means a lot of configuration to learn».

Показательна честность автора о нестабильности. В README есть раздел «feature chickenbits/beefybits» — флаги для отключения багованных функций и принудительного включения функций с известными проблемами. Список известных багов отсортирован «примерно по вероятности столкновения». Автор не притворяется, что проект отполирован.

Для выхода в интернет потребуется reverse-proxy, ручная настройка аккаунтов и осознание, что пароли лежат открытым текстом. «Простота одной команды» — это про запуск, а не про долгосрочную эксплуатацию.

Практическая ниша

Сравнение с конкурентами проясняет позицию copyparty. File Browser архивирован в 2026 году. nextExplorer — только веб-интерфейс с SSO. SFTPGo ориентирован на управляемый SFTP и облачные хранилища. Nextcloud — полный облачный пакет, который на Raspberry Pi с PHP-стеком работает с трудом. copyparty на том же Raspberry Pi работает без проблем.

Облачная совместимость тоже выделяет проект: отсутствие лимита размера файла сохраняется даже через Cloudflare, который обычно ограничивает загрузки. FUSE-монтирование позволяет примонтировать удалённый copyparty как локальную файловую систему (read-only) — мост между веб-интерфейсом и классическим файловым доступом.

Но границы применимости чёткие. copyparty — не замена Plex или Jellyfin для серьёзного управления медиатекой, хотя медиаплеер с транскодированием встроен. Это не облако с синхронизацией клиентов. И это не решение для строгой безопасности в интернете без дополнительной обвязки.

Прозрачность как следствие модели разработки

Проект ведёт один человек. ~43 500 звёзд на GitHub, 4 553 коммита, активная разработка. README содержит разделы «not my bugs», честное сравнение с конкурентами в versus.md, ироничный GDPR-раздел «imagine using copyparty professionally...» и «Server hall of fame» — список неожиданных устройств, на которых пользователи запускают сервер.

Это не маркетинговая полировка, а инженерная честность. Автор документирует слабости, потому что не продаёт продукт, а публикует инструмент. Следствие для пользователя: документации можно доверять, но не стоит ждать, что проект превратится в «продукт» с поддержкой и SLA. Это хобби-инструмент, доросший до массового использования.

Когда copyparty — правильный выбор

copyparty — наиболее практичное решение для сценария «нужен файловый сервер здесь и сейчас» на любом устройстве с Python. Он занимает нишу между «просто поднять HTTP-сервер» и «развернуть Nextcloud»: мультипротокольность в одном процессе вместо нескольких демонов, устойчивые к обрывам загрузки, дедупликация.

Но это не панацея. Для интернет-экспозиции нужен reverse-proxy и понимание рисков. Для множества пользователей — ручное управление конфигом. Для медиаменеджмента — другой инструмент. copyparty решает конкретную задачу — переслать файл — и решает её лучше большинства альтернатив. Всё остальное — за рамками его ниши.