Piral runs a frontend that other teams can ship into at runtime

A pilet is a module you ship on its own

The core concept is the pilet, and the README describes it in one paragraph. Piral enables you to create a modular frontend application that is extended at runtime with decoupled modules called pilets, leveraging a microfrontend architecture. A pilet can be developed independently and ships with the necessary code as well as all other relevant assets, and pilets are as independent of the host application as you want them to be, which makes them transferrable between different applications. That transferability is the reason to choose this style of microfrontend over the alternatives: a pilet built for one Piral application is not tied to it, so the same module can go into a second application without a rewrite.

What a pilet can do to the application it lands in

The feature list reads like a set of guarantees, and each one has a design consequence behind it. A pilet is capable of dynamically extending other pilets or using such an extension slots itself, so the extension model is recursive rather than a single host-and-plugin tree. A pilet can provide or use shared dependencies from other pilets, which means the runtime has a package mechanism rather than expecting every module to be self-contained. A pilet is isolated, developed and handled, and will never destroy your application, which is the property that makes a third party safe to let in. A pilet can be developed with any technology using a standard IDE, so a team does not have to adopt the framework's own component model. And a pilet can be updated and published within seconds, or rolled out or disabled dynamically to create self-forming applications.

The repository is a monorepo of packages and samples

Piral itself is developed as a monorepo, and the README warns that this repository may contain an overwhelming amount of information, which is why it recommends starting at the documentation site and working through the tutorials in order. The workspace manifest shows the shape, with the workspaces covering the converters, the framework, the initializers, the pages, the plugins, the samples, the tooling and the utilities. The samples are where the framework's variants live, and the build scripts name them: a minimal sample, a full Piral sample, a Piral core sample and a cross-framework sample, each with a watch and a build script. There is also a siteless build, which produces a bundle with no shell at all, and the build scripts use the `piral` CLI directly with a target directory and a type of release or emulator. The tooling is a mix of Lerna for orchestration and Nx, with both an `lerna.json` and an `nx.json` at the root.

Building the samples is a piral CLI invocation

The scripts show how the CLI is used, and the pattern is the same for every sample. A debug run points the CLI at an HTML entry point, and a build run adds a target directory and a type:

piral debug src/samples/minimal-piral/src/index.html
piral build src/samples/sample-piral/src/index.html --target dist/demo-full/index.html

The `debug` and `build` commands come from the framework's own tooling, so the CLI is installed as part of the workspace rather than fetched separately, and the `piral build` output can target a release bundle or an emulator build. The siteless variant is the more interesting script, because it builds the same entry point twice and copies the release output into the source tree before producing the emulator variant, which tells you the two outputs are the same application with different hosting assumptions. The site and the docs also have their own scripts, with `build:docs` and `watch:docs` fanning out through Lerna with the stream flag so the output is visible.

Contributing goes through a defined process

The contribution section points at a contributing guide for the development process, how to propose bugfixes and improvements, and how to build and test changes. There is a good first issues list for people getting their feet wet, with the note that those issues contain bugs of relatively limited scope. The repository structure is described in the README, with `docs` holding the user documentation, `src` holding the sources for all the developed packages, samples and pages, `test` holding the test setup and, in the future, system tests, and `tools` holding some of the internal tooling for building the different components, and each subdirectory carrying its own README. General usage questions are asked on the Discord or on StackOverflow with the piral tag rather than in GitHub issues, while issues are for bugs and feature suggestions, and there is a separate help translating the documentation with pull requests to a documentation branch.

The CI and release setup

The badges show the build running on Azure Pipelines against the develop branch, a FOSSA licence and security scan status, an uptime monitor for status.piral.io, and a CLA assistant. The Azure Pipelines configuration is in an `azure-pipelines.yml` at the root, and the default branch is develop rather than main, which is the usual convention for a project where the release branch is cut from development. The release history shows steady patch cadence on the 1.12 line, with 1.12.4 on 2026-09-11, 1.12.3 on 2026-08-18 and 1.12.2 on 2026-08-05, and the last push to the develop branch was on 2026-10-17. The licence is MIT with the file at the root, and there is a SECURITY.md alongside a CODE_OF_CONDUCT.md. The website is piral.io and the documentation is at docs.piral.io, with a status page at status.piral.io for the hosted service.

Editorial conclusion

Adopt Piral if you have several teams shipping into one frontend and need them to release independently, since the pilet model gives each team a deployable unit that does not have to be rebuilt into the host. Do not adopt it for a single team on a single product, because the runtime extension mechanism costs you a build pipeline per pilet and a host that can load them. Verify first which framework your pilets will target, since the microfrontend architecture is a set of adapters, and read the security policy before you let third parties register extensions at runtime.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. smapiot/piral on GitHub