Skip to content
Flui Documentation

Framework templates

For a new self-hosted application, the hard step usually comes before the deployment: getting from an idea in a framework to a repository the platform can build and deploy. Templates cover that step. One command produces a repository that already contains everything Flui needs to build, deploy and observe the application. From then on, the code is yours.

What a template gives you

A Flui template is a working starting point for an application in a specific framework. When the platform creates a repository from a template, you get a buildable, deployable application that you can clone, change, push and watch deploy without writing any infrastructure file yourself.

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, and 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 answers from day one.
  • A build pipeline that Flui writes into the repository on the first deploy and drives end to end, triggered by a push.

From there the deploy works like any other Application: flui deploy reads the manifest, the build pipeline runs, the image lands on the cluster, and the endpoint and certificate are wired in.

The first deploy, and every push after it

The first push of a template becomes a running application. What the pushes after it do is up to you.

Every push triggers a build. What a successful build does next depends on one setting.

  • The first deploy is unaffected. The application is not live yet, so the finished build rolls straight out.
  • After that, rolling out is opt-in, one application at a time. It is off unless someone turns it on. While it is off, a successful build is recorded as an available version and waits for someone to trigger a deploy.

Two commands cover the waiting versions:

  • flui app versions <app> lists the image versions the registry holds for that application, and which one is deployed.
  • flui app redeploy <app> <tag-or-digest> rolls one of them out, without rebuilding anything.

Pushing a commit and shipping to production are two different intentions, and a template repository is where they are easiest to confuse: the first push is meant to go live, the fiftieth usually is not.

The switch lives on the application: flui app auto-deploy <app> --on (or --off), and without a flag it shows the current setting. The dashboard shows the setting as an Auto-deploy on push badge on the application’s Releases tab, but does not change it.

The frameworks Flui covers

The supported frameworks span the languages most self-hosted applications are written in: JavaScript and TypeScript fullstack and backend stacks, two frontend frameworks, two static-site generators, a JVM backend, two Python backends and a .NET backend. A generic catch-all template covers the cases none of these fits.

The list is kept small because each template is a real repository that someone has to maintain. The goal is to cover the common shapes without a long tail of variants. The exact set, with versions and command syntax, is in the CLI reference.

What makes a repository Flui-compatible

A template is 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.

Any repository that meets those three requirements deploys through the same flow as a template-generated one. If you outgrow the official templates, you can fork one, edit it freely, or write your own from scratch. The platform does not care where the repository came from, as long as the contract holds.

Where this chapter goes from here