One CLI for the whole lifecycle: build, run, inspect, cross-compile — plus first-class editor support.
| Goal | Command |
|---|---|
| Portable image (runs anywhere with the runtime) | plugfy build app.plug -o app.fy |
| …with a native accelerator for this host | plugfy build app.plug --native-slice |
| …with accelerators for several platforms | plugfy build app.plug --native-slice --target win-x64,linux-x64 |
| Run (auto-selects native / JIT / VM) | plugfy run app.fy |
| Run a flow | plugfy run app.flow |
| Standalone native binary | plugfy native app.plug --release |
| One binary per platform | plugfy native app.plug --target win-x64,linux-x64,osx-arm64 |
| Build a whole project | plugfy build App.project.plugfy |
| Build a whole project natively | plugfy native App.project.plugfy |
See what's inside a .fy | plugfy inspect app.fy |
| Explain a flow's parallel waves | plugfy explain app.flow |
| Export a flow's graph | plugfy flow-graph app.flow --dot |
| List / add cross targets | plugfy target list · plugfy target add linux-arm64 |
.fyA .fy is Plugfy's portable binary module — the "assembly" of the ecosystem: typed bytecode + a metadata manifest, optionally carrying per-OS native slices. It is compiled, not interpreted, on the hot path — the ReadyToRun model.
.fy with a plugfy runtime and it runs on any OS/arch the runtime is ported to.plugfy inspect shows what the module needs from the world without executing it.No single mainstream platform gives both layers in one artifact: a .jar can't go native, a Go/Rust binary can't run on a foreign OS, GraalVM native-image throws the portable fallback away. The .fy keeps both.
The runtime picks the fastest tier available, transparently:
A per-platform machine-code accelerator embedded in the .fy. Loads only where its target triple is ABI-valid; sealed against the toolchain that built it.
Hot code compiled at run time where a native slice for the host doesn't exist.
The portable floor: the typed-bytecode interpreter that runs everywhere, always available as fallback.
Cross-built slices are resilient: a target with no cross-toolchain available is skipped, and the image still runs there via JIT/VM. The runner never needs a Rust toolchain — rustc is only used (optionally) at build time.
A project manifest (App.project.plugfy) declares the deliverable: name, type (app or lib), dependencies and default targets. Building produces a predictable bin/ layout — bin/App.fy plus bin/libraries/… — and plugfy native compiles the whole project graph through the same fan-out.
The VS Code extension gives the full experience:
.plug, .flow and .fy — instant TextMate grammar, refined by semantic tokens once the language server attaches.plugfy-lsp): completion, diagnostics, navigation — with automatic toolchain resolution (workspace plugfy-version.yaml, a managed download, or your PATH).