Aldine

Aldine

Write LaTeX together. Fast, versioned, yours.

[CI] [License: AGPL v3] [PRs welcome] [Buy Me a Coffee]

Aldine is a self-hosted, open-source collaborative LaTeX editor and an Overleaf alternative. It is slim and built for speed: real-time multi-cursor editing, every project a real git repo with branches, native Zotero, ~2s warm recompiles. Two containers and one SQLite file by default: no database server to run, nothing to babysit.

Homepage · Try the live demo (resets nightly) · Quick start · How Aldine compares · Screenshots · Self-hosting · Contributing

Guides on aldine.dev: Self-hosting Overleaf (Community Edition, Server Pro) compared with Aldine · Git with Overleaf and a git-native alternative · A LaTeX MCP server for Claude

Live collaboration, a recompile, and a SyncTeX jump, in one real recording (compile wait trimmed):

[A collaborator's edits stream in live, the PDF recompiles in about two seconds, and double-clicking the PDF jumps the editor to the source line]

Status: Aldine reached 1.0 in October 2026, three months after its first release. Within 1.x an upgrade starts on older data with no manual step, and stable settings, MCP tools and the plugin API keep their names until 2.0 (docs/STABILITY.md). That is a promise about upgrades, not a long track record. It compiles real papers daily and every headline feature has a Playwright end-to-end test; CI runs those on every pull request, next to typecheck, build and the integration suites. Expect rough edges, and file issues generously.

Features

• Bring your Overleaf projects, and take them with you: download any Overleaf project as a ZIP, drop it on the home screen, keep writing — root file detected, first typeset automatic.

• Real-time collaboration: CRDT-based (Yjs), multi-cursor with live presence, conflict-free by construction. Unlimited collaborators.

• Git-native with branches: every project is a real git repository. Create branches, edit them independently, merge back from the UI. Publish a project to GitHub, GitLab, Gitea or Forgejo and a co-author can clone it and keep using VS Code; their commits come back with one Pull.

• Fast, sandboxed compiles: TeX Live + latexmk with persistent incremental builds (~2s warm recompiles) in a no-egress container with restricted shell-escape; errors surfaced with line numbers and click-to-jump.

• GitHub/GitLab/Gitea/Forgejo sync: import from GitHub, GitLab, Gitea or Forgejo as a project or publish a local project to a fresh repo, push/pull with ahead/behind indicators, branches, a conflicting pull that lists the files and keeps your version until you take the remote's, server-side autopush, and open a pull or merge request, all from the editor. gitlab.com and self-hosted GitLab, any Gitea or Forgejo instance (Codeberg included); a personal access token needs no OAuth app. A team instance can create every new project in a GitLab group automatically and push every autosave from the server.

• Native Zotero integration: link your whole Zotero library or a single collection, from My Library or any of your group libraries, no premium tier required; keep a .bib in sync with cheap version-aware refresh, insert citations from a search panel or via \cite{ autocomplete.

• Claude as a collaborator (optional, ALDINE_MCP=1): Aldine has a built-in MCP server. Connect your instance to claude.ai, Claude Desktop, Cowork or Claude Code over MCP and Claude edits, typesets and shows the PDF in the chat (inline on claude.ai, Claude Desktop and Cowork; a signed link elsewhere); every change is a git commit authored "Claude" with a review-and-revert toast in the editor. Setup, reachability and the security model: docs/AGENT_API.md.

  [Claude edits the open document, adds a section, typesets, and History lists its commits with a review prompt]

Quick start

No clone, no build: save this as docker-compose.yml and run docker compose up -d:

name: aldine
services:  app:    image: ghcr.io/trahloff/aldine-app:${ALDINE_VERSION:-1.9.1}    ports:      - "8080:3000"    volumes:      - aldine-data:/data      - aldine-secrets:/secrets    networks: [frontend, backend]    init: true    restart: unless-stopped
  compiler:    image: ghcr.io/trahloff/aldine-compiler:${ALDINE_VERSION:-1.9.1}${ALDINE_TEXLIVE:-}    volumes:      - aldine-data:/data    # The compiler runs untrusted LaTeX. Keep this block.    networks: [backend]    mem_limit: 2g    pids_limit: 256    cap_drop: [ALL]    security_opt: [no-new-privileges]    init: true    restart: unless-stopped
networks:  frontend: {}  backend:    internal: true # no route to the internet
volumes:  aldine-data:  aldine-secrets:

Open http://localhost:8080. That's it. Projects live in the aldine-data volume, and everything else (auth, SSO, AI fix, email) is opt-in via environment variables when you want it.

That is equivalent to the repo-root docker-compose.yml (same services, images and sandbox settings), so a clone works identically: git clone https://github.com/trahloff/Aldine && cd Aldine && docker compose up -d. Keep the name: aldine line wherever you save it: it fixes the volume names, which is what lets you switch compose files later and what deploy/backup.sh looks for.

• You are pinned to a version. The block above says ${ALDINE_VERSION:-1.9.1}, so a fresh copy installs the current release and nothing under a running install changes on its own. To upgrade, read the CHANGELOG, back up (deploy/backup.sh), write the new version into a .env file next to docker-compose.yml, then pull:

  # .envALDINE_VERSION=<new version>
  docker compose pull && docker compose up -d

  Compose reads .env on every call, so a later up stays on that version. A prefix (ALDINE_VERSION=… docker compose pull && docker compose up -d) reaches only the first command, and up starts the old version again. To roll back, put the previous release in .env and run the same two commands. Your projects live in the aldine-data and aldine-secrets volumes and an image swap does not touch them. :latest still exists and points at the newest release; pinning is what lets you choose when to move.

• Stability. Versions follow SemVer. A 1.x release starts on data from an earlier 1.x, or from 0.14 or later, with no manual step, and nothing covered is removed before 2.0. Every release is built from a commit that passed CI, and its images are booted and made to typeset a real document before :latest moves to them. Before that, it is also started on volumes left by the previous release and by 0.14.4, on the JSON store and on Postgres, and the projects, comments, shares and tokens have to survive. Back up first anyway. Watch the repo's Releases for security fixes: per SECURITY.md, only the latest release gets them. Which data, settings and APIs every 1.x keeps working, and how each promise is checked, is in docs/STABILITY.md.

• The first pull is big. TeX Live lives in the compiler image: about 2.4 GB to download, about 5 GB on disk. It carries TeX Live's medium scheme plus the pictures, latexextra and bibtexextra collections (pgfplots, tikz-cd, cleveref, todonotes, minted, biblatex, …), the publisher classes, and the Arabic, Persian, Cyrillic and Greek scripts; the one family it leaves out is CJK. After the first pull, starts take seconds. Ready when curl localhost:8080/api/health returns {"ok":true,"name":"aldine"}.

• Need a package it does not have? The missing-package error in the editor names it. Two ways to get it, and project settings show which image you are on:

  • Add just that package. Put a docker-compose.override.yml next to docker-compose.yml that builds a derived compiler image, then docker compose up -d --build. tlmgr installs from the same dated TeX Live snapshot the release was built from, so this keeps working after the release ages:
    yaml

    services:  compiler:    image: aldine-compiler-local    build:      dockerfile_inline: |        FROM ghcr.io/trahloff/aldine-compiler:1.9.1        RUN tlmgr install pgfplots tikz-cd

    Bump the FROM tag when you bump ALDINE_VERSION. Compose builds the image on your machine, so this works for arm64 servers as well.
  • Get everything. Every release from 0.4.0 also ships all of TeX Live as -full (about 2.8 GB compressed, 9 GB on disk; CJK is only here). Add ALDINE_TEXLIVE=-full next to ALDINE_VERSION and pull again.

• Port 8080 taken? Change the left side of ports:; with docker-compose.full.yml, set ALDINE_PORT=8081 in .env instead.

• On a NAS, with the same compiler sandbox:

  • CasaOS and ZimaOS: import deploy/casaos/docker-compose.yml under App Store → Custom Install.
  • TrueNAS 24.10 and later: docs/TRUENAS.md (Install via YAML).
  • Unraid: docs/UNRAID.md (Compose Manager Plus).

• Everything beyond the minimum: building from source (latest main, not a release), auth/SSO/AI/email options, TLS, Postgres/Redis. All of it lives in docker-compose.full.yml, which carries the same compiler sandbox and the same volumes, so you can switch without losing data: docker compose -f docker-compose.full.yml up -d --build. The first build installs TeX Live into the compiler image; expect 20–60 minutes (the tlmgr install step is most of it), then seconds per start. ALDINE_TEXLIVE_SCHEME=full builds the all-of-TeX-Live variant instead.

How Aldine compares

If Overleaf CE fits you, use it; it's good software. Aldine exists for people who want review comments with suggested edits, git and Zotero without paid tiers, in a deployment they can hold in their head.

Every Overleaf CE cell except "Not measured" links to the Overleaf page it was checked against on 2026-10-12. For GitHub synchronization and Zotero we found no Overleaf page that states them for the on-premises editions, so those cells quote what Overleaf does say. A longer, dated version of this comparison is at aldine.dev/self-hosted-overleaf.

Screenshots

Home: every project shows page 1 of its last typeset. Search, sort, or start a new one from a template, a ZIP or a git host.

Visual editing: the source rendered as formatted text, byte-stable, with math and tables editable in place. Switch with Source/Visual in the toolbar.

Development

npm installnpm run dev:server     # API + collab on :3000npm run dev:web        # Vite on :5173 (proxies to :3000)docker build -t aldine-compiler apps/compilerdocker run -d -p 4020:4020 -v $PWD/.data:/data aldine-compiler

Tests

npm run typecheck -w apps/web && npm run test -w apps/web   # tsc + vitestnpm run test:github -w apps/server                          # GitHub-sync integrationnpm run test:gitlab -w apps/server                          # GitLab-sync integrationnpm run test:gitea -w apps/server                           # Gitea/Forgejo-sync integrationnpm run test:db -w apps/server                              # datastore conformance

End-to-end (Playwright; covers compile, collab, branches, plugins, Zotero). The suite starts its own app on :3100 but not the compiler, and it runs against .data-e2e, so the compiler has to point at that directory or every compile test fails against a healthy-looking compiler:

npx playwright install chromiumDATA_DIR=$(pwd)/.data-e2e PORT=4020 node apps/compiler/server.js &   # or a container on the same dirnpm run test:e2eALDINE_URL=http://localhost:8080 npm run test:e2e   # against a running compose stack instead

Production deploy

Settings live in a .env file next to the compose files, so every later docker compose call picks them up. Give each comment its own line: anything after a value becomes part of the value, and AUTH_ENABLED=1 multi-user login is not 1, so auth silently stays off.

# app on loopback only; your reverse proxy fronts itALDINE_APP_BIND=127.0.0.1# absolute URL of the app, used in OAuth callbacks, password-reset links and# the PDF links the MCP connector hands out. Give it a path to serve Aldine# under a prefix (https://server/internal/aldine); the Claude connector URL# is <ALDINE_PUBLIC_URL>/mcpALDINE_PUBLIC_URL=https://aldine.example.com# signs the connector's 15-minute PDF links; generated into META_DIR when# unset — set it explicitly when several nodes do not share that volume.# At least 32 characters (`openssl rand -base64 32`); shorter values refuse to bootALDINE_SIGNING_SECRET=# MCP endpoint for Claude (docs/AGENT_API.md); needs AUTH_ENABLED=1 or ALDINE_MCP_TOKENALDINE_MCP=# static bearer for /mcp with auth off (single-tenant); ignored when AUTH_ENABLED=1ALDINE_MCP_TOKEN=
# Everything below is optional and off unless set.# multi-user login, ownership and sharing (unset = single-tenant)AUTH_ENABLED=1# Google SSOGOOGLE_OAUTH_CLIENT_ID=GOOGLE_OAUTH_CLIENT_SECRET=# GitHub SSOGITHUB_LOGIN_CLIENT_ID=GITHUB_LOGIN_CLIENT_SECRET=# ORCID SSO: a Public API client (orcid.org/developer-tools, HTTPS callback# <ALDINE_PUBLIC_URL>/api/auth/oauth/orcid/callback); ORCID_SANDBOX=1 for sandbox.orcid.orgORCID_CLIENT_ID=ORCID_CLIENT_SECRET=# OpenID Connect SSO (Keycloak, Authentik, Authelia, Pocket ID, …): redirect URI# <ALDINE_PUBLIC_URL>/api/auth/oauth/oidc/callback; every option in docs/OIDC.mdOIDC_ISSUER=OIDC_CLIENT_ID=OIDC_CLIENT_SECRET=OIDC_LABEL=OIDC_ALLOWED_GROUPS=# GitHub repo sync: a separate OAuth app with repo scope; GITHUB_URL points# it at a GitHub Enterprise Server (PAT connect works without these)# GITHUB_URL=https://github.comGITHUB_CLIENT_ID=GITHUB_CLIENT_SECRET=# GitLab sync (gitlab.com or self-hosted); PAT connect works without theseGITLAB_URL=https://gitlab.comGITLAB_CLIENT_ID=GITLAB_CLIENT_SECRET=# Gitea / Forgejo sync needs nothing here: users paste a token and their instance URL# REMOTE_PROVIDERS=github,gitlab,gitea   # hide a provider by leaving it out# Optional: every new project is also created on GitLab in this group (service# account PAT with scope api and Owner on the group). Off unless both are set.GITLAB_TOKEN=GITLAB_DEFAULT_GROUP=# GITLAB_DEFAULT_VISIBILITY=private   # or internal | public# AUTOPUSH_DEBOUNCE_MS=30000# AI error fix, bring your own keyOPENROUTER_API_KEY=# password-reset email: SMTP, or SES_FROM + AWS_REGION insteadSMTP_HOST=SMTP_PORT=587SMTP_USER=SMTP_PASS=SMTP_FROM=# error tracking, and which instance the errors came fromSENTRY_DSN=SENTRY_ENVIRONMENT=production# Templates from your own git repositories (see templates/README.md)# TEMPLATE_REPOS='[{"id":"lab","label":"Lab templates","url":"https://gitlab.example.org/latex/templates.git","tokenEnv":"TEMPLATE_REPO_LAB_TOKEN"}]'# TEMPLATE_REPO_LAB_TOKEN=

# Behind your existing reverse proxy (nginx, Traefik, …), the usual setup. The# prod overlay trusts proxy headers, sets secure cookies, and rotates logs;# point your proxy at 127.0.0.1:8080.# Sample nginx vhost (WebSocket + body-size gotchas handled): deploy/nginx.confdocker compose -f docker-compose.full.yml -f deploy/docker-compose.prod.yml \  up -d --build
# …or, if nothing else owns ports 80/443, add the bundled Caddy for# zero-config HTTPS: append `--profile tls` and set ALDINE_DOMAIN in .env.
# Back up the data + secrets volumes (and the bundled Postgres, if you use it):deploy/backup.sh aldine-backup.tar.gz# Restore, after stopping the stack with `docker compose down` (with Postgres,# start the database alone first: deploy/README.md, "Restore"):#   deploy/restore.sh aldine-backup.tar.gz

Every variable Aldine reads is listed in deploy/README.md.

Isolation & limits. The compiler runs on an internal-only Docker network (no internet egress), drops all Linux capabilities, and is bounded on CPU / memory / PIDs; LaTeX compiles with restricted shell-escape (whitelist only) and openin_any=p. Per-client rate limits guard login, AI, and reference lookups; compiles are concurrency-capped, with optional per-user compile quotas (ALDINE_COMPILE_QUOTA_MIN) if you host for a group.

See deploy/README.md for the full single-VPS runbook (nginx/Traefik/Caddy ingress, backups, SSO setup, Postgres/Redis, every config variable), deploy/aws for a Terraform/Fargate deployment, and SECURITY.md for the threat model and how to report vulnerabilities.

Architecture

┌────────────┐   HTTP/WS    ┌──────────────────────────────┐│  Browser   │ ───────────► │  app (Node 22)               ││  React +   │              │  Fastify API + Hocuspocus    ││  CM6 + Yjs │              │  git repos + worktrees       │└────────────┘              └──────────┬───────────────────┘                                       │ shared volume /data                            ┌──────────▼───────────────────┐                            │  compiler (TeX Live medium)  │                            │  latexmk wrapper, sandboxed  │                            └──────────────────────────────┘

• One Yjs document per file per branch (project::branch::path), persisted straight to the git worktree with debounced writes and auto-commits.
• Branches are git worktrees, so every branch is editable concurrently.
• Compile output stays inside the project tree (.aldine-out/, kept out of git history) which keeps latexmk's incremental cache warm.

Data & storage

Two separate concerns, behind two seams:

• Project files: real git repos + worktrees on disk (store.ts). This is what gives you branches and history.
• Relational/metadata: users, sessions, project metadata, review comments, and usage go through the DataStore interface (db/). Three backends:
  • SQLite (default): one file, META_DIR/aldine.db, through the node:sqlite module built into Node, so no dependency. On its first start it copies the JSON files of an earlier release and leaves them as they were.
  • JSON files (ALDINE_DATASTORE=json): the default before 1.7, kept for anyone who wants plain files.
  • Postgres (set DATABASE_URL): the horizontally-scalable backend, and the prerequisite for ever running multiple app nodes. pg is an optional dependency; the same conformance suite runs against all three.

For how this scales past one box (and what the remaining walls are), see docs/SCALING.md.

Plugins

A plugin is a folder in plugins/:

plugins/hello/├── manifest.json   # { "id": "hello", "name": "Hello", "version": "1.0.0", "entry": "index.js" }└── index.js        # export default { activate(aldine) { ... } }

The aldine API exposes ui.registerSidebarPanel (with an optional onShow, called each time the panel comes into view), ui.showPanel (select one of the plugin's own panels), ui.registerCommand (a palette command), ui.confirm (a question in the app's own dialog), editor.insertAtCursor, editor.insertCitation, project context, compile(), toast(), and fetch(). See plugins/zotero for a complete example.

Templates

A template is a folder with a template.json and the files to start from; the shipped ones live in templates/. A group that keeps its own thesis, poster or report templates puts the same layout in any git repository (GitHub, GitLab, Gitea, a bare repo over https), lists it in TEMPLATE_REPOS, and the templates appear in the gallery under the repository's name, refreshed on an interval or with "Refresh templates", with {{PROJECT_NAME}}, {{AUTHOR}}, {{DATE}} and {{YEAR}} filled in on create. Layout, manifest fields, placeholders and private-repository tokens: templates/README.md.

License

Copyright (C) 2026 Tobias Rahloff.

AGPL-3.0: self-host freely; if you offer a modified Aldine as a service, share your changes. Third-party plugins interact with Aldine over its plugin API and may use any license. Each folder under templates/ carries its own LICENSE and states it in template.json (the gallery shows it on the tile): the generic templates are MIT, and templates/iac-paper is LPPL-1.3c, the customary license for a LaTeX class file. Venue templates are generated from the classes installed in the compiler image, with the license tlmgr reports. Venue kits are downloaded from the publisher when a project is created, and their tile links the publisher's terms instead of naming a license. No publisher file is stored in this repository. Overleaf is a trademark of its owner. Claude, Zotero, GitHub, GitLab and other names are trademarks of their respective owners. Aldine is an independent project, not affiliated with or endorsed by any of them.

Two things stated plainly, because finding them out later feels like a bait-and-switch. A hosted Aldine service is planned, and contributions are accepted under a CLA that permits relicensing, so a commercially licensed edition is possible in future. What will not change: the self-hosted edition stays AGPL-3.0, and no feature that works today moves behind a paid tier. The name is handled separately in TRADEMARK.md.