ContentLIBRE — home

PROJECT PATTERNS

Different projects.
The same freedom to adapt.

A content foundation for teams who want to shape the implementation around the work—not the other way around.

Explore the foundation Read the developer guide

Three ways a team could approach it.

Confirm scope

A content service that fits your application.

01 · Developers & Integrators

Use the typed API and content foundation as part of a larger system. Keep public representations intentionally small and let your own integration code translate business-specific requirements.

What it needs:

  • Review API module contracts and authentication.
  • Define the fields each audience may receive.
  • Verify release support for the selected site modules.
Explore the API
Confirm scope

A reusable foundation, not a fixed experience.

02 · Agencies & Delivery Teams

Structure reusable project code and content alongside deployment-owned configuration. Reuse the foundation while keeping branding, integrations and operational choices specific to each client.

What it needs:

  • Use explicit feature assemblies for each deployment.
  • Treat multi-site and authoring scope as release-specific.
  • Budget for a tailored authoring experience.
Plan your customization
Confirm scope

More control over the long-term direction.

03 · Businesses & Platform Teams

Evaluate an Apache 2.0–licensed foundation without making one supplier’s service the only route forward. Plan ownership of operations, change management and any maintained fork from the start.

What it needs:

  • Assess security and backup responsibilities.
  • Confirm required capabilities before adoption.
  • Separate lifecycle proposals from released behavior.
Understand the open-source model

Start with a fit assessment.

Need approval workflows, private drafts, scheduled publication or recoverable deletion? Those are part of the lifecycle design and are not established as implemented. Need clustering, full-text search or document parsing? The documented starter does not provide those as a default solution. Make those requirements explicit before selecting a release.

Bring your requirements. Keep your options.

The architecture and status pages are the best starting points for a technical evaluation.

Architecture Capability status