Montscan: FTP-to-WebDAV Scan Naming with Ollama Vision Models

The filing problem Montscan is built around

A network scanner produces files with names like scan_20260824_0001.pdf. Someone then has to open each one, work out what it is, and rename it before it goes into a document store. Montscan's premise is that the scanner already knows how to push a file somewhere, so the tool only has to sit at the receiving end, read the page, and produce the name.

The README describes the target plainly: receives documents from network scanners via FTP or a polled SMB share, analyses them with Ollama vision models, generates date-aware filenames, and delivers the result to WebDAV or an SMB share. That is a narrow job done end to end, and the narrowness is the point. It is not a document management system, not an OCR pipeline for search indexing, and not a scanner driver.

The intended user is someone running a home or small-office stack who already has Ollama available, most likely because they run other local models, and who wants scans to land in Nextcloud with a readable name instead of a serial number. The README's own framing is worth repeating: it says the project is not fully production-ready and is in active development, but is fairly usable. The last push to the repository was on 2026-08-24, and the most recent release, v1.3.2, carries the same date.

Ingress, vision pass, egress: how a scan moves through Montscan

Three ingress paths exist and at least one must be enabled. The FTP server listens on a bind address and port and writes received files into a local upload directory. The Samba ingress polls a remote SMB share at a configurable interval and can delete the source file after reading it. The folder watcher polls a local directory, which is the path to use when the scanner already writes to a share mounted on the same machine.

Whatever the source, the file reaches a local staging directory. Because the pipeline is built around PDFs, Montscan needs a converter to turn pages into images the vision model can read. The prerequisites list Poppler (pdftoppm) or ImageMagick for exactly this step, and the Dockerfile installs poppler-utils into the runtime image. On a bare-metal install you supply that yourself.

The image then goes to the Ollama endpoint named by OLLAMA_HOST, using the model named by OLLAMA_MODEL. The model returns text, and a second pass turns that text into a filename, with LANGUAGE controlling the language of the generated name. The result is delivered by an egress provider: WebDAV upload to a base URL and remote path, or SMB upload to a share and path. The folder watcher doubles as an egress when FOLDER_OUTPUT_DIR is set, moving the renamed file to an output directory, or renames in place when it is not.

The architecture is deliberately flat. There is no queue, no database, and no retry ledger visible in the configuration surface. If the Ollama endpoint is down when a file arrives, the failure mode is whatever the agent loop does with an error, and the README's troubleshooting section is where you would look. That is a reasonable design for a single-user tool and a thin one for anything with volume.

Installing Montscan and naming your first scan

The README gives a local build path. You need Go 1.24 or later according to the prerequisites, though go.mod declares go 1.25.0, so treat the module file as the stricter requirement. Clone, then build:

git clone https://github.com/sh4den/Montscan.git
cd Montscan
go build -o montscan .

The build produces a single montscan binary in the repository root. Next, install the PDF-to-image dependency and pull a vision model. The README suggests llava, and .env.example ships with a different default, gemma4:26b-a4b-it-qat, so pick one deliberately rather than inheriting either.

sudo apt-get install poppler-utils
ollama pull llava

Configuration is entirely environment variables. The repository includes .env.example, and the README's local run instructions copy it, edit it, and export it before starting the binary:

cp .env.example .env
# edit .env with your values
export $(grep -v '^#' .env | xargs)
./montscan

The smallest useful setup is the folder watcher, because it needs no FTP server and no remote share. Point it at a directory, leave FOLDER_OUTPUT_DIR unset to rename in place, and turn the FTP ingress off so nothing else is listening:

FOLDER_ENABLED=true
FOLDER_INPUT_DIR=/mnt/scanner
# FOLDER_OUTPUT_DIR not set → rename in place
FTP_ENABLED=false

Drop a PDF into /mnt/scanner and the watcher should pick it up within FOLDER_POLL_INTERVAL_SEC seconds (default 5), send the page images to Ollama, and rename the file. If nothing happens, check that Ollama is reachable at OLLAMA_HOST (default http://localhost:11434) and that pdftoppm is on PATH.

For the Docker route, docker-compose.yml publishes ports 21 and 21000-21010 for the FTP server and defines an Ollama service that pulls OLLAMA_MODEL on startup. Note the credentials baked into the compose file: FTP_USERNAME defaults to scanner and FTP_PASSWORD to scanner123. Those defaults exist so the stack starts without configuration, and they should not survive contact with a network you do not control.

Where Montscan breaks down

The honest limitation is the one the README states: the project is not fully production-ready. The 97.5% success rate it cites comes from a small test set of 1000 documents, and the README does not define what counts as a success, nor what the document mix was. Naming accuracy on clean printed invoices is a different problem from accuracy on handwritten notes or faxed forms, and you cannot infer which one the number reflects.

Beyond that, the design has structural soft spots. The vision pass sends page images to an Ollama endpoint. If that endpoint is remote, your documents leave the machine, and nothing in the configuration surface suggests a redaction or region-restriction step. For medical, legal or financial scans, that is a decision to make before deployment, not after.

PDF conversion is an external dependency, not a bundled library. A host without Poppler or ImageMagick will fail at the conversion step, and the failure will look like an AI problem rather than a missing binary.

The FTP ingress is another boundary. The compose file maps port 21 and a range of passive ports, and the default credentials are published in the repository. Running that on a shared network without changing FTP_USERNAME and FTP_PASSWORD is the kind of mistake that is easy to make because the stack works fine either way.

Finally, the naming model is whatever you configure. A small vision model will produce plausible but wrong filenames on dense pages, and there is no confidence score or review queue described in the README. You get the name the model produced.

How Montscan differs from Paperless-ngx and similar tools

Paperless-ngx is the obvious comparison for anyone filing scanned documents, and the difference is in what each one owns. Paperless-ngx is a document management system: it ingests, stores originals, runs OCR to make text searchable, applies tags and correspondents, and gives you a web interface to browse the archive. Its OCR step is about extracting text for search, and its naming and metadata are driven by rules and by what it can match.

Montscan does none of that. It has no archive, no search index, no web interface. It reads a page with a vision model, which means it can work from layout and appearance rather than from a text layer, and it produces a filename and hands the file to WebDAV or SMB. Your Nextcloud or ownCloud instance is the archive, and its search is whatever that server provides.

The practical consequence is that Montscan is a pipe and Paperless-ngx is a destination. If you want to search the contents of your scans years later, Montscan alone will not give you that, because it does not persist extracted text as far as the documentation describes. If you already have a Nextcloud library and just want files to arrive with sensible names, Montscan is the smaller thing to run. The two are not mutually exclusive: you could point Montscan's WebDAV egress at a folder that Paperless-ngx consumes, though that is a composition the README does not discuss.

Licence, upgrades and the cost of running this

Montscan is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with it. The LICENSE file sits at the top level of the repository. This is a description of the licence, not legal advice; if you are embedding it in a product, read the file yourself.

The upgrade surface is small. Releases have moved at roughly monthly intervals through 2026, with v1.3.0 in June, v1.3.1 in July and v1.3.2 in August, and the last push was on 2026-08-24. Configuration is environment variables, so upgrades do not require migrating a config file, but they can rename or retire keys. The .env.example already carries a block of deprecated SAMBA_INGRESS_* aliases kept for backward compatibility, which tells you the project has renamed ingress variables before and may again. Diff your .env against the shipped example after each upgrade rather than assuming keys are stable.

The real ongoing cost is not the binary. It is Ollama. You need a machine that can serve a vision model at whatever latency you find tolerable, and the compose file supports an NVIDIA GPU profile via COMPOSE_PROFILES=gpu and OLLAMA_GPU_COUNT. On CPU, a vision model per page is slow enough that a busy scanner will queue up behind it. Budget the hardware for the model, not for Montscan, which is a small Go program.

Editorial conclusion

Montscan fits a single user or small office that already has a scanner pushing files to FTP or a Samba share and a Nextcloud or ownCloud instance to file them into, and who is willing to run Ollama alongside it. Skip it if you need a supported product, if your documents are sensitive enough that sending page images to a model endpoint is unacceptable, or if you cannot run Poppler or ImageMagick on the host. Before adopting, verify the vision model's output on your own document mix, confirm the container's published FTP ports do not collide with an existing FTP service, and decide whether the default FTP credentials should ever leave a test machine.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sh4den/Montscan on GitHub