Why not the whole of FOLIO?

There is an obvious question once Foundry can run several real FOLIO applications on a laptop:

Why not the whole of FOLIO?

The honest answer is that nothing in the current architecture prevents that in theory. Foundry is already separating the app shell, control plane, routing plane, identity, operational descriptors, and backend capability activation. That separation could be a good basis for a fully self-hostable FOLIO installation with substantially less overhead than many current local or hosted setups.

But that is not our main focus right now.

Our main focus is creating a sovereign home for the applications K-Int writes and maintains for the FOLIO ecosystem. We want to be able to offer those applications directly to libraries that are interested in specific vertical slices: ERM, Open Access, ILL, serials, and the other areas where K-Int has deep domain history.

That is different from trying to create a full ILS.

The whole of FOLIO is possible in theory

The reason this question is worth asking is that Foundry has changed the shape of the local runtime.

The current local workspace can run Licenses, Agreements, Open Access, Serials Management, and ILL through the same Lattice shell. Those apps are selected by Loom runtime state, loaded as module-federation artifacts, routed by Envoy, authenticated through Zitadel, and backed by real module services or platform support APIs.

That is a long way from a screenshot-only prototype.

If we kept widening that approach, a self-hosting path for more of FOLIO is easy to imagine:

• publish more FOLIO UI modules as reusable MFE artifacts;
• model more module backends and support interfaces in operational descriptors;
• let Loom select and activate capability versions for a workspace;
• let Envoy execute routing, auth policy, tenant headers, and compatibility transforms;
• keep platform support APIs behind foundry-platform-services instead of running a long tail of utility modules by default.

There are real advantages to that model. The app shell does not have to be rebuilt every time the app set changes. Published frontend artifacts can be immutable and reusable. The control plane can reason about activation and reconciliation explicitly. The gateway remains a gateway, not a product catalog or tenant database.

So yes: in theory, this might become a useful substrate for someone who wants to self-host FOLIO with a smaller operational footprint. If there is interest in that direction, we would be open to looking at it.

It is just not the problem we are choosing to solve first.

The problem we do want to solve first

K-Int has spent a long time working at the front edge of library systems: ERM, knowledge bases, license and agreement management, Open Access workflows, interlibrary loan, and serials. That history reaches back through KB+ and into the work we have contributed to the FOLIO ecosystem.

Those areas are still where many libraries have urgent problems.

But libraries do not all run the same ILS. Some run FOLIO. Some run Koha. Some run Evergreen. Some run hosted or commercial systems. Some have a mix of local and external services. If our specialist applications only make sense inside one complete platform deployment, then we make the adoption problem harder than it needs to be.

Foundry is an attempt to change that.

Instead of building another full ILS, we want a framework that lets K-Int applications run as focused library capabilities:

• standalone, where a library wants a self-hosted slice;
• alongside an existing FOLIO installation;
• as an extension to Koha, Evergreen, TIND, or another library system;
• behind provider-backed interfaces for users, organisations, catalog, settings, tags, and other platform surfaces.

That is why the current Open Access screenshot matters.

Open Access is not being baked into a new monolith. It is selected by workspace runtime state, loaded as an MFE, and connected through the same platform and routing contracts as the rest of the app suite.

That is the shape we want for ERM, OA, ILL, and serials.

Platform services are the abstraction layer

The container named foundry-platform-services is doing more than filling gaps for a demo.

It is the start of an abstract interface between K-Int applications and the different implementations of common library-system concepts: users, organisations, catalog data, settings, tags, acquisition units, and similar surfaces.

In a standalone Foundry workspace, those interfaces can be backed by local Foundry providers.

In a workspace extending FOLIO, they could be backed by FOLIO-compatible providers.

In a workspace extending Koha, Evergreen, TIND, or something else, they should eventually be backed by providers that know how to talk to those systems while presenting the same application-facing platform contract.

That is the important architectural bet. The apps should not each learn every ILS integration directly. They should call stable platform interfaces, and the provider binding should vary by workspace.

This puts us closer to where we wanted to be in the first place: working on the leading edge of library problems while allowing the underlying ILS projects and vendors to catch up in their own time.

Sustainability still matters

We remain deeply committed to open source.

We also need to find ways to make that commitment sustainable. Building and maintaining specialist library software takes long-term investment. If the only route to using that software is to adopt, host, upgrade, and operate a whole platform, the sustainability problem gets worse for everyone: libraries, vendors, maintainers, and contributors.

Foundry is part of our exploration of a different balance.

The aim is not to retreat from the FOLIO ecosystem. The aim is to make the best of our FOLIO-era work easier to run, easier to integrate, and easier to sustain.

If that eventually helps someone run the whole of FOLIO with less overhead, that would be interesting. But the immediate target is more specific:

Get K-Int’s ERM, Open Access, ILL, and serials applications working as standalone and integratable capabilities, without making libraries wait for a complete ILS replacement.

That is the answer to “why not the whole of FOLIO?”

Because we are not trying to solve cataloging and circulation first.

We are trying to serve the problems libraries are asking us to solve now.