Foundry has reached the point where it is useful to look at it as a running thing, not just an architecture sketch.
The increment is deliberately narrow: a FOLIO application, mod-licenses on the back end and ui-licenses on the front end, rendered in a completely standalone environment. This is not Okapi. It is not Eureka. It is a small, self-contained “just licenses” application that lets us test what independently deployable FOLIO services might feel like in practice.
Why this matters
FOLIO has long had the language of independently deployable microservices, but in practice an individual module often travels with a lot of surrounding platform. Even a focused app can need supporting services for things like settings, tags, tenant context, authentication, and UI composition before it becomes usable.
This experiment asks a more direct question: what would it take to run one coherent FOLIO capability on its own?
For Licenses, the answer is beginning to look like a smaller harbour around the module rather than a full platform deployment. The back-end support scaffold provides enough shape for mod-licenses to run without dragging in a broad set of non-domain utilities. Authentication is handled through Zitadel. The front end is loaded by an app shell, not built into it.
That distinction is important. Foundry is not only showing a familiar FOLIO screen in a different place. It is testing whether the boundaries around a module can become operational boundaries too.
The shell and the app
On the front end, the shell is responsible for tenant-level rendering, tenant resolution, and application loading. ui-licenses is wrapped and published independently as a single module, then loaded dynamically by the shell at runtime.
That removes a common source of cost in multi-tenant front-end delivery. Instead of minting and publishing a fresh front-end bundle every time a tenant configuration changes, the service can be deployed once and reused. Tenant branding, available modules, and module versions can be resolved from configuration.
Virtual or wildcard domains make this feel natural. A tenant-specific hostname can map to tenant-specific configuration while still using the same deployed shell. The shell decides what the tenant should see and which application module version should be loaded.
The app launcher is where the composition becomes visible. Licenses is not statically baked into the shell bundle. It is an available app for this tenant, resolved and loaded by the shell.
Licenses, but lighter
The point of using Licenses is not that Licenses itself is new. The point is that a recognisable FOLIO workflow is running without the usual platform envelope.
The search page is the first proof that this is more than a landing page. It is a real module screen, backed by mod-licenses, presented inside a shell that has no build-time dependency on the Licenses UI.
The new license flow extends that proof into write-side application behaviour. It gives us a better test of authentication, tenant context, module wiring, and the supporting scaffold around the back-end service.
What this changes
Foundry gives us a place to explore FOLIO applications as smaller, clearer units of deployment. A module can have enough surrounding infrastructure to be useful without being forced back into a large shared runtime. A front-end app can be packaged independently and selected dynamically. Tenant configuration can change without triggering a new front-end build for every tenant.
That is the interesting part of this increment. It starts to make “independently deployable” less of a packaging aspiration and more of an operational design constraint.
There is still plenty to learn. The scaffold has to prove that it can support more than one module shape. Tenant configuration needs to stay understandable as options grow. The runtime contract between shell and app needs to remain boring enough that independently published front-end modules do not become a new source of coupling.
For now, though, Foundry has crossed a useful line: a real FOLIO app is running on its own, with its own back end, its own dynamically loaded front end, and a shell that can serve multiple tenants without becoming a tenant-specific build product.