Skip to content
flui.cloud

The build pipeline, today and tomorrow

For an application built from source, there is a step between the user pushing code and a container running on the cluster: the build. Where that build runs is not a detail — it shapes the cost model, what fails when something breaks, and what credentials need to live where.

This chapter is about the build pipeline that turns a kind: Application manifest plus a source repository into a deployable image — what it does today, what it deliberately doesn’t try to do, and where the design is heading.

Today: build at the source

Today’s pipeline runs alongside the user’s source repository, on the CI service of the platform that hosts it. When a deploy of a kind: Application is triggered, the platform writes (or refreshes) a build workflow inside the user’s repository, makes sure the workflow has the credentials it needs to push the resulting image to a container registry, and watches the run through to completion. When the run finishes, the image is in the registry and the deploy step picks it up and rolls it onto the cluster.

The shape of the pipeline is the user’s CI tool’s shape — its runners, its logs, its reruns, its UI. Flui drives it; it does not host it.

Why an external pipeline

Building images is heavy work — compilation, dependency download, layer composition, image push. Doing that work on the same cluster that is also serving production traffic creates a noisy-neighbour problem at exactly the wrong moment. Running it outside the cluster avoids that problem entirely.

The CI services Flui integrates with also bring three things for free: a mature build cache layer that makes repeated builds fast, generous time budgets that for a typical user mean the build infrastructure is genuinely free, and a standard debugging surface the user already knows — when a build fails, there is a run page with logs, the user opens it and reads. Flui does not have to reinvent any of that.

The trade-offs

A few honest costs that come with this choice:

  • External dependency. If the CI service is down, new deploys cannot land. Running applications keep running and the observability stack stays up — but the deploy path is gated on a service Flui does not control.
  • Credentials in the user’s CI. Pushing to the registry requires a credential, and that credential lives where the workflow runs. The user has to be comfortable trusting that surface with it.
  • Latency floor. Running the build elsewhere puts a real lower bound on how fast the deploy loop can close. For tight inner-loop iteration, the build time on whichever runner the CI picks is the floor.
  • Coupled to one CI today. The current integration is specific to one CI service; other CI services need a parallel integration, which is one of the directions the next section describes.

Where the design is heading

Two directions are on the roadmap, both aiming at the same property: the user’s manifest never has to know which pipeline ran the build.

  • Other CI/CD systems. The current single integration is the first one, not the only one. The roadmap covers other CI services as additional backends, with the platform picking the right one for the installation without changing the application model or the manifest.
  • A self-hosted alternative. For air-gapped or disconnected installations, for compliance environments where build traces cannot leave a controlled perimeter, and for teams that prefer to keep all their infrastructure on hardware they own, the build can run inside the installation itself — pipeline and optional registry, end-to-end inside the user’s control plane.

Both moves are deliberate substitutions inside the build pipeline, not a rewrite of the deploy contract. The user-facing shape — kind: Application produces an image, the image deploys to a cluster, the cluster runs the workload — is the same regardless of which pipeline drew the lines underneath.

Where this chapter goes from here

  • The app concept — what the build pipeline produces, once the image is on the cluster.
  • Catalog vs application — why the build pipeline matters only for kind: Application, and not for kind: CatalogApp.
  • CLI: Applications — the command-by-command reference for inspecting builds and managing image versions.