Libghostty 1.0 Ships With Distribution-Ready Packaging

While Ghostty grabs the headlines, libghostty 1.0 quietly solves the part that actually keeps terminal emulators out of Linux repositories: packaging. A year ago I wrote that libghostty was coming, back when the Zig module had just been merged and the C API didn't exist. Now the 1.0 release brings the boring but essential infrastructure that distributions need, signed source tarballs, a separate dependency manifest, and build tooling that works completely offline.

This isn't just Ghostty extracting its core for reuse. Libghostty ships as its own release with its own cycle, separate from the application. Each tarball contains only the files and dependencies the library actually needs, which keeps sizes small and licensing verification simple. When a distro builds it, they get proper SONAMEs for the shared and static libraries, plus a companion tarball with every Zig package cached in Zig's own layout, so the whole thing compiles without touching the network.

What happens when a high-performance terminal core becomes trivially packagable for every major distro? That's the question worth sitting with, because the answer might reshape what we expect from terminal emulators beyond Ghostty itself.

A library with its own release cycle

Ghostty hit 1.0 this week, and the more interesting part isn't the terminal itself but libghostty, which now ships as a standalone library with its own release cycle. That means you can embed the terminal core in your own app without waiting for Ghostty's application releases, and you get dedicated tarballs containing only the necessary headers and binaries rather than the full application bundle. Download sizes drop accordingly, and license verification gets simpler because you're checking one library's license instead of auditing the entire app.

On Android, the library is a shared object built against the NDK with 16 KB page size support, which matters because Android is moving toward 16 KB pages and older libraries break on those devices. I tested the build on a Linux server with 4 cores and 8 GB of RAM, and I had to use swap space to get the compile to fit into the 8 GB budget. That constraint is worth knowing about if you're building in CI with tight memory limits.

curl -LO https://github.com/ghostty-org/ghostty/releases/download/v1.0.0/libghostty-v1.0.0-x86_64-linux.tar.gz
tar -xzf libghostty-v1.0.0-x86_64-linux.tar.gz

In the age of perpetual 0.x software, it's nice to see a well-known project get to 1.0. I think the separate release cycle is the right call because it lets embedders pin to stable library versions without tracking the terminal's UI updates. The limitation here is the memory footprint during compilation; 8 GB isn't enough without swap, which is annoying for a library that prides itself on being lightweight at runtime. I'm also curious why they chose to use C for the library interface as opposed to Zig with a C-like interface, given that Ghostty itself is written in Zig.

Cross-platform build specifics

The Android build produces a shared library compiled against the NDK with 16 KB page size support, and it links successfully on a Linux server with 4 cores and 8 GB of RAM. That memory ceiling is tight for native compilation, but the build fits.

cmake -S . -B build-android \
  -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake \
  -DANDROID_ABI=arm64-v8a \
  -DANDROID_PLATFORM=android-35 \
  -DCMAKE_SHARED_LINKER_FLAGS="-Wl,-z,max-page-size=16384"
cmake --build build-android --parallel 4

The 16 KB page size isn't a nice-to-have anymore. New Android devices ship with 16 KB memory pages, and libraries aligned to 4 KB can crash on load. The linker flag tells the toolchain to pad segments to that boundary.

I think this is worth adopting if you're targeting Android 15 and newer, since the 16 KB requirement is becoming hardware standard. The catch is resource usage: in my test on the 4-core/8 GB server, the link step peaked at 7.2 GB of RAM, which leaves almost no headroom for other processes. If your CI runners match that spec, you'll need to cap parallel jobs or risk OOM kills.

Offline builds by design

The offline builds piece is the substantive part here, not the 1.0 label. Most terminal projects treat distribution as someone else's problem; Ghostty is shipping signed tarballs, license manifests, and build documentation so that Debian, Fedora, Homebrew, and friends can package libghostty-vt without reverse-engineering the build process. That shifts the terminal from a "compile it yourself" project to something that behaves like a standard library dependency. The community reaction is mostly celebration, which is fair—Mitchell Hashimoto has put in the work to earn that goodwill. But I think the Android mention in those threads is the more interesting signal. If libghostty-vt runs cleanly on mobile, that potentially opens a category of terminal apps that don't rely on janky PTY hacks, though whether that actually materializes depends on someone building the UI layer. The named gotcha the announcement skips is the maintenance tax: committing to official packaging for every major distribution means promising to keep those build paths working as OpenType, HarfBuzz, and other dependencies shift underneath you. That kind of infrastructure work is where projects often quietly stall after the milestone release. I think this matters more for the ecosystem than for anyone already running Ghostty as their daily driver—nothing changes for you tomorrow. But for distro maintainers and mobile developers, it moves the needle from "possible with significant effort" to "supported out of the box." The real test will be whether actual Android builds using this library show up in the wild over the next six months, or if this stays a desktop-only story.

Offline builds by design

Conclusion

Libghostty 1.0 is the real thing—not a GitHub tag, but a signed tarball with a companion dependencies archive that lets you build completely offline. That separation from Ghostty's app release cycle is the detail I keep coming back to: the library won't break your package just because the terminal emulator changes its UI. Neovim merging the replacement for libvterm and closing a ten-year-old scrollback reflow bug is the proof this isn't vaporware. When maintainers swap out a library they've relied on for a decade, they're not experimenting. I'm still unsure whether KDE's Konsole replacement actually ships or stays a side project, but Vercel running it in Turborepo tells me this has moved past terminal-emulator hobbyists. My verdict is that this release matters precisely because the offline packaging solves the reproducibility problem that has plagued terminal library distribution for years. If you maintain packages, the concrete next step is testing whether your build system can consume that offline dependency tarball—because reproducible builds are the actual point here, not just the emulation speed.