SnapOtter：你的文件处理工作站，在家里也能跑

痛点场景：被在线工具绑架的那些年

你有没有过这样的经历：想压缩一张照片，打开某个在线网站，结果要你注册账号；想把 PDF 转成 Word，某个网站告诉你每天只能免费转换两次；想给视频加字幕，找了半天不是要充钱就是要把文件上传到别人服务器。

更让人不安的是，你根本不知道那些网站把文件上传到哪里去了。也许是云端某台服务器，也许几天后才删除，也许根本没有删除。

SnapOtter 就是来解决这个问题的——一个完全自托管的文件工具箱，157 个工具，覆盖图片、视频、音频、文档、数据五种媒体格式，所有处理都在你自己的硬件上完成。

项目起源：一个极客想让文件永远属于自己

SnapOtter 由独立开发者 snapotter-hq 团队构建，2026 年 3 月底在 GitHub 开源，不到三个月就积累了 1732 颗星。它的诞生背景很有意思——团队本身是做 SaaS 工具的，但越来越无法接受把用户文件上传到第三方服务器这件事。

开源版其实是他们商业产品的技术降级版：保留了所有核心处理引擎，但把云端依赖去掉，换成了本地 Docker 部署模式。这种"先私有化再开源"的路径，让它从第一天起就具备生产级稳定性。

157 个工具，这是不是一个瑞士军刀？

严格来说，SnapOtter 更像一套可编程的数字车间，而不只是瑞士军刀。它分为五个模块：

图片工具（64个）：最成熟的部分。包括常规的 resize、crop、compress、convert、watermark、color adjust，以及高级功能如截图美化（beautify screenshots）、生成表情包（meme generator）、矢量化（vectorize）、找重复图片、证件照自动排版。支持 55+ 输入格式（包含 23 种 RAW 格式）和 14 种输出格式。

视频工具（29个）：convert、compress、trim、resize、crop、merge、video-to-GIF、提取音频、去抖动、调帧率（change FPS）、烧录字幕、提取字幕。视频处理底层依赖 FFmpeg 的静态构建版本，多架构支持（amd64/arm64）。

音频工具（17个）：convert、trim、normalize、volume、fade、pitch shift、去静音、降噪、merge/split、波形图生成。

文档/PDF 工具（37个）：merge、split、compress、格式转换（Word/Excel/PowerPoint/EPUB）、加密/解密、涂黑敏感信息（redact）、加水印、加页码、OCR 文字识别。这部分用到了 PDFCPU（Go 语言实现的纯静态 PDF 工具库，无 CGO 依赖）和 mupdf（底层 PDF 渲染引擎）。

数据工具（10个）：CSV/JSON/XML/YAML 互转、CSV merge/split、图表生成、ZIP 压缩/解压。

本地 AI：不用联网，照片也能修复

这是 SnapOtter 最亮眼的特性之一。所有 AI 功能都运行在本地硬件上：

• 抠图（Remove Background）：用 Sharp + WASM 版 ZXing 配合自研算法，不需要云端 API
• 图片放大（Upscale）：本地推理
• 老照片修复与上色：本地模型
• 物体擦除（Erase Objects）：Inpaint 风格
• 人脸模糊与增强
• OCR：从图片和 PDF 中提取文字，底层用 mupdf 渲染 PDF + 自研识别
• 音频转录：本地 Whisper 模型
• 视频字幕自动生成：先用 Whisper 转录，再烧录进视频
• 扩展画布（Expand Canvas）：AI 填充边缘

v2.0 还在修复本地 AI 安装的最后一个问题，官方公告说 v2.0 即将发布，届时 AI 工具会从现在的 10 个左右扩展到覆盖上述全场景。

架构解析：一个 Turbo monorepo 的工程实践

SnapOtter 采用了 pnpm workspace + Turbo monorepo 结构，这在 TypeScript 开源项目中属于比较"重"的工程化选择，但考虑到它有 5 个 App 和 6 个 Package，这种架构完全合理。

apps/api：Fastify 5 驱动的后端 API，是整个系统的核心。集成了：

• BullMQ：任务队列，基于 Redis，支持高并发任务调度
• Drizzle ORM：TypeScript 原生 ORM，对接 PostgreSQL 17
• OpenTelemetry：全链路追踪（Instrumentation for Fastify、HTTP、ioredis、pg）
• Sentry：Node.js 错误追踪
• PostHog：产品分析（可关闭）
• OpenAPI/Scalar：交互式 API 文档

apps/web：Vite + React 构建的前端 UI，提供浏览器端操作界面。处理层在用户本机，但上传后由 API 端处理。

packages/ai：AI 工具封装，目前主要依赖 Sharp（libvips 绑定）进行图片处理，以及 WASM 版 ZXing。

packages/image-engine：图片处理引擎，依赖 Sharp 和 exif-reader。

packages/media-engine：音视频处理引擎，依赖 FFmpeg。

packages/shared：跨包共享类型和国际化资源（i18n，支持 21 种语言）。

Dockerfile 架构：多阶段构建，第一阶段编译 React 前端，第二阶段运行 Node.js API。FFmpeg 通过 mwader/static-ffmpeg 镜像引入，PDFCPU 在构建时用 Go 1.25 编译成纯静态二进制文件（无 CGO），最终镜像对 amd64 和 arm64 均可运行。

部署体验：十分钟内跑起来

这大概是 SnapOtter 最友好的部分了。只需要：

docker compose up -d

三秒钟后，你就有了：

• SnapOtter 应用（端口 1349）
• PostgreSQL 17 数据库
• Redis 8 缓存

然后浏览器打开 http://localhost:1349，用 admin/admin 登录。

想跑 AI 功能？用 GPU 版本的 compose 文件：

docker compose -f docker-compose-gpu.yml up -d

硬件方面，CPU 模式完全可用，GPU 模式可选（NVIDIA CUDA 或 Intel/AMD VAAPI 加速）。内存建议 2GB+（AI 推理建议 4GB+），磁盘 5GB+（含预下载 AI 模型）。

局限与争议

文件大小限制：README 中没有明确说明单文件大小上限，.env.example 里 MAX_UPLOAD_SIZE_MB=0（0=不限）但实际取决于服务器配置。

AI 能力待验证：v2.0 尚未正式发布，本地 AI 功能还在修复中。当前 latest 镜像只包含图片工具，非全功能版本。

AGPLv3 许可证：这意味着如果修改源码再分发，必须开源。但如果是自用部署，不受影响。商业场景建议咨询法律意见。

非 ARM 树莓派优化：虽然官方说支持 ARM64，但 AI 推理在树莓派上可能较慢，内存是主要瓶颈。

行业意义：隐私优先工具的崛起

SnapOtter 代表了一种趋势：把原本属于在线 SaaS 的能力，下沉到本地自托管。类似 PhotoPrism、Nextcloud Mail、LibrePhotos 等项目都在做这件事。SnapOtter 的差异化在于工具数量（157 个 v2.0）和对专业用户（RAW 格式、OCR、专业 PDF 操作）的覆盖。

对于 homelab 玩家和注重隐私的个人用户，SnapOtter 是目前最完整的文件处理解决方案之一。开源且无外部依赖，文件永远在自己的硬盘里。