Skip to main content

Why Pagifier?

Because deploying to Kubernetes shouldn't require learning Kubernetes.

One file. That's the deal. No Dockerfiles, no YAML mountains, no Helm charts, no nginx configs. You write pagifier.toml; Pagifier builds the image, writes the manifests, and runs your app.

The entire developer experience:

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

(Prefer YAML? pagifier.yaml works identically — Pagifier accepts both, TOML first.)

zip -r app.zip . && curl -H "Authorization: Bearer $PAGIFIER_TOKEN" \
  -F config=@pagifier.toml -F archive=@app.zip \
  "https://pagifier.company.com/v1/applications/my-app/environments/prod/deployments?wait=true"
{"phase":"Building"}
{"phase":"Available","url":"https://my-app.company.com","done":true,"success":true}

That's it. Behind that one call: an in-cluster image build, security-hardened workloads, TLS ingress, health checks, autoscaling, and a rollback point.

Which hat are you wearing?​

I am deploying an application​

Head to the developer guide. You will create the small project file, choose Git observation or external CI, and debug your own builds without needing cluster access.

The fast routes are:

I am running the platform​

Head to platform operations. You own the cluster, storage, registry, templates, provider connections, tokens, and the guardrails developers should not have to think about.

Start with Installation, then connect Git and publish the templates and profiles that make the developer file pleasantly boring.

I just need one answer​

Project configuration · REST API · Custom resources · Web console

The house rules (there are only three)​

  1. Everything is explicit. Pagifier never reads package.json, never guesses ports, never detects frameworks. If something's missing, you get an error that says exactly what and where.
  2. Templates carry the boring parts. Your platform team publishes templates (react-static, nestjs, go-api, …) with the build commands, images, and caching already right — your file only says what's unique about your app. Anything a template sets, you can override.
  3. Every deploy is a rollback point. Uploads create immutable releases; rolling back is instant and never rebuilds.

What you get without asking​

Zero-downtime rollouts · TLS by default · hardened containers (non-root, read-only, no capabilities) · network policies · canary releases gated on real error rates (in prod, if your platform enables it) · preview environments per pull request · a web console · full audit history.