PaperPilot представив локальний PDF-рушій на Rust із підтримкою WASM і MCP
PaperPilot об’єднує локальні інструменти для роботи з PDF: браузерний рушій на WASM, CLI, десктопний застосунок, REST API та MCP-сервер. У версії v0.6 доступні операції зі сторінками, стиснення й витягування тексту.
26 жовтня 2026 року на Hacker News з’явився матеріал про PaperPilot — набір інструментів для роботи з PDF на Rust. Проєкт дає змогу обробляти документи локально: у браузері, через командний рядок, десктопний застосунок, REST API або MCP-сервер для ШІ-інструментів. Дату випуску самого рушія в матеріалі не вказано.
Один рушій для кількох способів роботи
В основі PaperPilot — спільне ядро, яке використовують різні інтерфейси. Браузерна версія працює через WebAssembly. Згідно з описом проєкту, документи обробляються в пам’яті вкладки, без надсилання файлів на сервер. Для роботи поза браузером є десктопний застосунок на Tauri та Svelte: у ньому можна переглядати документи, робити розмітку й порівнювати їх.
Розробникам доступні CLI для пакетних операцій і локальний REST API. API можна запустити на порту 7823 і викликати з Python, Node або n8n. Є також MCP-сервер для підключення до сумісних клієнтів. Серед перелічених у проєкті — Codex, Claude Code, Claude Desktop і Cursor. Щоб клієнт отримав доступ до операцій із PDF, локальний сервер потрібно додати до його конфігурації.
Автори зазначають, що рушію не потрібні Chromium, середовище виконання C++ і звернення до хмарних сервісів. Community Edition поширюється за ліцензією Apache 2.0: до неї входять CLI, MCP-сервер, REST-шлюз, WASM-рушій і десктопний застосунок. Окремо розробляють Enterprise Edition із SSO, керуванням доступом на основі ролей, журналами аудиту та DLP. Ці можливості не варто плутати зі складом відкритої версії.
Можливості v0.6 і дорожня карта
У версії v0.6 можна об’єднувати й розділяти PDF, змінювати порядок сторінок, видаляти, витягувати та повертати їх. Також заявлено підготовку буклетів, розміщення кількох сторінок на одному аркуші та стиснення. Для отримання вмісту передбачено витягування звичайного тексту й OCR; розпізнавання описано як реалізацію PaddleOCR на Rust через rten.
До переліку інших функцій входять водяні знаки, перевірка й видалення підписів, пошук персональних даних і глибоке очищення документа. Для даних з Excel передбачено перетворення на JSON або CSV. Це перелік можливостей проєкту, а не результат перевірки на різних документах: відомостей про те, як інструменти працюють із конкретними файлами, у матеріалі немає.
Наступні етапи поки що зазначені в дорожній карті. У v0.7 заплановано перетворення між PDF і Markdown, HTML або JSON; у v0.8 — перетворення PDF на Word, Excel і PowerPoint. Для v0.9 заплановано шифрування й розшифрування, підписання, незворотне приховування фрагментів документа, роботу з формами та анотації. Для v1.0 перелічено рендеринг, зведення шарів, виправлення документів, порівняння, PDF/A й нумерацію Бейтса. Дат виходу цих версій немає: заплановані функції не можна вважати доступними у v0.6.
Проєкт можна зібрати з вихідного коду; готовий виконуваний файл MCP-сервера пропонують завантажити з Releases. Для збирання потрібні Rust 1.75+, Node.js і pnpm. У репозиторії також передбачено запуск тестів продуктивності та згадано окремий звіт із методикою й результатами. У представленому матеріалі немає чисел, за якими можна було б порівняти PaperPilot з іншим інструментом.
Практичні сценарії для сайтів і команд
Один зі сценаріїв для сайту — дати відвідувачеві змогу об’єднати або стиснути PDF, не надсилаючи документ на сервер. У проєкті наведено код для вбудовування віджета з об’єднанням, стисненням і OCR. Якщо такий інструмент потрібен на сторінці, важливо розрізняти заявлений принцип роботи браузерного рушія та поведінку конкретного вбудованого рішення після підключення.
Для команди, яка готує матеріали до публікації, стануть у пригоді операції з поточної версії: стиснути файл, об’єднати кілька PDF в один або витягти текст. Розробник може автоматизувати повторювані дії через CLI або підключити їх до локального процесу через REST API чи MCP. Якщо потрібно перетворити PDF на Markdown або Word, наразі йдеться про дорожню карту, а не про готову функцію.
Мій погляд
Мені ближчий браузерний варіант: для звичайної сторінки я б віддав перевагу зрозумілому рішенню без окремої обробки на сервері, якщо потрібно виконати лише кілька дій із PDF. Але перед підключенням я б перевірив на власних файлах результат обробки, завантаження сторінки й обсяг доданого коду. У матеріалі немає даних, які дали б змогу оцінити це заздалегідь.
Я б обирав між віджетом, CLI й локальним API залежно від конкретного завдання, а не підключав усе одразу. MCP корисний там, де операції з документами вже потрібні сумісному клієнту. Для невеликої сторінки це не обов’язкова частина рішення; функції з дорожньої карти я б до їхнього виходу не враховував.
Джерела
Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.
Початківець фронтенд-розробник
Вивчаю основи JavaScript і у вільний час створюю невеликі сторінки. Насамперед звертаю увагу на зрозумілість коду й швидкість завантаження.
Усі публікації автораСхожі статті
Представлено Proa — Rust-фреймворк із серверним рендерингом і виведенням у різних форматах
На Hacker News представили Proa — вебфреймворк на Rust для серверного рендерингу та виведення компонентів у HTML і Markdown. Автори пропонують випробувати його на одному маршруті чинного проєкту.
Bez генерує браузерний рушій за вебспецифікаціями й тестами
Bez створює браузерний рушій за вебспецифікаціями, звіряючи результат із Chromium, Firefox і WebKit. Проєкт поки на ранній стадії, а опубліковані показники не означають готовності рушія.
У $mol додали підтримку Node.js для зберігання даних і нові інструменти інтерфейсу
В огляді змін $mol і Giper Dev за серпень та вересень — підтримка Node.js у $mol_storage, нові можливості редактора й інструменти інтерфейсу. Розповідаємо, що варто перевірити розробникам.
Обговорення 5
Тьягу Урсу
у нас для локального прототипа обработки PDF хватило браузерного WASM: файлы не уходили на сервер, а интеграция в интерфейс была проще, чем поднимать отдельный API. интересно проверить, насколько PaperPilot удобен для пакетных задач через CLI
Клара Новотна
але «лише браузерний WASM» швидко закінчується, коли з’являються пакетні задачі й інтеграції: тоді CLI або локальний API — не зайва складність, а наступний прототип; інакше ручні операції теж доведеться масштабувати руками
Павел Ковальський
@klara.novotna тут, здається, трохи змішалися різні масштаби задач. Для прототипу з невеликим потоком файлів браузерного WASM цілком може вистачити, а пакетні операції не обов’язково одразу тягнуть за собою API чи CLI — іноді достатньо простого сценарію в браузері. У PaperPilot CLI справді є, але разом із ним з’являється окремий спосіб запуску й підтримки; я б додавав його, коли повторювані ручні кроки вже реально стали вузьким місцем, а не наперед.
Павел Новак
CLI не обов’язково запускати в продакшн: спершу можна дати йому пару повторюваних пакетів — хай покаже, чи ручні кроки вже просять автоматизації.
Олівер Лопеш
У схожих задачах ми спершу ганяли кілька повторюваних пакетів через браузерний WASM, а потім виявилося, що час з’їдає не обробка PDF, а ручне завантаження й перевірка результатів. Тоді CLI справді став наступним кроком; профайлер, звісно, підказав би не все — інколи вузьке місце сидить між клавіатурою та кріслом.