Helix Framework Documentation

Ecosystem

Templates

Project templates that give new services and libraries a maintainable starting point aligned with Helix conventions.

What Templates Are

Helix templates are the fastest way to start with a project shape that already reflects framework conventions. Instead of hand-assembling build logic, dependency baselines, and initial project structure, you start from a curated template and then grow into plugins, starters, and libraries as the project matures.

Templates are a good fit when you want:

  • a service or library scaffold that already matches Helix conventions
  • a repeatable starting point across teams and repositories
  • a project that can be generated, inspected, and versioned from the CLI

Choose a Template

These are the templates currently available out of the box through the Helix CLI, and the catalog will continue to grow as more templates are published.

springboot

Best default for teams evaluating Helix with a single Spring Boot service.

  • Good first template for framework evaluation
  • Simple service shape with room to expand later
  • Best starting point for most new backend services

springboot-multi-module

Use when the service should start with multiple modules from day one.

  • Better fit for larger teams or layered service designs
  • Useful when API, domain, and app modules should stay distinct
  • Stronger choice for platform-backed service baselines

springboot-postgres

Choose this when database integration is part of the initial project shape.

  • Helpful for services that start with PostgreSQL from the beginning
  • Good fit for data-heavy CRUD or workflow services
  • Reduces the amount of persistence setup teams do by hand

java-lib

Start here for a reusable JVM module instead of an application.

  • Good for internal shared libraries
  • Useful when teams want a clean dependency module, not a service
  • Pairs naturally with the Helix plugin and library surfaces

java-cli

Use for Picocli-based or command-line oriented Java applications.

  • Good for internal tooling and automation utilities
  • Better fit than service templates when no HTTP app is needed
  • Aligns well with the published Helix CLI plugin surface

java-app

Start with a plain Java application when Spring Boot is not the right abstraction.

  • Useful for non-web JVM apps and internal runtimes
  • Keeps the starting point lighter than a service template
  • Works well when teams want Helix conventions without a Boot app shell

Inspect Before Generating

The CLI gives you a few ways to inspect templates before you commit to one.

Discovery

List every published template

helix template list

Discovery

Inspect one template in more detail

helix template info springboot
helix template versions springboot

Use template list when you want the broad catalog, and template info / template versions when you want to compare one template’s metadata, packaging, and published versions more closely.

Generate a Project

Once you know which template you want, generate a project with either the short alias or the explicit template command.

Generation

Generate a Spring Boot service

helix init springboot billing-service

Generation

Generate with an explicit template version

helix template init springboot billing-service --version 1.2.0

Generation

Preview generation without writing files

helix template init springboot billing-service --dry-run

Helix resolves the template version, downloads the archive if needed, prompts for template values, applies replacements, and writes template lock metadata into the generated project.

Common Workflows

Start with `springboot`

Best for most teams exploring the framework for the first time.

Recommended next steps:

  • Generate a service
  • Run the default Gradle workflow
  • Use the Libraries and Plugins pages to expand selectively

Use `springboot-multi-module`

Better when the initial project should already express module boundaries.

Recommended next steps:

  • Keep API and implementation modules separate
  • Adopt plugins for consistent multi-module build behavior
  • Use starters only where Spring Boot integration adds value

Use `java-lib`

Best when the outcome is a reusable dependency rather than a runnable app.

Recommended next steps:

  • Document the library’s scope clearly
  • Keep dependencies focused and minimal
  • Link consumers to the right Helix libraries and plugins

Use `java-cli`

Ideal for internal developer tools, automation utilities, and shell-facing apps.

Recommended next steps:

  • Inspect the Java CLI plugin documentation
  • Keep command behavior and help output tight
  • Use completion support and config patterns from the main Helix CLI page

Suggested Reading