# Tectonic: a self-contained TeX engine that carries its own support files > Tectonic is a TeX/LaTeX engine forked from XeTeX and built on TeXLive, written mostly in C with a Rust crate for embedding. It is aimed at people who want a reproducible LaTeX build without a full TeX Live installation, and at developers who want to call a typesetting engine from Rust. **tectonic-typesetting/tectonic** — A modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive. - Repository: https://github.com/tectonic-typesetting/tectonic - Website: https://tectonic-typesetting.github.io/ - Stars: 5,135 · Forks: 220 - Language: C - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/tectonic-typesetting-tectonic ## The problem Tectonic targets: a TeX engine that carries its own support files A conventional TeX Live installation is large and its package set changes with each release, so two machines can produce different output from the same .tex file. Tectonic takes the opposite position. It is described in its README as a "modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive," and the self-contained part is the distinguishing claim. The engine is forked from the XeTeX extension to the classic Web2C implementation of TeX, and it uses the TeXLive distribution of support files. The target user is not someone who wants a graphical editor. It is someone who wants to compile a document from a script, a container or a continuous integration job, and who wants the support files to arrive as part of the process rather than as a prerequisite installed months earlier. The README is explicit that the page is aimed at people interested in how Tectonic works under the hood, and directs anyone who just wants to compile documents to the project website. That split matters: the repository is the engine, and the documentation for using it lives elsewhere. ## How the engine is put together: XeTeX semantics, TeXLive bundles, a Rust workspace The core code derives from XeTeX, and the project states that it strives to track and maintain compatibility with upstream as much as possible while accepting that source-level divergence is inevitable. To keep track of what it is compatible with, the repository carries a Git submodule named reference_sources that links to a staging repository tracking the XeTeX source used as a reference. The README says the submodule holds the most recent code whose semantics are guaranteed to be expressed in Tectonic, and that you do not need to clone it to build. That is a deliberate design choice: compatibility is defined against a moving reference, not against a fixed release of XeTeX. The build itself is a Cargo workspace. The Cargo.toml lists members including crates/engine_xetex, crates/engine_bibtex, crates/engine_xdvipdfmx, crates/engine_spx2html, crates/bundles, crates/docmodel, crates/pdf_io, crates/xetex_layout and a set of bridge crates for flate, fontconfig, freetype2, graphite2, harfbuzz, icu and png. That layout tells you where the seams are: the TeX engine, the bibliography engine, the DVI-to-PDF driver, the bundle machinery and the font layout layer are separate crates. The package is published as the tectonic crate, and the same Cargo.toml declares the license as MIT. The repository LICENSE file is the authoritative text; the GitHub metadata reports the license as NOASSERTION, which means the platform could not classify it automatically, not that the project is unlicensed. ## Installing Tectonic and compiling a first document The README does not contain install commands. It points to the installation page of the project book at tectonic-typesetting.github.io/book/latest/installation/, and to a packaging status badge on repology.org, which is where you should look for a distribution package for your system. The crate is published on crates.io as tectonic, and the README directs anyone who wants to build the crate to CARGO_README.md in the repository. Because the README gives no command to run, there is no install snippet to copy here; take the steps from the book page rather than from this article. What the README does give is the shape of the tool: a single engine that you point at a document, with the support files resolved by the engine rather than preinstalled. If you would rather not install anything locally, the README lists two GitHub Actions that wrap the engine: setup-tectonic, which the README says supports caching and optionally biber, and compile-latex, contributed by Vinay Sharma and described as powered by Tectonic. For embedding, the crate documentation is at docs.rs/tectonic. The repository also carries a bundles/ directory and a dist/ directory at the top level, which is where the project keeps its bundle and distribution machinery; the README does not explain how to build a custom bundle from them. ## Where Tectonic is the wrong tool The self-contained model has a cost that the README does not spell out. Because support files come from TeXLive bundles rather than from a tree you installed and pinned, a document that depends on a package outside the bundle, or on a local .sty file that expects a particular TeX Live layout, is a plausible failure case. The README does not document an offline or air-gapped bundle workflow, so if your build environment has no network access you should confirm that story before adopting. A second limitation is compatibility. The project tracks XeTeX semantics rather than promising bug-for-bug source equivalence, and the reference_sources submodule is described as the most recent code whose semantics are guaranteed to be expressed in Tectonic. That wording implies a moving target: a change landed in XeTeX after the pinned reference may not yet behave the same way here. If your document relies on TeX Live behaviour that is not XeTeX-compatible to begin with, Tectonic is not the engine to reach for, because it is a XeTeX fork and not a pdfTeX or LuaTeX replacement. Finally, the repository README is a developer document. Anyone expecting a user manual in the repository will not find one; the book and website are separate. ## Tectonic compared with a full TeX Live installation The honest alternative is TeX Live itself, installed and pinned. The difference is in where the support files live and who decides when they change. A TeX Live installation puts a fixed tree on disk, and the package manager decides what is present; reproducibility comes from freezing that tree. Tectonic inverts this: the engine is a single tool that resolves support files as part of the build, so the input to a build is the document plus whatever the bundle resolution picks up. That makes a fresh machine or a container much cheaper to set up, and it makes the build depend on the bundle resolution path rather than on a local tree. The trade-off is control. With TeX Live you can inspect exactly which version of which package is installed and pin it. With Tectonic, the README describes the bundle concept and the bundles/ directory but does not document how a user pins a bundle version, so if byte-identical output across time is a requirement, that is the question to answer before migrating. The second real alternative is not another engine but another packaging of the same one: the two GitHub Actions listed in the README let you use Tectonic inside a workflow without installing it on the runner, which is a different operational choice from installing the crate. ## Maintenance, releases and what the repository tells you The repository is not archived, and the last push was on 2026-08-01. That is recent enough that the project cannot be described as abandoned. The release list is unusual and worth reading carefully: the most recent entry is a continuous deployment release dated 2026-07-31, alongside component releases for tectonic_xetex_layout at 0.3.4 and tectonic_pdf_io at 0.5.3, both dated 2026-07-27. The workspace crates are versioned individually, and the top-level package in Cargo.toml carries the version 0.0.0-dev.0 with a comment saying the version is assigned with cranko. So the version you consume depends on which artifact you consume: a crate from the workspace, the tectonic CLI crate, or a continuous build. Upgrading means watching two streams, the component crates and the continuous release, rather than a single semantic version. The repository includes a CHANGELOG.md at the top level, which the README also links on the release branch, and that is the file to read before an upgrade. On licensing, Cargo.toml declares MIT for the package, and the repository contains a LICENSE file. The GitHub metadata reports NOASSERTION, which is a classification failure rather than a licence term. Because the engine is derived from XeTeX and uses TeXLive support files, the licence situation for what you redistribute is not something this article can settle; read the LICENSE file and the upstream licences before shipping a bundle. ## Conclusion Adopt Tectonic if you compile LaTeX in CI, want a single engine that pulls its own support files, or need to call a TeX engine from Rust. Do not adopt it if your workflow depends on a pinned, fully offline TeX Live tree or on packages the bundle does not carry, since the README points to the website and book for installation and does not document an offline bundle workflow. Before committing, verify the CLI against one of your real documents, check the licence situation for the version you install, and read the changelog to see how the continuous release stream is versioned. ## FAQ ### How do I install Tectonic? The README does not list install commands; it points to the installation page of the project book at tectonic-typesetting.github.io/book/latest/installation/ and to a repology.org packaging status badge. The crate is published on crates.io as tectonic, and the README directs people who want to build the crate to CARGO_README.md. ### How do I use Tectonic to compile a LaTeX document? The README does not document the command line. It points to the project website and the book for people who want to compile TeX documents, and describes the repository page as aimed at how Tectonic works under the hood. ### Is Tectonic a fork of XeTeX? Yes. The README describes Tectonic as powered by XeTeX and TeXLive, and the Cargo.toml description says it is forked from the XeTeX extension to the classic Web2C implementation of TeX. The repository keeps a reference_sources submodule pointing at a staging repository that tracks the XeTeX source used as a reference. ### Can I use Tectonic in GitHub Actions? The README lists two actions: setup-tectonic, which it says supports caching and optionally biber, and compile-latex, contributed by Vinay Sharma and described as powered by Tectonic. Both are linked from the README's technical ecosystem section. ### What licence is Tectonic under? The Cargo.toml declares the package license as MIT and the repository contains a LICENSE file, while the GitHub metadata reports NOASSERTION, meaning the platform could not classify it automatically. Because the engine derives from XeTeX and uses TeXLive support files, read the LICENSE file and upstream licences before redistributing a bundle. ## Sources - [Issues](https://github.com/tectonic-typesetting/tectonic/issues) - [Project website](https://tectonic-typesetting.github.io/) - [README](https://github.com/tectonic-typesetting/tectonic/blob/master/README.md) - [Releases](https://github.com/tectonic-typesetting/tectonic/releases) - [tectonic-typesetting/tectonic on GitHub](https://github.com/tectonic-typesetting/tectonic) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tectonic-typesetting-tectonic