DEV Community: Moeid Heidari

Production-Ready Docker Compose Collection with kikplate

Moeid Heidari — Fri, 17 Jul 2026 10:26:54 +0000

Docker Compose Plates: Reusable Infrastructure Stacks with kikplate

Infrastructure setup is one of the most repeated tasks in software development. Every new project needs a database, a cache, a message broker, or an observability stack. Teams copy configurations from old projects, adjust port numbers, forget to add health checks, use unofficial images, and eventually end up with inconsistent setups across their environments.

This article walks through a curated collection of twenty Docker Compose plates built for the kikplate template generation system. Each plate is a parameterised, versioned, composable unit that generates a production-ready stack from a single command.

Repository
Kikplate.dev

What is kikplate?

kikplate is a developer toolchain for generating project files from versioned, schema-driven templates.

A plate lives on its own Git branch. It defines:

A typed schema of input variables
Optional feature modules
A set of template files

Templates are fetched from GitHub, rendered with the provided values, and written to a local output directory.

Install on macOS and Linux

brew tap kikplate/homebrew-kikplate
brew install --cask kik

Install on Windows

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

The Plate Format

Every plate in the collection follows the same directory structure:

plate.yaml          schema, modules, and file definitions
values.yaml         default values for all schema variables
templates/
    docker-compose.yml.tmpl     main compose template
    .env.tmpl                   secrets template
    README.md.tmpl              usage documentation
    ...                         additional config files where needed

The plate.yaml file acts as the manifest.

Example: the PostgreSQL plate.

name: postgres
owner: kikplate-public
description: PostgreSQL 16 database with optional pgAdmin 4 web interface,
  persistent named volumes, health checks, and bridge network isolation.
version: 1.0.0
category: database

tags:
  - postgres
  - postgresql
  - database
  - pgadmin
  - docker-compose

schema:
  projectName:
    type: string
    default: postgres

  postgresVersion:
    type: string
    default: "16"

  postgresUser:
    type: string
    default: app

  postgresDb:
    type: string
    default: app

  postgresPort:
    type: int
    default: 5432

  timezone:
    type: string
    default: UTC

  sharedBuffers:
    type: string
    default: "128MB"

  maxConnections:
    type: int
    default: 100

  pgadminVersion:
    type: string
    default: "8"

  pgadminEmail:
    type: string
    default: admin@example.com

  pgadminPort:
    type: int
    default: 5050

modules:
  pgadmin:
    enabled: true

files:
  - path: docker-compose.yml
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/postgres/templates/docker-compose.yml.tmpl

  - path: .env
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/postgres/templates/.env.tmpl

  - path: README.md
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/postgres/templates/README.md.tmpl

Schema

The schema section defines every configurable value, including:

Type
Default value
Validation rules (when applicable)

Modules

The modules section defines optional capabilities that can be enabled or disabled during generation.

Files

The files section specifies every generated output file and the remote template that should be rendered.

values.yaml

The values.yaml file is a flat copy of all schema defaults and serves as the primary customization point.

projectName: "postgres"
postgresVersion: "16"
postgresUser: "app"
postgresDb: "app"
postgresPort: 5432
timezone: "UTC"
sharedBuffers: "128MB"
maxConnections: 100
pgadminVersion: "8"
pgadminEmail: "admin@example.com"
pgadminPort: 5050

modules:
  pgadmin:
    enabled: true

What Gets Generated

Running:

kik generate kikplate-public/postgres

produces three files.

docker-compose.yml

The Compose file is rendered from the template. Image versions, container names, ports, command flags, network names, and optional services are generated from the provided schema values.

services:
  postgres:
    image: postgres:16-alpine
    container_name: myapp-postgres
    restart: unless-stopped
    stop_grace_period: 30s
    security_opt:
      - no-new-privileges:true
    env_file:
      - .env
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGTZ: UTC
    command: >
      postgres
        -c shared_buffers=128MB
        -c max_connections=100
        -c timezone=UTC
        -c log_timezone=UTC
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    networks:
      - db_net

  pgadmin:
    image: dpage/pgadmin4:8
    container_name: myapp-pgadmin
    restart: unless-stopped
    stop_grace_period: 30s
    security_opt:
      - no-new-privileges:true
    env_file:
      - .env
    environment:
      PGADMIN_DEFAULT_EMAIL: ${PGADMIN_EMAIL}
      PGADMIN_DEFAULT_PASSWORD: ${PGADMIN_PASSWORD}
      PGADMIN_CONFIG_ENHANCED_COOKIE_PROTECTION: "True"
      PGADMIN_LISTEN_PORT: 80
    ports:
      - "5050:80"
    volumes:
      - pgadmin_data:/var/lib/pgadmin
    depends_on:
      postgres:
        condition: service_healthy
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    networks:
      - db_net

volumes:
  postgres_data:
  pgadmin_data:

networks:
  db_net:
    driver: bridge

.env

Secrets and sensitive values are generated into a separate environment file.

Placeholder values make it obvious what should be changed before a deployment.

POSTGRES_USER=app
POSTGRES_PASSWORD=changeme
POSTGRES_DB=app

PGADMIN_EMAIL=admin@example.com
PGADMIN_PASSWORD=changeme

README.md

A project-specific README is generated alongside the stack.

The rendered documentation includes:

Startup instructions
Service URLs
Port mappings
Connection strings
Operational guidance

All values are generated using the parameters provided during plate generation.

Why Use Plates?

Instead of copying Compose files between projects, teams can generate consistent infrastructure stacks from a controlled source.

Benefits include:

Versioned infrastructure definitions
Standardised health checks
Consistent security settings
Reusable configuration patterns
Optional feature modules
Built-in documentation generation
Reduced setup time for new projects
Easier maintenance across teams

Every generated stack follows the same design principles and can be reproduced at any time from its original plate version.

The Collection

The repository currently contains twenty Docker Compose plates organised into five categories.

Each plate defines:

A service stack
Schema-driven configuration
Optional modules
Generated documentation
Environment templates

Each row in the collection documents:

The plate slug
The generated Docker Compose services
Available optional modules

This allows teams to quickly select the required infrastructure stack and generate a production-ready environment with a single command.

Database

Backend

DevOps

Security

Other

Architecture and Composition

The diagram below shows all twenty plates and the composition relationships between them. Solid arrows indicate a default-enabled composition. Dashed arrows indicate an optional module.

How Composition Works

Many infrastructure stacks depend on other services. For example, Keycloak typically requires a PostgreSQL database.

Instead of duplicating database definitions, kikplate supports plate composition, allowing one plate to reuse templates from another plate.

The Keycloak plate composes the PostgreSQL plate by referencing its templates directly in plate.yaml.

modules:
  postgres:
    enabled: true

  pgadmin:
    enabled: false

files:
  - path: docker-compose.yml
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/keycloak/templates/docker-compose.yml.tmpl

  - path: docker-compose.postgres.yml
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/postgres/templates/docker-compose.yml.tmpl
    condition: modules.postgres.enabled

  - path: .env
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/keycloak/templates/.env.tmpl

  - path: README.md
    template: https://raw.githubusercontent.com/kikplate/docker-compose-plates/keycloak/templates/README.md.tmpl

When modules.postgres.enabled is set to true, kikplate:

Fetches the PostgreSQL template from the PostgreSQL plate branch.
Renders it using the values provided to the Keycloak plate.
Generates a dedicated docker-compose.postgres.yml file.
Includes that generated Compose file in the final deployment.

This approach enables reusable infrastructure building blocks without copying configuration between plates.

Shared Schema

To ensure the PostgreSQL template always receives valid input values, the Keycloak plate includes all PostgreSQL-related variables in its own schema.

schema:
  projectName:
    type: string
    default: keycloak

  keycloakVersion:
    type: string
    default: "24.0"

  postgresVersion:
    type: string
    default: "16"

  postgresPort:
    type: int
    default: 5432

  timezone:
    type: string
    default: UTC

  sharedBuffers:
    type: string
    default: "128MB"

  maxConnections:
    type: int
    default: 100

  pgadminVersion:
    type: string
    default: "8"

  pgadminPort:
    type: int
    default: 5050

  pgadminEmail:
    type: string
    default: admin@example.com

  keycloakPort:
    type: int
    default: 8080

  keycloakLogLevel:
    type: string
    default: INFO

Because all required PostgreSQL variables are available in the schema, the PostgreSQL templates can be rendered independently without requiring any additional configuration.

Docker Compose Includes

The Keycloak Compose template uses Docker Compose's include capability to compose the generated PostgreSQL stack into the final deployment.

{{ if .modules.postgres.enabled }}
include:
  - docker-compose.postgres.yml
{{ end }}

services:
  keycloak:
    image: quay.io/keycloak/keycloak:{{ .keycloakVersion }}
    container_name: {{ .projectName }}-keycloak
    restart: unless-stopped

    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: ${POSTGRES_USER}
      KC_DB_PASSWORD: ${POSTGRES_PASSWORD}
      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}

    ports:
      - "{{ .keycloakPort }}:8080"

    depends_on:
      postgres:
        condition: service_healthy

    networks:
      - kc_net
      - db_net

networks:
  kc_net:
    driver: bridge

When PostgreSQL is enabled:

docker-compose.postgres.yml is generated.
The Keycloak stack includes it automatically.
The PostgreSQL service exposes the db_net network.
The Keycloak container joins db_net.
Keycloak can connect to PostgreSQL using the hostname postgres.
Startup order is controlled through health checks and depends_on.

This creates a loosely coupled but fully integrated deployment.

Generated Output

Generating the Keycloak plate produces the following files:

generated/
├── docker-compose.yml
├── docker-compose.postgres.yml
├── .env
└── README.md

docker-compose.yml

Contains:

The Keycloak service
Compose include directives
Keycloak-specific networking and configuration

docker-compose.postgres.yml

Contains:

PostgreSQL service
Persistent volumes
Health checks
Logging configuration
db_net network

.env

Contains shared credentials used by both services.

POSTGRES_USER=app
POSTGRES_PASSWORD=changeme
POSTGRES_DB=keycloak

KEYCLOAK_ADMIN=admin
KEYCLOAK_ADMIN_PASSWORD=changeme

README.md

Contains deployment-specific documentation including:

Startup instructions
Access URLs
Port mappings
Login credentials guidance

Benefits of Composition

Plate composition provides several advantages:

Reuse existing infrastructure definitions
Eliminate configuration duplication
Keep service definitions independent
Share common variables across related stacks
Generate modular Docker Compose deployments
Simplify maintenance and versioning
Allow optional dependencies through modules

Instead of embedding PostgreSQL directly into the Keycloak plate, the Keycloak plate composes the PostgreSQL plate as a reusable building block. This keeps both plates focused on a single responsibility while still allowing them to work together as a complete deployment.

Composition Examples

The same composition pattern is used throughout the collection.

Examples include:

WordPress → composes MySQL, optionally Redis.
n8n → composes PostgreSQL, optionally Redis.
Grafana and observability stacks → optionally compose PostgreSQL as the backend database.

Each plate remains focused on a single responsibility while reusing infrastructure components from other plates where appropriate.

Generating a Plate

The simplest generation flow uses interactive prompts and accepts default values.

kik generate kikplate-public/postgres

Generate from a Values File

To avoid prompts entirely, provide a values file.

kik generate kikplate-public/postgres -f values.yaml

Every plate includes a values.yaml file containing all schema variables with default values.

Teams typically:

Generate a values file.
Customise it for their environment.
Commit it into source control.
Regenerate infrastructure at any time from the committed values.

This makes infrastructure reproducible and eliminates manual configuration.

Override Individual Values

Specific values can be overridden directly on the command line.

kik generate kikplate-public/postgres \
  --set projectName=myapp \
  --set postgresPort=5433

Generate into a Specific Directory

Generated files can be written to a dedicated location.

kik generate kikplate-public/postgres \
  --output-dir ./infra/postgres

Generate Directly to a Repository

Generated output can also be pushed directly into a remote repository.

kik generate kikplate-public/postgres \
  -f values.yaml \
  --repo https://github.com/yourorg/infra.git

Consistency Across Every Plate

Regardless of the service being provisioned, every plate follows the same operational and security standards.

Secrets Management

No passwords or secrets are embedded in templates.

Generated secrets are written to a separate .env file with placeholder values.

POSTGRES_PASSWORD=changeme
REDIS_PASSWORD=changeme

Developers replace these values before starting the stack.

Health Checks

Every stateful service defines a health check.

Dependent services wait until dependencies become healthy before starting.

depends_on:
  postgres:
    condition: service_healthy

This guarantees a reliable startup sequence during:

docker compose up

Logging

Every service uses the Docker json-file logging driver.

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

Benefits include:

Log rotation
Predictable disk usage
Consistent behaviour across stacks

Network Isolation

Each plate defines its own named Docker bridge network.

networks:
  app_net:
    driver: bridge

Services communicate only within their assigned network.

When plates are composed together, the dependent service joins the required networks to enable controlled communication between components.

Security Options

All containers run with:

security_opt:
  - no-new-privileges:true

Additional Linux capabilities are not granted unless the application explicitly requires them.

For example:

cap_add:
  - IPC_LOCK

is included for Vault because its functionality depends on memory locking.

Graceful Shutdown

Every container defines a shutdown grace period.

stop_grace_period: 30s

This allows databases, queues, and brokers to:

Complete pending writes
Flush data safely
Exit cleanly

before container termination.

Official Images

Every plate uses official vendor-maintained container images.

Examples include:

postgres
mysql
redis
grafana
prometheus
quay.io/keycloak/keycloak

Images are version-pinned through schema defaults and can be overridden at generation time.

No community-maintained wrappers or floating latest tags are used.

How Teams Use This

Small Development Teams

A backend team starts a new service and requires:

PostgreSQL
Redis

Without automation, the team typically:

Copies an old docker-compose.yml.
Adjusts service names.
Changes ports.
Updates image versions.
Fixes broken health checks.
Troubleshoots startup issues.

With kikplate:

kik generate kikplate-public/postgres \
  -f postgres-values.yaml \
  --output-dir ./infra/postgres

kik generate kikplate-public/redis \
  -f redis-values.yaml \
  --output-dir ./infra/redis

Two commands produce two standardised infrastructure stacks.

The generated configurations are:

Current
Version-controlled
Health-checked
Secure by default
Reproducible

Platform Teams

Platform engineering teams often need to standardise infrastructure across dozens of services.

A common approach is to maintain approved values files.

When a new service is created, developers:

Select an approved plate.
Generate infrastructure using the approved values file.
Commit the generated output alongside their application.

This ensures every service begins with infrastructure aligned to organisational standards.

Updating Existing Deployments

When a plate receives updates such as:

New image versions
Security improvements
Additional configuration options
Operational enhancements

teams simply regenerate the files.

kik generate kikplate-public/postgres -f values.yaml

The generated changes can be reviewed using normal source control workflows.

The plate remains the single source of truth for infrastructure configuration.

Repository Structure

The Docker Compose Plates collection is hosted at:

Docker Compose Plates Repository

The repository uses a branch-per-plate model.

Individual Plate Branches

Each plate resides on its own branch.

Examples:

postgres
redis
mysql
keycloak
wordpress
n8n
grafana

Each branch contains:

plate.yaml
values.yaml
templates/

plate.yaml

Defines:

Schema
Modules
Template files
Metadata

values.yaml

Contains default values for all schema variables.

templates/

Contains the source templates that are rendered during generation.

Examples:

templates/
├── docker-compose.yml.tmpl
├── .env.tmpl
├── README.md.tmpl
└── additional configuration templates

Main Branch

The main branch contains:

Documentation
Guides
The plate catalogue
Repository metadata

It acts as the public entry point for the collection.

All Branch

The all branch contains every plate as a subdirectory.

all/
├── postgres/
├── redis/
├── keycloak/
├── wordpress/
├── grafana/
└── ...

This branch exists primarily for:

Cross-plate development
Local testing
Refactoring shared functionality
Reviewing the complete collection in a single working tree

Summary

Docker Compose Plates turns infrastructure configuration from a copy-and-paste exercise into a repeatable generation process.

By combining:

Typed schemas
Versioned templates
Optional modules
Plate composition
Standardised operational practices

teams can generate production-ready infrastructure stacks in seconds while maintaining consistency across every environment and every project.

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

Production-Ready Docker Compose Collection with kikplate

Docker Compose Plates: Reusable Infrastructure Stacks with kikplate

What is kikplate?

Install on macOS and Linux

Install on Windows

The Plate Format

Schema

Modules

Files

values.yaml

What Gets Generated

docker-compose.yml

.env

README.md

Why Use Plates?

The Collection

Database

Backend

DevOps

Security

Other

Architecture and Composition

How Composition Works

Shared Schema

Docker Compose Includes

Generated Output

docker-compose.yml

docker-compose.postgres.yml

.env

README.md

Benefits of Composition

Composition Examples

Generating a Plate

Generate from a Values File

Override Individual Values

Generate into a Specific Directory

Generate Directly to a Repository

Consistency Across Every Plate

Secrets Management

Health Checks

Logging

Network Isolation

Security Options

Graceful Shutdown

Official Images

How Teams Use This

Small Development Teams

Platform Teams

Updating Existing Deployments

Repository Structure

Individual Plate Branches

plate.yaml

values.yaml

templates/

Main Branch

All Branch

Summary

What If Your Project Starter Knew Exactly What You Needed

Introducing kik generate: schema driven plates on Kikplate

From kikplate.yaml to plate.yaml

Anatomy of a plate.yaml file

The schema tab on the plate page

The CLI is now kik

Installing the CLI

Walking through kik generate

Step 1: pick or inspect a plate

Step 2: write a values file

Step 3: generate from a local checkout of the template

Step 4: generate from the published plate by slug

Step 5: run the generated project

Migrating an existing plate

Closing thoughts

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

What is Crossview?

Key Features

Why We Built It

Who Is It For?

Open Source and Community‑Driven

Final Thoughts

The CLI is now `kik`