What Is Pilar Runtime

Pilar Runtime gives feature teams independent deployment, versioning, and ownership within the Pilar platform. Each feature is built, signed, and released by the team that owns it — the host discovers them at runtime.

Internal working name

The codebase and CLI tooling use the working name favn (e.g., @favn/feature-sdk, pnpm run favn, favn-runtime). "Pilar Runtime" is the product name — "favn" is what you'll see in code and package names.

Pilar Runtime addresses scaling and distribution scenarios where build-time composition creates friction — independent release cadence, per-feature delivery to customer clusters, and runtime isolation between teams. The long-term goal is a unified frontend architecture — both approaches are designed to converge.

	Pilar Embedded	Pilar Runtime
Composition	Build-time (Next.js monorepo)	Runtime (CDN artifact discovery)
Deployment	Single app image, all features together	Per-feature static asset packages, independent release
Best for	Tight integration, shared types, RSC	Independent teams, high feature count, customer clusters

Pilar Runtime is designed around two constraints: teams must be able to publish independently, and customer deployments must work through the existing SMUD-GitOps pull model without requiring direct access to customer clusters.

Why the platform looks complex

At first glance, Pilar Runtime can look more complex than a traditional shared frontend or a simple CDN loader. That is a fair reaction, but the important point is why that complexity exists.

In this domain, the floor of complexity is already high:

• hospital deployments need deterministic rollout and rollback behavior
• customer deployments already operate through SMUD-GitOps workflows
• the platform must handle feature delivery and runtime activation safely without pushing that burden onto domain teams
• the same artifact model should transition cleanly to cloud CDN delivery later
• partial failure handling matters more than developer convenience

Pilar Runtime does not remove that complexity. It concentrates it into platform-owned infrastructure: the host, artifact verification, loader behavior, release metadata, and operational runbooks.

That is the trade-off. The platform takes on the deployment and runtime complexity so feature teams can stay focused on domain work:

• teams build features and declare dependencies
• Team Pilar owns the host, shared chart, signing, artifact delivery, and lifecycle behavior
• teams should not have to become experts in rollout mechanics, runtime activation, readiness semantics, or cloud-transition concerns

If the platform does its job well, the complexity remains real but mostly invisible to domain teams.

Core idea

Pilar Runtime separates concerns into three layers:

1. Pilar Runtime Server (codebase: favn-host) Handles discovery, verification, routing, shell rendering, and RPC transport.

2. Domain Features (featureType: "domain") Route-owning features that orchestrate workflows and can own data fetching.

3. Facet Modules (featureType: "facet") Reusable embedded UI units that receive data/props and emit user intent.

Legacy aliases are still accepted:

• application -> domain
• module -> facet

Framework position

Pilar Runtime should not be presented as "the React platform." The host ultimately serves browser assets: JavaScript, CSS, and HTML-facing behavior described through the manifest contract.

Today, the platform is clearly React-oriented:

• the shared dependency model currently ships React and related packages from the host
• the feature SDK and examples are React-first
• the current team workflow assumes client-focused SPA-style features

But the important architectural point is that the runtime contract is broader than React. If the ecosystem changes later, the host does not fundamentally depend on React as such. It depends on a feature producing valid browser assets and fitting the Pilar Runtime manifest, routing, and RPC model.

That means the long-term portability story is:

• the platform is JavaScript/browser-asset based
• React is the current default, not the permanent architectural requirement
• another client-focused framework could work if it fits the same artifact and integration contract

This should be framed carefully. Pilar Runtime is not framework-neutral in today's tooling, but it is more framework-tolerant than a host that is tightly bound to one UI runtime.

Why it exists

Pilar Embedded works well for teams that benefit from monorepo integration, shared types, and server rendering. As team count grows, build-time composition hits inherent trade-offs: linear build times, release coordination across 40+ teams, and a single failure domain.

Pilar Runtime moves composition to runtime to address these:

• signed artifact discovery at runtime,
• operationally safe version/channel control,
• strict host boundary (transport/security/runtime), with business logic owned by teams.

How it differs from common approaches

Area	Pilar Runtime	Module Federation	Podium	single-spa
Primary unit	Manifested feature artifact (domain/facet)	Bundler remotes/containers	Server-rendered fragments/podlets	Client apps registered in root config
Discovery model	Runtime discovery from local artifacts and/or remote index	Remote container URLs configured at build/runtime	Layout + podlet registration	Runtime registration/import maps
Built-in trust chain	Yes: signed release index + signed manifest + integrity checks	No built-in signature chain by default	No built-in signature chain by default	No built-in signature chain by default
Routing ownership	Host resolves domain features by prefix; facets are embedded	App-defined, usually router/bundler-driven	Server layout/router-driven	Root config + client router integration
Shared deps model	Host import map + declared shared requirements	Federation shared scope negotiation	App/runtime dependent	App/runtime dependent
Server function transport	First-class /rpc/:feature/:fn with host context + proxy/module modes	Not a built-in concept	Not a built-in concept	Not a built-in concept
Team authorization model	Feature-owned business authz (host handles authn/transport)	Team/application-defined	Team/application-defined	Team/application-defined

Mental model

Scope and boundaries

• Backend services remain separate — each team owns their backend repos and Helm charts. Pilar Runtime handles frontend composition and delivery.
• Authorization is feature-owned — the host enforces authentication and transport security. Business authorization decisions belong to feature teams, in their own server functions and services.

When to use Pilar Runtime vs Pilar Embedded

Pilar Embedded is the default. Use it unless you have a concrete reason not to.

Consider Pilar Runtime when a team hits a specific limitation:

• Independent release cadence is blocked by the monorepo deploy train
• The feature needs OCI-based distribution to customer clusters via SMUD-GitOps
• The feature doesn't fit the Next.js App Router model
• High feature churn makes shared deploy coordination a real bottleneck

The architecture comparison covers the trade-offs between the two approaches in more detail.

Read next

• Getting Started
• Reuse and Data Flow
• Architecture Overview