What If Your Project Starter Knew Exactly What You Needed

Moeid Heidari — Tue, 07 Jul 2026 19:59:25 +0000

Introducing kik generate: schema driven plates on Kikplate

By Moeid Heidari · 8 min read · Jun 22, 2026

Kikplate started as a simple idea. A plate is a project template backed by a real GitHub repository, and the CLI lets you pull one down in seconds. That part hasn't changed. What has changed is how a plate describes itself and how the CLI turns that description into a working project on your machine.

The new feature is called generate. It is built around a typed schema inside the plate manifest, a CLI command that reads that schema and renders every templated file in the repository, and a renamed CLI binary. This article walks through all of it: the new manifest file, the schema tab on the plate page, the generate command and its flags, a full walkthrough using a real plate, and what the migration away from the old manifest looks like.

From kikplate.yaml to plate.yaml

Every plate used to be defined by a single file at the root of its repository called kikplate.yaml. That file carried only descriptive metadata: a name, description, category, owner, tags, and, once a submission was approved, a verification token. The CLI would clone the repository, strip that file out, and hand you the rest of the contents as your new project. There was no concept of variables, no conditional files, and nothing for the platform to render. Cloning was the whole mechanism.

The new manifest is called plate.yaml. It carries everything kikplate.yaml used to carry, plus a schema block that declares the variables a plate accepts, a modules block for toggling optional pieces of the template on or off, and a files block that maps every output path in the generated project to a template source. In short, kikplate.yaml described a plate. plate.yaml describes a generator.

You do not need to throw away an existing plate to adopt this. Kikplate still reads kikplate.yaml today so that owners can migrate at their own pace. That support is temporary, though, and it will be removed in a future release. If you maintain a plate, the practical move is to add a plate.yaml file now, even a minimal one, rather than waiting for the cutover.

Anatomy of a plate.yaml file

The clearest way to see the new format is to look at a real plate. The nginx http server starter plate publishes a minimal, production-ready NGINX static server, and its plate.yaml looks like this:

name: nginx-http-server-starter
owner: kikplate-public
verification_token: d4864f00-8988-42bf-aa1d-54ea18146f76
description: Minimal production-ready NGINX static HTTP server with modular config and clean structure.
version: 1.0.0

category: backend

tags:
  - nginx
  - http
  - static
  - starter
  - boilerplate
  - web-server

schema:
  projectName:
    type: string
    default: nginx-http-starter
  projectDescription:
    type: string
    default: Minimal static server starter with clean structure and production-ready NGINX config.
  kikplateSlug:
    type: string
    default: nginx-http-starter
  kikplateBadgeColor:
    type: string
    default: 0366d6
  localPort:
    type: int
    default: 8080
  containerPort:
    type: int
    default: 80
  containerName:
    type: string
    default: anginx-http-starter
  nginxImage:
    type: string
    default: nginx:stable-alpine
  workerConnections:
    type: int
    default: 1024
  keepaliveTimeout:
    type: int
    default: 65
  gzipEnabled:
    type: bool
    default: true
  gzipMinLength:
    type: int
    default: 1024
  localRoot:
    type: string
    default: ./public
  containerRoot:
    type: string
    default: /usr/share/nginx/html
  prodCacheExpires:
    type: string
    default: 30d
  prodCacheMaxAge:
    type: int
    default: 2592000

modules:
  docker:
    enabled: true
  cacheHeaders:
    enabled: true

files:
  - path: .dockerignore
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/.dockerignore.tmpl
    condition: modules.docker.enabled
  - path: .editorconfig
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/.editorconfig.tmpl
  - path: .gitignore
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/.gitignore.tmpl
  - path: LICENSE
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/LICENSE.tmpl
  - path: README.md
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/README.md.tmpl
  - path: conf.d/active.conf
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/conf.d/active.conf.tmpl
  - path: conf.d/dev.conf
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/conf.d/dev.conf.tmpl
  - path: conf.d/prod.conf
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/conf.d/prod.conf.tmpl
  - path: docker-compose.yaml
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/docker-compose.yaml.tmpl
    condition: modules.docker.enabled
  - path: dockerFile
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/dockerFile.tmpl
    condition: modules.docker.enabled
  - path: mime.types
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/mime.types.tmpl
  - path: nginx.conf
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/nginx.conf.tmpl
  - path: public/index.html
    template: https://raw.githubusercontent.com/kikplate/nginx-http-server-starter/main/templates/public/index.html.tmpl

A few things are worth calling out.

Everything above schema is the same metadata you already know from kikplate.yaml: name, owner, description, category, tags, and the verification token issued during submission.
The schema block is new. Each key is a variable the plate exposes, with a type (string, int, or bool seen here) and a default value. These are the values a consumer of the plate can override at generation time.
The modules block groups related toggles together. Here, the docker module controls whether Docker-related files get generated at all, and is referenced from the files block as a condition.
The files block is the actual generator definition. Each entry maps an output path in the new project to a template file in the plate's own templates directory, written with the .tmpl extension so the engine knows it needs rendering rather than a plain copy. Some entries carry a condition, which is evaluated against the modules block, so an output file is only produced when its module is enabled.

This is what makes generate fundamentally different from the old clone-and-strip approach. The CLI is no longer just copying files. It is reading a schema, applying your values and module choices on top of the defaults, and rendering each template into the matching output path.

The schema tab on the plate page

On kikplate.dev, a plate page now has a tab dedicated to its schema. It lists every variable declared in plate.yaml along with its type and default value, so you can see exactly what a plate expects before you ever touch a terminal.

The CLI is now `kik`

The CLI binary itself has been renamed. What used to be invoked as kikplate is now invoked as kik. Every subcommand you already know — search, describe, submit, verify, and the rest — still exists under the new root command. The headline addition is the generate subcommand, which is what actually exercises the new schema.

Installing the CLI

The install paths follow the same mechanisms Kikplate has always used: a Homebrew tap on macOS and Linux, a Scoop bucket on Windows, release archives for any platform, or building from source with Go. Only the binary name has changed, from kikplate to kik.

macOS and Linux, via Homebrew

brew tap kikplate/kikplate
brew install kik

Windows, via Scoop

scoop bucket add kikplate https://github.com/kikplate/scoop-bucket.git
scoop install kik

Manual install from a release archive, any platform

Download the archive that matches your platform from the project's GitHub Releases page, then install the binary onto your PATH.

# Linux or macOS
tar -xzf kik-<version>-linux-amd64.tar.gz
sudo install kik-<version>-linux-amd64 /usr/local/bin/kik

# Windows, PowerShell
Expand-Archive .\kik-<version>-windows-amd64.zip -DestinationPath .
Move-Item .\kik-<version>-windows-amd64.exe kik.exe
# add the folder containing kik.exe to PATH

Build from source

git clone https://github.com/kikplate/kikplate.git
cd kikplate/cli
go build -o kik .
sudo mv kik /usr/local/bin/kik

Once installed, confirm it works:

kik --help

Walking through kik generate

The generate command supports two modes. You can point it at a plate.yaml sitting on disk, which is the natural workflow for a plate author iterating on their own template, or you can point it at a published plate by its slug, which is the natural workflow for someone consuming a plate from the registry. Both modes accept a values file that overrides whatever defaults the schema declares.

Step 1: pick or inspect a plate

Browse kikplate.dev and open a plate page to read its schema tab, or use the CLI to search and read the manifest directly from the repository. We will use nginx-http-server-starter as our example throughout.

Step 2: write a values file

Create a values.yaml file with only the keys you want to override. Anything you leave out falls back to the default declared in the plate's schema.

projectName: my-static-site
projectDescription: A small static site served by NGINX, generated from a Kikplate plate
localPort: 9090
nginxImage: nginx:stable-alpine
gzipEnabled: true
prodCacheExpires: 7d

Step 3: generate from a local checkout of the template

If you have cloned the plate's repository, or you are the author working inside it, point generate at the directory and tell it where to write the result:

kik generate --template . -f values.yaml --output-dir ./generated-project

The --template flag takes a path to a directory containing a plate.yaml. The -f flag takes the values file from step 2. The --output-dir flag is where the rendered project lands.

Step 4: generate from the published plate by slug

If you simply want to consume the plate without cloning anything yourself, drop the --template flag and pass the plate's slug instead:

kik generate nginx-http-starter -f values.yaml

This pulls the same plate.yaml and template set from the registry's source of truth — your repository — and renders it the same way the local mode does.

Both invocations evaluate the modules block, so if you wanted to skip Docker support entirely you would set modules.docker.enabled to false in your values file, and every conditioned file in the files block tied to that module simply would not be written.

For the exhaustive list of flags, including anything added after this article was written, run:

kik generate --help

Step 5: run the generated project

For this particular plate, the generated output is a ready-to-serve NGINX project. Enter the directory and start the server with the included config:

cd generated-project
nginx -c $(pwd)/nginx.conf -p $(pwd)

Open http://localhost:9090, or whichever port you set in localPort, in your browser.

Migrating an existing plate

If you maintain a plate that still only has a kikplate.yaml, here is the practical path.

Keep kikplate.yaml in place for now. Kikplate still reads it, so nothing breaks today.
Add a plate.yaml alongside it. Carry over name, owner, description, category, tags, and the verification token unchanged.
Decide which parts of your repository should be parameterized, and move them into a templates directory with a .tmpl extension on each file.
Build out the schema block for every variable those templates reference, giving each one a sensible default so generate works out of the box with no values file at all.
If any part of the repository is optional, group it behind a key in the modules block and add a condition on the matching files entries.
Once plate.yaml is in place and tested with kik generate --template ., remove kikplate.yaml. Support for it will go away in an upcoming release, so there is no advantage to leaving it around once plate.yaml is verified to work.

The two files can coexist during this transition, which is the whole point of the gradual rollout. There is no hard cutover date forcing every plate to migrate overnight, but there is also no reason to wait until the deprecation lands to start.

Closing thoughts

The shift from kikplate.yaml to plate.yaml, and from a clone-based scaffold to a schema-driven generate, changes what a plate actually is. It used to be a repository you copied. Now it is a small, typed program: declare your variables, declare your optional modules, declare which files depend on which, and let kik generate do the rendering. If you publish plates, this is worth adopting early. If you consume them, kik generate -f values.yaml is now the fastest path from a plate you found on kikplate.dev to a project running on your machine.

kikplate.dev

Crossview: Finally Seeing What’s Really Happening in Your Crossplane Control Plane

Moeid Heidari — Thu, 05 Feb 2026 20:26:35 +0000

If you’ve ever worked with Crossplane, you probably recognize this situation:

You apply a claim.

Resources get created somewhere.

And then you’re left stitching together YAML, kubectl output, and mental models to understand what’s actually going on.

That gap is exactly why Crossview exists.

What is Crossview?

Crossview is an open‑source UI dashboard for Crossplane that helps you visualize, explore, and understand your Crossplane‑managed infrastructure. It provides focused tooling for Crossplane workflows instead of generic Kubernetes resources, letting you see the things that matter without piecing them together manually.

Key Features

Crossview already delivers significant capabilities out of the box:

Real‑Time Resource Watching — Monitor any Kubernetes resource with live updates via Kubernetes informers and WebSockets.
Multi‑Cluster Support — Manage and switch between multiple Kubernetes contexts seamlessly from a single interface.
Resource Visualization — Browse and visualize Crossplane resources, including providers, XRDs, compositions, claims, and more.
Resource Details — View comprehensive information like status conditions, metadata, events, and relationships for each resource.
Authentication & Authorization — Support for OIDC and SAML authentication, integrating with identity providers such as Auth0, Okta, Azure AD, and others.
High‑Performance Backend — Built with Go using the Gin framework for optimal performance and efficient API interactions.

Crossview already gives you a true visual control plane experience tailored for Crossplane — so you don’t have to translate mental models into YAML every time you want to answer a question about infrastructure state.

Why We Built It

Crossplane is powerful, but its abstraction can make day‑to‑day operations harder than they should be.

Simple questions like:

Why is this composite not ready?
Which managed resource failed?
What does this claim actually create?

often require jumping between multiple commands and outputs.

Crossview reduces that cognitive load and makes the control plane easier to operate and reason about.

Who Is It For?

Crossview is useful for:

Platform engineers running Crossplane in production
Teams onboarding users to platforms built on Crossplane
Anyone who wants better visibility into Crossplane‑managed infrastructure

If you’ve ever felt blind while debugging Crossplane, Crossview is built for you.

Open Source and Community‑Driven

Crossview is fully open source, and community feedback plays a big role in shaping the project.

GitHub: https://github.com/corpobit/crossview
Docs and Helm charts are available via the repo and Artifact Hub.

Feedback, issues, and contributions are all welcome.

Final Thoughts

The goal of Crossview is simple: make Crossplane infrastructure visible, understandable, and easier to operate. It already ships with real‑time watching, multi‑cluster support, rich resource details, and modern authentication integrations — giving you a dashboard that truly complements CLI workflows.

If you’re using Crossplane, I’d love to hear:

What’s the hardest part to debug today?
What visibility do you wish you had?

Let’s improve the Crossplane experience together.

DEV Community: Moeid Heidari