Skip to main content

Your app, your side of the deal

You own the application and one small config file. Pagifier handles the Kubernetes-shaped machinery behind it.

That split is intentional:

You ownYour platform team owns
Application source and testsPagifier, Kubernetes, storage, and the registry
The project config: runtime, command, port, and app-specific needsApproved templates, runtime images, security defaults, and environment policy
When an artifact is ready to promoteGit connections, webhook credentials, scoped tokens, and infrastructure access
Fixing application build or readiness errorsKeeping the deployment platform healthy and observable

You should not need cloud credentials, kubectl, a Docker socket, or a home-grown pile of deployment YAML.

Pick how code reaches Pagifier​

There are two supported doors. They end at the same immutable Release, so pick the one that fits your team.

Let Pagifier watch Git​

This is the easiest route when your platform team has enabled the native Git observer. Pagifier watches a protected branch, builds on application repository changes, and deploys when a release pin changes in the operations repository.

Start with Deploy from Git.

Call Pagifier from CI​

Keep this route when CI already owns your release workflow or needs to perform work before handing over the archive. The integration is one authenticated API call; GitHub Actions and Jenkins wrappers hide even that.

Start with CI integration.

Two files with similar names​

Most applications only need the version 1 project file:

app.pagifier.toml
version = 1
name = "frontend"
template = "react-static"
environment = "prod"
ingress = "frontend.company.com"

It describes the application that will run.

Git-observed delivery also uses a version 2 control manifest, normally named pagifier.toml. It says which repositories to watch and when to build or deploy. Templates generate this file, so you generally review and commit it rather than write it from scratch.

A sensible reading order​

  1. Getting started for the five-minute deploy.
  2. Deploy from Git or CI integration for automation.
  3. Configuration reference when the template needs an app-specific override.
  4. A worked tutorial: static site, backend API, or monorepo.
  5. Debugging deploys when something is having a bad day.