When building applications on edge runtimes like Cloudflare Workers, developers face strict environment constraints. Workers operate as V8 isolates—sandboxed environments that run JavaScript and WebAssembly but lack a traditional operating system or the ability to execute arbitrary native binaries. This creates a significant hurdle for tools like LaTeX, which are native machine code programs. LaTeX engines (such as `pdflatex` or `xelatex`) are designed to interact with a full OS, reading and writing numerous temporary files and shelling out to other programs. Because these requirements cannot be met within an isolate, the compilation process must be offloaded to a separate service, typically a container, accessible via HTTP.

To manage this offloading, the author chose Tectonic as the underlying engine. Unlike a standard TeX Live installation, which can occupy gigabytes of disk space, Tectonic is a self-contained program that fetches only the specific packages, fonts, and hyphenation patterns required for a given document on demand. This allows the container image to remain small while still supporting complex documents. Furthermore, Tectonic automatically handles the multiple passes required by LaTeX to resolve cross-references and bibliographies, simplifying the API for the edge app. To ensure security, the service uses the `--untrusted` flag and disables 'shell escape,' a feature that could otherwise allow a malicious LaTeX document to execute arbitrary shell commands on the host server.

Deploying this service involves specific security and infrastructure trade-offs. Because the container sits on a public URL, the author implemented a 'fail closed' security model: the service refuses to start unless a valid `COMPILE_TOKEN` is provided in the environment. This prevents unauthorized users from using the container as a free compute resource. Additionally, the service handles file management by creating unique, atomic temporary directories for each job using `mkdtemp`. This prevents collisions between concurrent requests sharing the same container instance. While the author considered using platform-specific authentication (like Google Cloud's signed identity tokens), they opted for a shared secret to maintain compatibility across different container hosts, illustrating a deliberate trade-off between maximum security and architectural portability.