Skip to content
flui.cloud

Framework templates

The hardest step for a new self-hosted application is not the deployment — it is the gap between “I have an idea in a framework” and “I have a repository that the platform can actually build and deploy”. Templates close that gap. One command produces a repository that already contains everything Flui needs to build, deploy and observe the resulting application; from that moment on, it is the user’s code.

What a template gives you

A Flui template is a real, working starting point for an application in a specific framework. When the platform creates a new repository from a template, the result is not a skeleton to fill in — it is a buildable, deployable application that you can clone, change, push, and watch deploy without writing any infrastructure file yourself.

In particular, every template repository comes with:

  • A Dockerfile that builds a production-ready image of the framework, using the framework’s idiomatic base.
  • A flui.yaml that declares the application: its name, the port it listens on, the healthcheck path, sensible defaults for resources and scaling.
  • A healthcheck endpoint wired in the framework’s own way — an API route in JavaScript fullstack frameworks, an actuator in Spring Boot, a view in Django, and so on — so the healthcheck the manifest points at actually answers from day one.
  • A build pipeline that the platform can drive end-to-end, triggered by a push to the repository.

The deploy from that point on is identical to any other Application: flui deploy reads the manifest, the build pipeline runs, the image lands on the cluster, the endpoint and the certificate are wired in.

The frameworks Flui covers

The set of supported frameworks spans the languages most self-hosted applications are written in — JavaScript and TypeScript fullstack and backend stacks, a frontend framework, a JVM backend, two Python backends, a .NET backend — plus a generic catch-all template for the cases none of the above fits.

The list is deliberately small. Each template is a real repository that someone has to maintain over time: the goal is to cover the common shapes without growing a long tail of variants. The exact set, with versions and command syntax, lives in the CLI reference.

What makes a repository Flui-compatible

A template is really just one example of a Flui-compatible repository — a repository the platform can find, build and deploy. The contract is small:

  • a Dockerfile that produces a runnable image,
  • a flui.yaml at the root that describes how the resulting application should run,
  • a working healthcheck endpoint matching what the manifest declares.

Anything that satisfies those three requirements is deployable through the same flow as a template-generated repository, even if no one calls it a “template”. A user who outgrows the official templates can fork one, edit it freely, or write their own from scratch — the platform does not care which path the repository came from, as long as the contract holds.

Where this chapter goes from here