Lua lives in FreeBSD base, but not the Lua you install from ports.

It is flua: FreeBSD Lua. A private interpreter built for base system tasks, shipped in /usr/libexec, and treated like a trusted wrench rather than a general-purpose toy.

You may be tempted to use it for everything. Resist. flua is not a lifestyle. It is a tool the base system uses when shell scripts become too brittle and C becomes too heavy.

What flua is:

• A FreeBSD-flavored Lua interpreter intended for base system use.
• Maintained in lockstep with base system needs.
• Not guaranteed to be a fully compatible drop-in for whatever Lua you want today.

Why it exists:

Shell is good at orchestration. Shell is bad at data structures. When you need real parsing, real tables, and non-fragile logic, Lua becomes the narrow bridge between shell and C.

The FreeBSD base system wants that bridge without dragging the whole ports world into the bootstrap chain. So flua is the compromise: small, tight, and inside the fence.

Where it lives:

• /usr/libexec/flua

Not on PATH by default. That is not an accident. It is a signal: this is a base system instrument, not your public API.

What it ships with:

flua includes a curated set of modules, and those modules can change as base needs evolve. For example, a UCL module exists for JSON and related formats, because base needs to generate and consume structured data without relying on external tools.

If you want a stable, wide module ecosystem, use the normal Lua from ports. If you want the base system to remain bootstrappable and predictable, you accept flua’s narrowness.

The decree:

flua is a gate inside a gate. It is for FreeBSD itself. If your script is part of base, you may wield it. If not, you should install the regular Lua and live in the open world.

Base stays clean. The rest of the kingdom stays flexible.

That is the point.

— Kim Jong Rails, Supreme Leader of the Republic of Derails