Self-Host LanguageTool 6.7: Open Source Grammarly Guide

Two ways to run an open source Grammarly replacement: use the public LanguageTool API and hope your text isn’t logged, or self-host the exact same engine and own the pipeline end-to-end. The privacy argument is real – but there’s a bigger reason to self-host that most tutorials miss entirely. In December 2025, LanguageTool moved its browser extension behind a premium paywall, and the public server no longer accepts requests from the free extension. Self-hosting isn’t a privacy preference anymore. For anyone who wants the browser extension without a subscription, it’s the only path that still works.

This guide covers deploying LanguageTool 6.7 with Docker, wiring up the API, and dodging the traps buried in the community images.

What you’re actually installing

LanguageTool is a Java HTTP server that accepts text over REST and returns grammar and spelling suggestions. The core is licensed under LGPL 2.1 – but there’s a nuance worth knowing before you call it “fully open source”: among official LanguageTool integrations, only the OpenOffice and LibreOffice plugins are open source (and in LibreOffice, the plugin ships built in). Browser extensions, email plugins – all closed source. “Open source Grammarly” describes the engine, not the whole toolchain.

Version 6.7 released on 2025-10-01. And since March 2025, LanguageTool switched to a snapshot-based release model – v6.6 was the last ZIP. That matters because half the guides on Google still tell you to grab a ZIP from a URL that no longer produces new ones.

System requirements

Anyone who calls LanguageTool “lightweight” hasn’t loaded n-grams. Below is what actually works in practice.

Java 17 is a hard requirement as of v6.6. A 2 vCPU / 4 GB RAM VPS handles the server comfortably alongside other services (per Ethan’s Wiki, May 2026). The 15 GB disk figure for English n-grams isn’t a rough guess – it comes from the codeslikeaduck self-hosted LT walkthrough, and it bites people who provision a standard 20 GB root volume and then wonder why the container won’t start.

Pick the right Docker image (this trips people up)

Two community images dominate search results. Turns out they’re not interchangeable – the docs bury this.

• erikvl87/languagetool – the classic. It listens on port 8010 (not 8081), and the default heap is -Xms 256m / -Xmx 512m. That 512m ceiling will OOM the moment you load English n-grams under real traffic.
• meyay/languagetool – the successor. Built directly from LanguageTool repository tags since official release ZIPs were discontinued after v6.6, listens on 8081, and supports read-only filesystems and unprivileged users out of the box.

If you’re starting fresh in 2026, meyay is the safer pick – it’s actively tracking the snapshot release model. Already have a Compose file wired to port 8010? Keep erikvl87, but pin the tag.

One thing that doesn’t get written about much: what “open source” actually buys you here is auditability, not feature parity. You can read the rule files, write custom XML rules, and understand exactly why a suggestion fired. That’s a different value proposition than Grammarly’s black-box scoring – and for technical writers or teams with house style guides, it’s often more useful than a fluency score.

Install with Docker Compose

Create a directory, drop in this docker-compose.yml, and start:

services:
 languagetool:
 image: meyay/languagetool:latest
 container_name: languagetool
 restart: unless-stopped
 read_only: true
 tmpfs:
 - /tmp:exec
 ports:
 - "8081:8081"
 environment:
 Java_Xms: 512m
 Java_Xmx: 2g
 download_ngrams_for_langs: en
 volumes:
 - ./ngrams:/ngrams
 - ./fasttext:/fasttext

Then:

mkdir -p ngrams fasttext
docker compose up -d
docker compose logs -f languagetool

First boot is slow. The container downloads n-gram data and the fastText language model before the API accepts requests. Wait for the line that says the server is listening.

Memory note:Java_Xmx: 2g is the floor if you enable n-grams. The default 512m maximum on erikvl87 will OOM at startup with English n-grams loaded – not under load, literally at startup.

Verify it works

One curl call proves the whole stack:

curl -X POST 
 -d "language=en-US&text=This is a example sentence with a error." 
 http://localhost:8081/v2/check

Two matches come back: “a example” and “a error”. If you see them, the engine, dictionary, and HTTP layer are all healthy. The full API reference – including language codes and configuration options – lives in the official Swagger UI.

Connect the browser extension

The extension is closed source but still works against your server. Install it from the Chrome Web Store or Firefox Add-ons, open its settings, scroll to advanced/pro options, and set the API server URL to http://YOUR_SERVER_IP:8081/v2 (or http://localhost:8081/v2 if you’re running it on the same machine).

For remote access without opening ports, Tailscale works well – point the extension at the Tailscale hostname and skip the reverse proxy entirely.

Common errors and fixes

java.lang.OutOfMemoryError: Java heap space – the fix is increasing the Java heap, specifically bumping Java_Xmx to 4g or higher in your Compose file. This error also accumulates over weeks of uptime on undersized servers – budget headroom from the start.

Container exits immediately after adding a fastText config – here’s the catch on erikvl87’s image: set langtool_fasttextModel or langtool_fasttextBinary as environment variables and the container just dies. Those values are wired internally; the image doesn’t expose them as overridable. Remove the variables and the image handles fastText itself.

Extension shows “missing arguments” – you pointed it at the root URL instead of /v2. The path matters. Always append /v2.

N-grams downloaded but suggestions haven’t improved – check that langtool_languageModel=/ngrams is actually set and that the mount contains a language-specific subfolder (e.g. ./ngrams/en/1grams). Without the subfolder structure LanguageTool silently ignores the data.

Upgrade and uninstall

Upgrading is a one-liner if you pinned a tag. Change the image tag in your Compose file, then:

docker compose pull
docker compose up -d

State lives in the mounted ngrams and fasttext directories, so restarts don’t lose data. To uninstall completely:

docker compose down
docker image rm meyay/languagetool:latest
rm -rf ./ngrams ./fasttext

That’s it. No system-wide state, no leftover services.

A moment of honesty

LanguageTool isn’t Grammarly. It won’t rewrite your paragraphs, score fluency, or explain tone. What it will do: catch grammar and spelling errors across 25+ languages (as of late 2025), run entirely on your hardware, and cost nothing per seat. For a lot of writers – especially non-English natives working in mixed-language codebases and docs – that’s the more useful tool anyway.

FAQ

Do I need n-grams to get useful suggestions?

No. The base rules catch most errors. N-grams mainly help with confused-word pairs like their/there. Skip them if disk space is tight.

Can I run LanguageTool without Docker, just as a plain JAR?

Yes. Download the latest snapshot ZIP from languagetool.org/download/snapshots, unzip, and run java -cp languagetool-server.jar org.languagetool.server.HTTPServer --port 8081 --allow-origin '*'. You’ll need Java 17 installed on the host, and you’ll manage the process yourself – no restart-on-crash, no easy version pinning. Docker exists precisely to skip all that.

Is my self-hosted instance really as good as the paid cloud version?

Rules engine: identical. The gap shows up in LanguageTool Premium’s AI-based suggestions and picky-style checks – those run server-side models you can’t replicate locally. For pure grammar and spelling it barely matters. For “make my paragraph sound better,” no self-hosted setup closes that gap, and you should go in knowing it.

Next: spin up the Compose file above, run the curl verification, and point one editor extension at your new server. Once that round-trip works, you can stop typing into anyone else’s cloud.