You don't build a framework with Forge. You build your app — the Kernel is the small core you start from, and capabilities are the components you select, or write, to give that app the behaviors it needs. This page is about what a capability is; the catalog is where you browse and choose them.
What. A capability is a self-contained component that plugs into the Kernel and adds one piece of behavior — a database, an ORM, authentication, a view engine, deployment tooling. A capability is infrastructure you choose, not a stack you inherit. Your app is your code: the business logic, the features, the domain. The Kernel and its capabilities are the materials you build with; your own modules and app code are the product.
Why. Because you shouldn't inherit a stack you didn't ask for — and you shouldn't pay the price of a full framework when you only need a piece of one. Not building a web app? Then you don't pull in a router or a view engine. Building a worker or a CLI tool? The Kernel alone is enough. You choose the capabilities your app actually needs, write the ones it doesn't have, and assemble them into the app you want. It only starts to look like a framework once you've taken the Kernel and plugged in a handful of capabilities — which is fine, because then it's your stack, shaped by your choices.
How. Each capability is a folder with
an entry file that carries its
#[Module] metadata — its
order (when it loads), its
type (descriptive), and whether it's
core (loaded separately, after the normal
modules). The Kernel discovers, orders, and loads
them. Install a capability through the package
manager, or drop it into one of your module roots
yourself; the details of building one live in
Core Concepts.
Technically there's no difference — the Kernel scans
and loads capabilities/ and
modules/ identically. The distinction is
convention, not mechanism: it's about intent and
namespace, and it's not enforced.
| Folder | Default Namespace | Intent |
|---|---|---|
capabilities/ |
Capability\ |
Reusable building-block primitives
(like ForgeHtmx). The recommended
home for primitives.
|
modules/ |
Modules\ |
App features and most current capabilities (still there during a gradual migration). |
Most primitives still live in modules/
until they're migrated;
capabilities/ForgeHtmx is the reference
for the target layout. Use whichever fits — mixed
layouts are fine.
Every capability, grouped by the role it plays — pick one and read its own page.
Open the Catalog →