The Quiet Collapse of Cloud LaTeX

There is a particular kind of panic that descends on an academic department twenty-four hours before a conference submission deadline when the typesetting platform goes down.

It is not the dramatic, headline-grabbing panic of a stock market crash or a data center fire. It is quieter and more specific. It is a PhD student sitting in front of a spinner that refuses to stop, a manuscript partially compiled, a bibliography unresolved, and the clock moving with absolutely no intention of slowing down. It is a faculty member refreshing a status page that says "investigating" while their paper sits half-rendered on a remote server they cannot access and cannot influence. It is the particular helplessness that comes from having organized your entire intellectual infrastructure around a single point of failure you were told was a convenience.

This is the landscape of cloud-based LaTeX in 2026. And the researchers who have lived through it—once, twice, repeatedly—are leaving.

Not loudly. Not with manifestos. They are simply installing toolchains on their own machines, configuring local compilation engines, and never looking back.

A Crisis Hiding in Plain Sight

The Canvas ransomware incident of May 2026 is the kind of event that crystallizes what was always structurally obvious but operationally ignored.

On May 1st, the hacking group ShinyHunters breached Instructure's Canvas learning management system—a platform embedded into the academic infrastructure of 41% of North American higher education institutions. By May 7th, ransomware messages had replaced login pages across more than 8,800 universities worldwide. Approximately 30 million active participants lost access during finals week. The University of Illinois at Urbana-Champaign postponed all final exams. Boise State canceled Friday finals entirely. The University of California system blocked Canvas access across every campus until security could be confirmed.

Colleges had no contingency plans. That detail deserves its own paragraph, because it is the most revealing part of the entire incident. Faculty and students had built their academic workflows so thoroughly around a single cloud system that when that system disappeared, there was simply no alternative waiting. The infrastructure had been externalized so completely that institutional knowledge of how to operate without it had atrophied.

The average ransomware recovery cost for higher education institutions reached $4.01 million in 2024—nearly four times the figure from the year before. The cost is rising. The dependency is deepening. The two trends have an obvious relationship.

This is the broader context within which the LaTeX conversation is happening. Overleaf is not a ransomware target in the same way. But it operates within the same dependency architecture: centralized infrastructure, remote compilation, data uploaded to servers the user does not control. And its failure record is substantial enough to require no embellishment.

"

The pattern is not a bug. It is the predictable behavior of a platform that has normalized fragility by making outages feel temporary while making dependency feel permanent.

Eighty-Six Outages and Counting

Since February 2020, Overleaf has experienced 86 tracked outages. Seventeen of them occurred in a single twelve-month period.

A complete site-down event in May 2025 lasted approximately six hours. In March 2026, publisher submissions failed for three hours—researchers attempting to submit papers to journals simply could not. In November 2025, compilation broke entirely when using certain packages, preventing PDF generation at a point when researchers were most likely to need it.

Each individual outage is a temporary inconvenience. But the accumulated pattern tells a different story. For researchers working against conference deadlines, dissertation windows, or journal review cycles, the consequence of a six-hour outage on the wrong day can be measured in career terms. A missed submission window does not reset. A deadline does not negotiate.

One Hacker News comment posted during an Overleaf outage captured the stakes with unusual clarity: there were people who were not going to graduate because of this, and there were conference papers that would miss deadlines. The comment was not hyperbole. It was a straightforward description of what dependency looks like when it fails.

The October 2025 AWS outage demonstrated how individual platform problems scale into cascading infrastructure events. A single DNS failure in the US-East-1 data center rippled through Canvas, Zoom, and thousands of dependent services for fifteen hours. Over four million users reported issues across more than sixty countries. Every major cloud provider—AWS, Google Cloud, Microsoft Azure—experienced significant outages in 2025 alone.

"

Cloud outages in academic infrastructure are no longer anomalies. They are statistical expectations. The question is not whether they will happen, but whether your workflow survives them.

The Compile Timeout Is Not a Bug

Understanding what Overleaf actually sells requires understanding what LaTeX actually does.

LaTeX is not a word processor. It is a typesetting language with the computational properties of a Turing-complete system. Processing a document can literally redefine the rules for parsing the rest of the document. A single imported package can alter every subsequent compilation decision, which means there is no static map of dependencies—the document must be interpreted sequentially, completely, on every pass.

This is why LaTeX compilation is often a multi-pass process. Cross-references must be resolved. Bibliographies must be built. Glossaries must be sorted. Indices must be generated. A thesis with a substantial bibliography might require three full passes through the document before the PDF is coherent. A document using complex vector graphics packages like TikZ or pgfplots requires those graphics to be calculated and rendered on every compile.

A typical thesis compiles in 4–7 seconds per single pdflatex pass on a modern local machine. Full multi-pass compilation with BibLaTeX and glossaries takes 20–34 seconds. One 78-page physics paper required close to four minutes. These are not edge cases—they describe the realistic behavior of real academic documents.

Overleaf's free tier imposes a compile timeout of 10 seconds.

The arithmetic does not require elaboration. A document that takes 5 seconds per pass requires at least 15–20 seconds for a complete multi-pass compilation. A thesis with TikZ figures may need four minutes. The free tier times out on documents that are routinely submitted to journals. Premium plans extend the timeout to 240 seconds, which is more generous but still imposes an artificial ceiling on a process that, run locally, has no ceiling at all.

Overleaf's own documentation states the situation plainly: if you are preparing a large or complex document, you may need to subscribe to a premium plan to get more compile time. That sentence, written without apparent irony, describes forcing payment for access to computation that already exists on the user's own hardware.

The July 2024 change to project sharing added another dimension to this pressure. Overleaf altered its free tier so that all editors—whether invited by email or via shared link—count toward the collaborator limit, with free plans restricted to one collaborator per project. The link-sharing workaround that had allowed informal collaboration across academic groups was specifically closed. Multi-author academic papers, which are the norm rather than the exception in most research fields, now require paid plans to collaborate in real time.

The community reaction to these changes has been consistent and visceral. One Reddit thread titled "why these greedy bastards" accumulated hundreds of comments. Another describing the timeout as "ridiculous" drew responses from researchers who had begun disabling their table of contents, reducing vector graphics quality, and working around features of their own documents just to stay within the free tier's limits. This is not a marginal user behavior. It is a documented pattern of researchers deliberately degrading the quality of their work to comply with cloud resource constraints.

Your Research Data Is Not Fully Yours

The compile timeout is visible and quantifiable. The data privacy situation is less legible but considerably more consequential.

A 2026 IEEE Security & Privacy study from RWTH Aachen University conducted a systematic analysis of all 2.7 million arXiv submissions containing source files. The finding: 88% contained content that was never meant for public distribution.

The researchers identified three categories of unintended exposure. The first was unnecessary bundled files—backup folders, old drafts, complete Git repositories uploaded alongside the document. The second was metadata embedded in images and PDFs: usernames, GPS coordinates, hardware identifiers baked into file headers by the tools that created them. The third, and arguably most sensitive, was content embedded in LaTeX comments—the % lines that authors use for notes, editorial communications, and reminders to themselves.

The specific numbers from that study are difficult to read without a degree of alarm. Among the 2.7 million submissions: 699 links to Google Docs granting edit access. At least 200 documents containing reviews and cover letters never intended for public view. Eighteen submissions containing survey data with personally identifiable information. Eighty-two submissions containing API tokens, private keys, or passwords.

A complementary analysis—the LaTeXpOsEd framework—reviewed over 1.2 terabytes of source data from 100,000 arXiv submissions and found thousands of PII leaks, GPS-tagged EXIF files embedded in image uploads, publicly accessible Google Drive and Dropbox folders linked from within documents, and exposed cloud API keys. These were not malicious uploads. They were the ordinary consequences of workflows where researchers upload entire project directories to cloud platforms without inspecting every file within them.

The Structural Conflict Nobody Discusses

There is a structural dimension to the Overleaf data situation that receives less attention than the individual vulnerability reports but is arguably more significant as a long-term concern.

Digital Science, Overleaf's parent company, is owned by Holtzbrinck Publishing Group—the same corporate entity that owns Springer Nature. In 2025, Digital Science launched AI writing tools for Overleaf's more than 20 million users. The press release described the move as providing access to next-generation AI capabilities.

Consider what this creates: a publisher that owns both the platform where researchers write their papers and the publication pipeline through which those papers are reviewed and accepted. Researchers upload pre-publication manuscripts, draft sections, unpublished data tables, and internal communications to a platform owned by an entity that has financial interests in the content of academic publishing. The documents uploaded to Overleaf are stored on Google Cloud Platform infrastructure, meaning the research passes through US-headquartered third-party systems with their own regulatory obligations and data handling practices.

The platform's own privacy policy does not make this situation cleaner. Understanding exactly which data informs which AI features, and under what legal frameworks that data can be accessed, requires the kind of legal expertise that most researchers do not possess and most institutions do not provide.

"

Privacy through policy—terms of service, compliance certifications, contractual guarantees—is not the same as privacy through architecture. The former is a legal instrument. The latter is a technical fact.

The Jurisdictional Trap

The regulatory landscape for cloud-hosted research data has shifted significantly in the past two years, and the direction of travel is unmistakable.

The US CLOUD Act obliges US-based technology companies to comply with law enforcement requests for data stored anywhere in the world—including data physically located in European data centers. Microsoft has stated publicly that it would comply with such requests for EU citizen data stored in the EU, regardless of EU law. The practical implication is stark: a European researcher uploading a pre-publication manuscript to a US-controlled cloud platform does not have the data protection of EU law, even if the bits are physically located in Frankfurt.

France's data protection authority, the CNIL, has articulated the principle with unusual clarity. For the most sensitive data processing, it recommends using a service provider exclusively subject to European law—a category that effectively excludes all US hyperscalers. The EU-US Data Privacy Framework, adopted in July 2023, faces an existential legal challenge from privacy advocates who have pledged to contest it before the European Court of Justice. The Trump administration's decision to fire Democrat members of the Data Protection Review Court in January 2025 left that body unable to function, further destabilizing the legal basis for transatlantic data transfers.

The institutional responses to this landscape are concrete and already underway. Schleswig-Holstein completed the migration of its entire email system from Microsoft Exchange to Open-Xchange and Thunderbird for over 40,000 civil servants, and is in the process of moving 30,000 PCs from Microsoft Office to LibreOffice and from Windows to Linux. The state's digital minister framed the decision in terms that resonate well beyond German regional government: it is a core responsibility to be able to influence the operational processes of IT systems at all times and to ensure data security.

Denmark's Ministry of Digitalisation began switching from Microsoft Office 365 to LibreOffice in mid-2025. The International Criminal Court migrated off Microsoft services entirely after US sanctions caused its chief prosecutor to lose access to his Microsoft-hosted email—a vivid demonstration of how cloud dependency and geopolitical risk interact in ways that are almost impossible to predict in advance.

The European Commission itself launched a €180 million sovereign cloud tender in late 2025, awarded in April 2026 to four European provider groups for up to six years of service to EU institutions. Gartner has identified "geopatriation"—the deliberate relocation of workloads from hyperscale public clouds perceived to pose geopolitical risks—as a key infrastructure trend for 2026. A European Commission "Tech Sovereignty Package" was expected in late May 2026.

Evolution Timeline: Institutional Cloud Migration

• 2022 → Schleswig-Holstein announces full migration away from Microsoft for civil service
• July 2023 → EU-US Data Privacy Framework adopted; NOYB immediately announces legal challenge
• 2024 → France SecNumCloud certification formally excludes US hyperscalers from sensitive procurement
• October 2024 → NIS2 Directive transposition deadline grants member states power to mandate EUCS-certified providers
• January 2025 → Trump administration dismantles Data Protection Review Court
• Mid-2025 → Denmark Ministry of Digitalisation begins LibreOffice migration
• October 2025 → European Commission launches €180M sovereign cloud tender
• April 2026 → Sovereign cloud contracts awarded to four European provider groups
• May 2026 → Canvas ransomware affects 30 million academic users; EU Tech Sovereignty Package expected

For academic researchers, these developments converge on a single practical implication: documents containing pre-publication research, sensitive survey data, or institutional communications that are uploaded to US-controlled cloud infrastructure exist in a legal jurisdiction that European law cannot fully protect. The simplest compliance strategy is also the most architecturally robust. Data that never leaves your local machine cannot be subpoenaed from a server, cannot be exposed through a platform breach, and cannot be fed into AI training systems without your knowledge.

Why the Old Local Toolchain Failed

The failure of cloud LaTeX is clear. What is less often acknowledged is that the previous alternative—the traditional local LaTeX distribution—failed in its own distinctive ways, and those failures explain why researchers chose the cloud option in the first place.

Installing TeX Live, the standard local LaTeX distribution, means downloading approximately 9 gigabytes of files. The process takes over an hour even on fast connections. It deposits thousands of package files across the operating system's directory structure, often requiring system administrator permissions that corporate IT departments and university library policies routinely prohibit for standard user accounts.

After installation, the local editing environment must still be constructed from separate components. A text editor. A compilation extension. An external PDF viewer. A version of SyncTeX configured to connect them. Configuring this chain requires writing JSON build recipes, explicitly defining paths to executables, and establishing bidirectional navigation between the editor and the PDF viewer—navigation that breaks whenever any component in the chain updates.

When the pipeline breaks—and it breaks—the researcher must become a systems administrator. The compilation logs are impenetrable to non-specialists. Package version mismatches are common. The tlmgr package manager, used for updating the distribution, has its own failure modes. The cognitive overhead of maintaining the toolchain often exceeds the cognitive overhead of the writing itself.

The cloud promised to dissolve all of this complexity. It succeeded, for a time, for simple documents. It failed structurally for anything approaching the complexity of real academic work.

The Architectural Failures, Side by Side

Each column in that table represents a real population of frustrated users who attempted the approach and eventually retreated. The cloud users are retreating now. Some are going back to the broken local toolchain because even its friction is more predictable than cloud outages. But the more productive response is to ask whether the toolchain itself has been rebuilt for this decade.

It has. And the new architecture looks quite different from the TeX Live behemoth.

The Intellectual Foundations of Local-First

The philosophical framework for what a better architecture should look like was articulated formally in 2019 by Martin Kleppmann and colleagues at Ink & Switch, in a paper that proposed seven ideals for what they called "local-first software."

The ideals: operations respond without network round-trips. Data synchronizes across devices when connectivity is available. Users can read and write without a network connection. Multiple users can collaborate concurrently. Data remains accessible even if the vendor ceases to exist. End-to-end encryption protects user data. And the vendor cannot restrict how users access their data.

The core architectural distinction is deceptively simple: in a local-first system, the user's device holds the canonical copy of all data, with changes synchronized in the background when connectivity is available. In a cloud application, the server holds the authoritative copy, and the local client is merely a display window. When the server is unavailable, the cloud application stops functioning. When network connectivity is unavailable, local-first software continues operating with full capability.

That paper has since grown into an active community with its own conference series (Local-First Conf, held in Berlin since 2024), podcast, and regular meetups. Industry adoption has followed: Apple implements conflict-free replicated data structures in the Notes app for syncing offline edits, Figma uses similar structures for collaborative design, and Microsoft's Fluid Framework provides collaborative SDKs built on the same principles.

LaTeX, as a document format, is natively compatible with local-first principles. Source files are plain text. They can be version-controlled with Git, edited offline, synchronized through any mechanism the user chooses, and compiled on any machine that has the appropriate engine installed. The architecture was always there. What was missing was tooling that made it as accessible as a cloud editor—without the cloud.

The Modernized Engine: Tectonic

The 9 GB TeX Live problem has been solved. The solution is Tectonic.

Written primarily in the memory-safe Rust programming language, Tectonic is a self-contained, modernized LaTeX engine that operates as a single executable binary. It does not require a multi-gigabyte upfront installation. Instead, it parses the source document during compilation, identifies required packages, retrieves them from a versioned bundle, and caches them locally for subsequent use. The total footprint for a given document is limited to only the packages that document actually needs.

The architectural consequence of this design is reproducibility. Because the engine relies on a version-locked bundle of support files, a document compiled on one machine produces the exact same PDF output on another. The "works on my machine" syndrome—a persistent problem in shared LaTeX projects where collaborators have different package versions installed—disappears by construction. There is no divergence in the compilation environment, because the compilation environment is defined by the document itself.

Tectonic also automates multi-pass compilation. It handles cross-references, bibliography generation, and index sorting without requiring the user to write or understand latexmk scripts. The user provides source text; the engine handles the rest.

# Install Tectonic (single binary, no system-wide TeX distribution required)
curl --proto '=https' --tlsv1.2 -fsSL https://drop.tectonic-typesetting.github.io/install.sh | sh

# Compile a document — multi-pass handled automatically
tectonic thesis.tex

# Build with a specific format bundle for reproducibility
tectonic -X compile --only-cached thesis.tex

This is what "zero-configuration local compilation" looks like in practice. No installation wizard. No system path modification. No tlmgr. No package manager ritual before you can write.

Building the Sovereign Stack

The offline LaTeX ecosystem in 2025–2026 offers mature, production-capable alternatives to cloud editors. These are not compromises arrived at through desperation. They are architecturally superior arrangements for researchers who need reliability, performance, and data control.

The Editor Layer

VS Code with LaTeX Workshop represents the most accessible entry point for researchers migrating from Overleaf. The extension provides live PDF preview with SyncTeX forward and inverse search, automatic compilation on file save, and intellisense for citations and references across a project's bibliography. Version 10.9.0 (released March 2025) added real-time collaboration via Live Share with PDF previewing—a free, local-first collaboration model with no collaborator caps and no monthly fees.

The extension's configurable build system supports all major engines: pdfLaTeX, XeLaTeX, LuaLaTeX, and Tectonic. Git integration comes through VS Code's built-in source control interface without additional configuration.

Neovim with VimTeX serves researchers who prioritize editing speed above all else. The workflow popularized by Gilles Castel demonstrates real-time mathematical typesetting using snippet expansion—LaTeX commands appear as the user types, matching the speed of handwriting mathematical notation. VimTeX provides continuous compilation, SyncTeX integration with PDF viewers, and text objects for navigating document structure. For researchers with established Vim workflows, this arrangement produces LaTeX faster than any browser-based editor.

TeXstudio 4.9.3 (March 2025) remains a strong choice for researchers who prefer a traditional graphical interface. It offers word-level SyncTeX—clicking on a specific word in the PDF preview jumps to the exact source position—along with over a thousand mathematical symbols accessible from the toolbar. The install-and-write experience requires no configuration to begin.

The Bibliography Layer

A complete academic workflow requires bibliography management. Zotero combined with Better BibTeX provides automated export of .bib files that update automatically whenever the Zotero library changes. The export generates stable, predictable citation keys and supports watching specific .bib files used by LaTeX projects. JabRef provides a native BibTeX/BibLaTeX editor with direct integration into TeXstudio, Emacs, and VS Code.

Both tools operate entirely offline after initial setup. Neither requires an account. Neither sends document content to remote servers.

The Collaboration Layer

Collaboration in a local-first LaTeX environment is handled through Git. This is not a limitation compared to real-time cloud collaboration—it is, for serious academic work, a superior arrangement.

Git-based LaTeX workflows benefit from a specific structural choice: writing each sentence on its own line. Since Git was designed to version-control source code where each line is semantically distinct, this formatting minimizes merge conflicts between collaborators working on the same document. A co-author editing the second sentence of a paragraph does not create a conflict with another co-author adding a sentence to the end of that same paragraph.

Branches allow experimental work without destabilizing the main document. A collaborator proposing a substantial restructuring of a methodology section can do so on a separate branch, compile the full PDF to verify the layout, and submit a pull request for review. The main document remains compilable throughout. This is the workflow model that professional software engineering adopted over a decade ago, and it maps cleanly onto collaborative academic writing.

The latexdiff and git-latexdiff tools enable formatted visual diffs between any two commits—changes appear as tracked edits in a compiled PDF, providing reviewers with human-readable change documentation without requiring a cloud platform to generate it.

# Create a branch for a major revision
git checkout -b chapter-3-rewrite

# After editing, compile locally to verify
tectonic thesis.tex

# Generate a PDF showing differences from the main branch
git latexdiff main chapter-3-rewrite -- thesis.tex

The Broader Industrial Pattern

The migration away from cloud-dependent professional tools is not isolated to academic LaTeX. It is a structural shift underway across multiple sectors of the software industry.

Early 2026 saw the "SaaSpocalypse"—a term applied to the roughly $300 billion in SaaS market value that evaporated over a short period, with a major software index down approximately 30% from its late-2025 peak. This was not simply a valuation correction driven by interest rates. It reflected a market-level recognition that a specific business model had run its course.

Cory Doctorow's 2022 coinage "enshittification" gave vocabulary to something that developers and researchers had been observing empirically for years: platforms attract users with quality, then progressively degrade service while maximizing extraction. The compile timeout trajectory is a textbook illustration. Overleaf's free tier once offered 60 seconds of compilation time. It now offers 10. The direction of change is not ambiguous.

The economic case for running workloads locally is increasingly documented. Basecamp saved approximately $10 million over five years by moving off AWS onto its own hardware. A Retool survey reported by Forbes found that 35% of companies had already replaced at least one SaaS tool with something they built themselves, with 78% planning to continue. Individual developers have documented savings of over $1,100 per year by running services on a single energy-efficient local server.

The knowledge management community demonstrates this shift in a domain adjacent to academic writing. Obsidian stores notes as plain Markdown files on the user's local drive. Users migrating from Notion cite data ownership and offline access as primary motivations—not features, not performance, not price, but ownership. Logseq takes the same position explicitly: notes are plain text files in a folder on the user's hard drive, and that folder is theirs.

The pattern is consistent across contexts: users are choosing formats and architectures that survive vendor death, pricing changes, and platform decay.

Privacy by Architecture

There is a phrase worth distinguishing at this point, because it clarifies the fundamental design difference between cloud-hosted and local-first software.

Privacy by policy means the platform commits, through terms of service and compliance certifications, not to misuse your data. Privacy by architecture means the data never reaches the platform in the first place. The distinction is the difference between a promise and a fact.

Cloud platforms offer privacy by policy. The quality of those policies varies. They are subject to jurisdictional override through legislation like the CLOUD Act. They are subject to revision through corporate acquisition—as when a publisher acquires a writing platform. They are subject to unilateral change through business model shifts. And they are subject to breach through the platform vulnerabilities that CVE-2024-45313 documented in Overleaf Server Pro: default configurations that allowed LaTeX compilation to run without sandboxing, giving users access to the container's filesystem and network environment.

Local-first systems offer privacy by architecture. Data that exists only on your machine cannot be subpoenaed from a server you do not own. It cannot be ingested into AI training pipelines whose scope you cannot audit. It cannot be exposed through a breach of infrastructure you have no visibility into. For research hospitals handling de-identified patient data, defense contractors managing engineering schematics, financial researchers documenting proprietary models, or any researcher operating under GDPR or institutional data governance requirements—the architectural property is not optional. It is a prerequisite.

The choice to compile locally is simultaneously a choice about data custody. When the compilation engine runs on your hardware, the document never travels. The LaTeX source never leaves. The bibliography, the figures, the embedded metadata—none of it moves unless you explicitly move it.

Where SonnetPulse Fits

The mature elements of the sovereign LaTeX stack—Tectonic for compilation, VS Code or TeXstudio for editing, Zotero for bibliography management, Git for collaboration and version control—address each layer of the workflow independently. They are well-maintained, actively developed, and capable of handling production academic work at any scale.

What remains as a friction point is integration. Each tool must be configured to communicate with the others. SyncTeX must be set up correctly between the editor and the PDF viewer. The build recipe must be written and maintained. When the toolchain breaks—because of an editor update, an OS change, a package conflict—the researcher must diagnose it.

SonnetPulse is NTXM's approach to this integration gap. It is built on the Tectonic engine, which means there is no TeX Live installation to manage and no package manager to run. It is architecturally offline-first, which means no account is required, no data is transmitted unless the user explicitly chooses synchronization, and no compile timeout exists. The PDF viewer and the editor share the same local process, which means SyncTeX navigation—clicking in the PDF to jump to source, and in the source to jump to the PDF—operates without network latency.

The scope of SonnetPulse is deliberately focused. It does not attempt to replicate every feature of every existing LaTeX editor. It does not require researchers to abandon their existing Git workflows or bibliography managers. It occupies the integration layer: the compiled environment that removes setup friction without introducing cloud dependency.

For researchers who have been managing the manual toolchain and want the friction removed, SonnetPulse is a coherent answer. For researchers moving from Overleaf who want the collaborative UI experience in an offline-first form, it provides a familiar surface without the structural liabilities. For institutional IT environments where a 9 GB TeX Live installation is not permitted but research workflows require LaTeX compilation, it offers a path that does not require administrator privileges or cloud access.

"

The document belongs to the person who wrote it, compiled on hardware they own, stored in formats that will outlive any vendor.

What SonnetPulse does not do is worth stating equally clearly, because the product's positioning is defined by what it refuses as much as by what it provides. It does not promise to compile arbitrarily complex documents in five seconds—compilation speed is a function of document complexity and local hardware, and honesty about this is more valuable than marketing claims. It does not offer real-time cloud collaboration as a feature—that would contradict its core architectural principle. It does not require subscription fees, because the offline-first model does not have recurring server costs to recover.

Frequently Asked Questions

What is the actual difference between local compilation and cloud compilation?

The differences are structural rather than cosmetic. Local compilation uses your machine's CPU, RAM, and storage directly, with no network round-trips, no resource sharing with other users, and no artificially imposed timeout. Cloud compilation submits your document to a remote server, waits in a queue, receives allocated resources from a shared pool, and must return the compiled PDF to your browser—all within whatever timeout the platform imposes. For simple documents, the difference is often invisible. For complex academic documents requiring multiple passes, the difference is the gap between a compile that finishes and one that times out.

Can I collaborate with co-authors who are still using Overleaf?

Yes. The .tex source files used by Overleaf are standard LaTeX source files. If your project is hosted in a Git repository, co-authors using Overleaf can connect Overleaf to the same repository through its Git integration feature. Changes pushed to the repository by local toolchain users appear in Overleaf for those who prefer the browser interface, and vice versa. This is a practical migration path that does not require all collaborators to change their workflows simultaneously.

What happens to my data when I compile locally?

Nothing leaves your machine. Local compilation reads from your filesystem and writes the resulting PDF to your filesystem. No telemetry is transmitted. No usage data is collected. Your document source, bibliography, and figures remain entirely under your control throughout the process.

Is offline LaTeX suitable for submitting to journals and conferences?

Yes. The output of a local LaTeX compilation is a PDF that is formally indistinguishable from the output of cloud compilation. Journal submission systems receive PDFs and, where required, LaTeX source files. The editor or workflow used to produce them is not visible and not relevant to the submission process. The LaTeX source itself can be submitted directly from your local filesystem.

What about packages that aren't in the standard distribution?

Modern engines like Tectonic retrieve packages as needed during compilation, caching them locally after the first download. Once cached, those packages are available offline indefinitely. Packages that are not available through the standard distribution bundle can be included manually by placing them in the project directory—a capability that cloud platforms often restrict for security reasons.

Does local-first LaTeX mean I cannot use cloud storage?

No. Local-first means your machine holds the canonical copy of your data. Cloud storage can be used for backup and synchronization without changing this relationship. A project compiled locally can be synchronized to Dropbox, stored in a private GitHub repository, or backed up to a self-hosted server. The difference is that you choose if, when, and where data is synchronized—the synchronization is not a prerequisite for the software to function.

Glossary

Tectonic

A modernized, self-contained LaTeX/TeX engine written in Rust. Operates as a single binary executable, retrieving required packages on demand rather than requiring a full TeX Live installation. Enables reproducible builds across machines by version-locking the package bundle.

SyncTeX

A synchronization protocol that connects a LaTeX editor and a PDF viewer, enabling bidirectional navigation: clicking in the PDF jumps to the corresponding source line, and vice versa. Requires configuration in traditional toolchains; integrated automatically in dedicated environments.

Local-First Software

Software architecture in which the user's device holds the canonical copy of data, with cloud synchronization as an optional feature rather than a prerequisite for operation. Formally articulated by Kleppmann et al. in 2019.

CRDT (Conflict-Free Replicated Data Type)

A data structure enabling multiple replicas to be edited independently and merged without conflicts. Used in collaboration systems to enable simultaneous editing without central server arbitration.

latexmk

A utility that automates the multi-pass LaTeX compilation process, re-running the engine as many times as necessary to resolve cross-references, bibliographies, and indices. Replaces manual sequential compilation commands.

CLOUD Act

US legislation requiring US-based technology companies to produce data in response to law enforcement requests, regardless of where the data is physically stored. Creates jurisdictional conflict with GDPR and other non-US data protection frameworks.

BibLaTeX / biber

A modern bibliography processing system for LaTeX, replacing the older BibTeX. biber is the processing backend for BibLaTeX, capable of handling complex bibliographies including non-Latin scripts, multiple author formats, and extensive customization.

enshittification

A term coined by Cory Doctorow describing the three-stage decay pattern of digital platforms: attract users with quality, then degrade service quality as users are captured, then maximize extraction from both users and business partners. Selected as 2023 Word of the Year by the American Dialect Society.

The Document Belongs to You

The question at the center of this is ultimately not about LaTeX editors or compilation engines or storage architectures. It is about who holds the authoritative copy of your intellectual work, and what happens to that work when the relationship with the platform changes.

Platform relationships change. Pricing changes. Terms of service change. Companies are acquired. Features are gated behind subscriptions. Services go down at the worst possible moments. The researchers who planned for these eventualities—who kept local copies, who maintained local toolchains, who treated the cloud editor as a convenience rather than an infrastructure dependency—experienced the Canvas incident and the Overleaf outages as minor inconveniences. The researchers who had fully externalized their workflows experienced them as crises.

The local-first movement's core insight is not anti-cloud. It is pro-resilience. The argument is not that cloud services are useless—it is that designing your workflow to function without them makes you more capable of using them wisely rather than dependently. A researcher who can compile locally is a researcher who chooses cloud collaboration because it is useful, not because they have no alternative.

The academic LaTeX ecosystem has arrived at a moment where the tools to support this approach are genuinely mature. Tectonic makes local compilation accessible without the TeX Live burden. VS Code with LaTeX Workshop makes local editing capable enough to replace the Overleaf experience for most workflows. Git provides collaboration infrastructure that is more powerful and more transparent than anything a cloud editor's version control can offer. And the privacy argument, once theoretical, is now backed by institutional action at the level of national governments.

The compilation happens on your machine. The PDF is yours. The source is yours. The bibliography is yours. The history of every edit is yours, in a format that will remain readable long after any of today's cloud platforms have changed beyond recognition.

That is what ownership looks like in practice. And increasingly, researchers who have spent time on the other side of this divide are choosing it.

"

NOTE: If you are in an institutional environment with restrictions on software installation, investigate whether your IT department can provide a managed local LaTeX environment or a self-hosted alternative. Many institutions have policies that enable this upon request, particularly given the increasing regulatory pressure around research data sovereignty.

"

INSIGHT: The single most effective data protection strategy for research documents containing sensitive data is also the simplest: compile locally, store locally, synchronize only to infrastructure you control. No policy document, compliance certification, or contractual guarantee offers the same structural guarantee as data that never leaves your filesystem.

This article draws on research compiled from community forums, institutional announcements, regulatory filings, IEEE publications, and technical documentation spanning 2020–2026. Where specific claims reference documented incidents or published studies, those sources are identified in the text.