Which product do I need?

Which product do I need?

DaisySuite Decision

Three products, one suite. Pick the product that owns the problem first.

DaisySuite works best when the boundaries stay sharp. Start with runtime, values, or typed YAML ownership based on the real engineering problem, not on whichever product sounds broadest.

Use DaisyCore

I need commands, menus, sidebars, tablists, and one runtime owner for the feature.

Start with DaisyCore

Use DaisySeries

I need canonical values and aliases for config-heavy modern Paper values like materials, sounds, biomes, attributes, particles, or more.

Start with DaisySeries

Use DaisyConfig

I need typed YAML, config lifecycle/versioning, module bundles, and clean config-backed text ownership.

Start with DaisyConfig

DaisySuite has three separate ownership layers: DaisyCore owns runtime systems, DaisySeries owns canonical values, and DaisyConfig owns typed YAML plus shared config state. The dependency chain still matters, but the first question is still which product actually owns your problem.

If your plugin needs all three layers together, skip the guesswork and follow Build the Normal Stack.

Related Product

Use DaisyCore when runtime systems are the problem

If the feature lives in commands, menus, sidebars, or tablists, DaisyCore is the default entrypoint.

Open DaisyCore docs

Related Product

Use DaisySeries when values are the problem

If you are about to write alias maps or lowercase enum serializers, start here.

Open DaisySeries docs

Related Product

Use DaisyConfig when YAML ownership is the problem

If config versioning, module layout, reload safety, and config shape are the pain point, DaisyConfig should own that layer.

Open DaisyConfig docs

Most plugins still start with DaisyCore

Start lower in the stack only when parsing or YAML lifecycle is clearly the actual source of complexity. Otherwise, begin with the runtime layer and add the lower products only when the feature genuinely needs them.