Kits & Component Marketplace

Create reusable infrastructure components that can be shared publicly, with friends, or kept private. Standardize patterns, accelerate onboarding, and maintain consistency across teams.

What is a Kit?

A kit is a reusable, pre-configured infrastructure component created from an existing asset or cluster stack. Kits capture not just the container image, but also the configuration, scaling policies, probes, volumes, and other operational parameters that make the component work in production.

What makes kits powerful:

• Complete patterns, not just images (includes config, scaling, health checks)
• Versioned and tested (battle-tested configurations from real deployments)
• Shareable (public marketplace, private libraries, friend sharing)
• Instantly deployable (no configuration required, works out-of-box)

Example kits:

• PostgreSQL database with optimized settings and automated backups
• Redis cache with replication and persistence configured
• Node.js API template with health checks and autoscaling
• Monitoring stack (Prometheus + Grafana) pre-configured
• NGINX ingress controller with rate limiting and WAF

Business Value

Standardization:

• Every team uses the same PostgreSQL configuration
• No reinventing the wheel for common patterns
• Enforce security and compliance baselines

Speed:

• Deploy production-ready PostgreSQL in 30 seconds (not 30 minutes)
• New developers get standardized components instantly
• Reduce time-to-production by 60-80%

Knowledge sharing:

• Senior engineers capture expertise in reusable kits
• Best practices encoded in templates
• Institutional knowledge preserved

Governance:

• Platform teams control approved component versions
• Security team can audit and approve kits
• Compliance requirements baked into templates

---

How Kits Work

Existing Asset/Stack          Reusable Kit              New Deployment
       ↓                           ↓                           ↓
[PostgreSQL in Prod]     cod kit create           cod kit deploy
   ↓                           ↓                           ↓
Well-configured         Kit Definition            New PostgreSQL
Battle-tested          (versioned)                (same config)
Production-ready       Shareable                  Instant deployment

Workflow:

1. Configure asset in production (battle-test it)
2. Create kit from working asset
3. Version and publish to library
4. Deploy kit to new cabinets/clusters (zero config required)
5. Update kit as best practices evolve

---

Creating Kits

Transform existing assets into reusable components.

Basic Kit Creation

cod kit create --asset postgres --cabinet prod-db

What gets captured:

• Container image and version
• Resource requests and limits
• Environment variables (non-secret config)
• Health probes (liveness, readiness, startup)
• Volumes and storage configuration
• Autoscaling policies
• Network configuration
• Labels and annotations

Result: Kit definition stored in enterprise, ready for reuse.

Kit Creation with Metadata

cod kit create \
  --asset postgres \
  --cabinet prod-db \
  --name production-postgres \
  --description "PostgreSQL 14 with optimized settings for high-traffic applications. Includes automated backups, replication, and monitoring." \
  --library @mycompany/databases \
  --version 1.0.0 \
  --tags database,postgres,production-ready \
  --visibility private

Metadata fields:

• --name: Human-readable kit name
• --description: What the kit provides, use cases
• --library: Namespace for organization (e.g., @mycompany/databases)
• --version: Semantic version (1.0.0, 2.1.3, etc.)
• --tags: Searchable tags (database, api, monitoring, etc.)
• --visibility: public, private, or friends

Kit from Cluster Stack

Create kit from infrastructure stack:

cod kit create \
  --from-stack production-stack-v2 \
  --name production-infrastructure-kit \
  --description "Complete production infrastructure: ingress, monitoring, logging, security" \
  --library @mycompany/stacks \
  --visibility friends

Use case: Share entire infrastructure patterns (not just single components) with partner companies or subsidiary teams.

Kit from Multiple Assets

Bundle related assets into single kit:

cod kit create \
  --assets api,worker,scheduler \
  --cabinet production \
  --name nodejs-microservice-kit \
  --description "Node.js microservice pattern: API, background workers, scheduled jobs" \
  --library @mycompany/templates

Result: One kit that deploys three related assets together.

---

Kit Libraries

Libraries organize kits into namespaces for discovery and access control.

Library Structure

@mycompany/databases
├── production-postgres
├── mysql-primary
└── redis-cache

@mycompany/apis
├── nodejs-api-template
├── python-fastapi-template
└── go-api-template

@public/monitoring
├── prometheus-stack
├── grafana-dashboards
└── alertmanager-config

Library naming conventions:

• @organization/category (e.g., @mycompany/databases)
• @public/category (public marketplace kits)
• @username/personal (personal kits)

Creating Libraries

cod kit library create @mycompany/databases \
  --description "Standard database configurations for production use" \
  --visibility private \
  --maintainers platform-team@company.com

Library Permissions

Visibility levels:

• Public: Anyone can discover and use
• Private: Only enterprise members
• Friends: Specific enterprises granted access

Example:

# Share library with partner company
cod kit library share @mycompany/databases \
  --with partner-enterprise \
  --permission read

---

Browsing & Discovering Kits

List Available Kits

cod kit list

Output:

LIBRARY                  NAME                      VERSION   VISIBILITY
@mycompany/databases     production-postgres       1.2.0     private
@mycompany/databases     redis-cache               2.0.1     private
@mycompany/apis          nodejs-api-template       3.1.0     private
@public/monitoring       prometheus-stack          5.0.0     public
@public/ingress          nginx-ingress-ha          2.5.0     public

Search Kits

# Search by keyword
cod kit search postgres

# Filter by tag
cod kit list --tag database

# Filter by library
cod kit list --library @mycompany/databases

View Kit Details

cod kit view @mycompany/databases/production-postgres

Output:

Kit: production-postgres
Library: @mycompany/databases
Version: 1.2.0
Created: 2026-01-15
Maintainer: platform-team@company.com
Visibility: private

Description:
PostgreSQL 14 with optimized settings for high-traffic applications.
Includes automated backups, replication, and monitoring integration.

Components:
  - postgres:14.3 (primary database)
  - pg_exporter:0.12.0 (Prometheus metrics)

Configuration:
  Replicas: 1 (stateful)
  CPU: 2000m request, 4000m limit
  Memory: 4Gi request, 8Gi limit
  Storage: 500Gi SSD

Health Checks:
  Liveness: pg_isready on port 5432
  Readiness: SELECT 1 query
  Startup: 30s initial delay

Environment Variables (16):
  POSTGRES_DB, POSTGRES_MAX_CONNECTIONS, SHARED_BUFFERS,
  EFFECTIVE_CACHE_SIZE, MAINTENANCE_WORK_MEM, etc.

Volumes:
  - /var/lib/postgresql/data (500Gi, SSD storage class)
  - /backups (100Gi, standard storage class)

Used by: 15 cabinets across 8 clusters
Tags: database, postgres, production-ready, ha

---

Deploying Kits

Use kits to deploy pre-configured components instantly.

Basic Deployment

cod kit deploy @mycompany/databases/production-postgres \
  --cabinet production

What happens:

1. Codiac fetches kit definition
2. Creates asset in production cabinet
3. Applies all captured configurations
4. Deploys to Kubernetes
5. Asset inherits cabinet/environment config (dynamic configuration)

Result: Production-ready PostgreSQL running in 30-60 seconds, zero manual configuration.

Deploy with Overrides

cod kit deploy @mycompany/databases/production-postgres \
  --cabinet production \
  --override storage=1Ti \
  --override replicas=3 \
  --override memory-limit=16Gi

When to override:

• Larger production cluster needs more resources
• Different environment (staging vs prod)
• Special requirements (compliance, performance)

Deploy to Multiple Cabinets

# Deploy same kit to multiple cabinets
cod kit deploy @mycompany/apis/nodejs-api-template \
  --cabinets team-a,team-b,team-c

Use case: Standardized API template for every team. Each team gets same starting point.

Deploy Specific Version

# Deploy older version
cod kit deploy @mycompany/databases/production-postgres:1.1.0 \
  --cabinet staging-db

# Deploy latest version (default)
cod kit deploy @mycompany/databases/production-postgres \
  --cabinet prod-db

---

Updating Kits

Evolve best practices over time and propagate improvements.

Create New Kit Version

# Update the original asset
cod asset deploy --cabinet prod-db --asset postgres --update 14.4

# Capture updated kit
cod kit update @mycompany/databases/production-postgres \
  --from-asset postgres \
  --cabinet prod-db \
  --version 1.3.0 \
  --changelog "Upgraded to PostgreSQL 14.4, increased connection pool"

Semantic versioning:

• MAJOR (1.0.0 → 2.0.0): Breaking changes (PostgreSQL 14 → 15)
• MINOR (1.0.0 → 1.1.0): New features (added replication)
• PATCH (1.0.0 → 1.0.1): Bug fixes, security patches

Upgrade Assets Using Kit

Find assets deployed from kit:

cod kit usage @mycompany/databases/production-postgres

Output:

15 assets deployed from this kit:

CABINET       ASSET           VERSION   LAST UPDATED
prod-db       postgres        1.2.0     2026-01-10
staging-db    postgres        1.2.0     2026-01-12
dev-db-1      postgres        1.1.0     2025-12-20  ⚠️ OUTDATED
dev-db-2      postgres        1.2.0     2026-01-15
team-a-db     postgres        1.2.0     2026-01-18

Upgrade outdated assets:

# Upgrade single asset
cod kit upgrade @mycompany/databases/production-postgres:1.3.0 \
  --cabinet dev-db-1 \
  --asset postgres

# Upgrade all assets using kit
cod kit upgrade @mycompany/databases/production-postgres:1.3.0 \
  --all

---

Kit Visibility & Sharing

Control who can discover and use your kits.

Visibility Levels

1. Public Kits

cod kit create --asset my-asset --visibility public

Characteristics:

• Anyone can discover and use
• Listed in public marketplace
• Open source spirit
• Great for community contributions

Examples:

• Standard NGINX configurations
• Prometheus monitoring stacks
• Common database patterns

2. Private Kits

cod kit create --asset my-asset --visibility private

Characteristics:

• Only your enterprise members can use
• Not discoverable by others
• Internal standardization
• Proprietary configurations

Examples:

• Company-specific API templates
• Internal infrastructure patterns
• Security-hardened configurations

3. Friends-Only Kits

cod kit create --asset my-asset --visibility friends

Characteristics:

• Share with specific enterprises
• Controlled distribution
• Partner/subsidiary sharing
• Not public, not private

Examples:

• Shared services between business units
• Partner integrations
• Vendor-provided templates

Granting Access

Share kit with specific enterprise:

cod kit share @mycompany/databases/production-postgres \
  --with partner-company \
  --permission read

Share entire library:

cod kit library share @mycompany/databases \
  --with subsidiary-company \
  --permission read-deploy

Permissions:

• read: View kit details
• read-deploy: View and deploy kits
• read-write: View, deploy, and create new versions

---

Component Marketplace

Public marketplace for community-contributed kits.

Browsing the Marketplace

Web UI:

1. Navigate to Codiac web UI
2. Click Marketplace or Kits
3. Browse categories (databases, APIs, monitoring, etc.)
4. Search by keyword or filter by tags

CLI:

# List public kits
cod kit list --public

# Search marketplace
cod kit search monitoring --public

# Browse by category
cod kit list --category databases --public

Marketplace Categories

Category	Examples
Databases	PostgreSQL, MySQL, MongoDB, Redis
APIs	Node.js, Python FastAPI, Go, Ruby on Rails
Monitoring	Prometheus, Grafana, Datadog, New Relic
Messaging	RabbitMQ, Kafka, NATS
Caching	Redis, Memcached, Varnish
Search	Elasticsearch, Solr, Meilisearch
Ingress	NGINX, Traefik, HAProxy
Security	Falco, OPA, cert-manager

Contributing to Marketplace

Publish public kit:

cod kit create \
  --asset my-asset \
  --name awesome-postgres-setup \
  --library @public/databases \
  --description "PostgreSQL with auto-tuning and automated backups" \
  --visibility public \
  --license MIT

Requirements:

• Tested configuration
• Clear documentation
• Open source license (for public kits)
• No proprietary/secret information

---

Common Kit Patterns

Pattern 1: Database Kit

Production-ready PostgreSQL:

Kit: @mycompany/databases/production-postgres

Components:
  - postgres:14.3 (main database)
  - pg_exporter (Prometheus metrics)
  - pgbackrest (automated backups)

Configuration:
  - Optimized memory settings (shared_buffers, work_mem)
  - Connection pooling (max 100 connections)
  - Replication enabled (streaming replication)
  - Automated daily backups to S3
  - Point-in-time recovery enabled

Health Checks:
  - Liveness: pg_isready
  - Readiness: SELECT 1 query
  - Startup: 30s delay for recovery

Volumes:
  - /var/lib/postgresql/data (500Gi SSD)
  - /backups (100Gi standard)

Autoscaling: Disabled (stateful)

Pattern 2: Microservice API Kit

Node.js API template:

Kit: @mycompany/apis/nodejs-api-template

Components:
  - node:20-alpine (API server)

Configuration:
  - NODE_ENV=production
  - Graceful shutdown (SIGTERM handling)
  - Request logging (Morgan)
  - Error tracking (Sentry integration)

Health Checks:
  - Liveness: GET /health (200 OK)
  - Readiness: GET /ready (checks DB connection)
  - Startup: 10s delay

Resource Limits:
  - CPU: 200m request, 1000m limit
  - Memory: 256Mi request, 512Mi limit

Autoscaling:
  - Min: 2 replicas
  - Max: 20 replicas
  - Target: 70% CPU

Ingress:
  - HTTPS enabled (Let's Encrypt)
  - Rate limiting (100 req/min per IP)
  - CORS configured

Pattern 3: Monitoring Stack Kit

Prometheus + Grafana:

Kit: @public/monitoring/prometheus-stack

Components:
  - prometheus:v2.48.0 (metrics collection)
  - grafana:10.2.0 (dashboards)
  - alertmanager:v0.26.0 (alerting)
  - node-exporter:1.7.0 (node metrics)
  - kube-state-metrics:2.10.0 (k8s metrics)

Configuration:
  - 90-day retention
  - Pre-configured dashboards (20+)
  - Alert rules for common issues
  - PagerDuty integration
  - Slack notifications

Volumes:
  - Prometheus: 200Gi (metrics storage)
  - Grafana: 10Gi (dashboards + config)

Ingress:
  - grafana.example.com (Grafana UI)
  - prometheus.example.com (Prometheus UI, admin only)

Pattern 4: Worker/Job Kit

Background job processor:

Kit: @mycompany/workers/job-processor

Components:
  - node:20-alpine (worker process)

Configuration:
  - Queue connection (RabbitMQ/Redis)
  - Concurrency settings
  - Retry policies
  - Dead letter queue

Health Checks:
  - Liveness: Process heartbeat
  - Readiness: Queue connection check

Resource Limits:
  - CPU: 500m request, 2000m limit
  - Memory: 512Mi request, 2Gi limit

Autoscaling:
  - Min: 1 replica
  - Max: 50 replicas
  - Target: Custom metric (queue depth)

---

Best Practices

1. Create Kits from Production Assets

Don't create kits from untested configurations:

• ❌ Create kit from local development asset
• ✅ Create kit from battle-tested production asset

Workflow:

1. Deploy asset to production
2. Monitor for 1-2 weeks
3. Tune configurations based on real metrics
4. Once stable, create kit
5. Share tested configuration with team

2. Version Kits Semantically

Follow semantic versioning:

# Patch: Security update to PostgreSQL 14.3 → 14.4
cod kit update production-postgres --version 1.2.1

# Minor: Added replication support
cod kit update production-postgres --version 1.3.0

# Major: Upgraded PostgreSQL 14 → 15 (breaking change)
cod kit update production-postgres --version 2.0.0

3. Document Kit Configurations

Include clear descriptions:

cod kit create \
  --asset postgres \
  --name production-postgres \
  --description "PostgreSQL 14.3 optimized for high-traffic apps (10k+ req/s).

Configuration highlights:
- Shared buffers: 4GB (25% of available RAM)
- Max connections: 100 (connection pooling recommended)
- Work mem: 32MB per query
- Automated backups: Daily to S3, 30-day retention
- Streaming replication: Enabled for HA setups
- Monitoring: Prometheus exporter included

Requirements:
- 8GB RAM minimum
- SSD storage recommended
- Kubernetes 1.26+

Best practices:
- Use connection pooling (pgBouncer)
- Mount /var/lib/postgresql/data as persistent volume (500Gi+)
- Set DATABASE_URL in cabinet configuration"

4. Use Tags for Discoverability

Tag kits with relevant keywords:

cod kit create \
  --asset postgres \
  --tags database,postgres,sql,production-ready,high-availability,automated-backups,monitoring

Common tags:

• production-ready - Tested in production
• ha - High availability configured
• monitoring - Observability included
• security-hardened - Enhanced security
• auto-scaling - Autoscaling enabled

5. Test Kit Deployments

Before publishing:

# Deploy kit to test cabinet
cod kit deploy my-new-kit --cabinet test-kit-deployment

# Verify functionality
# Run integration tests
# Check resource usage

# If successful, publish to library
cod kit publish my-new-kit --library @mycompany/databases

6. Keep Kits Updated

Regular maintenance:

• Update kit when base images get security patches
• Refresh configurations based on production learnings
• Deprecate old versions gracefully

# Mark old version as deprecated
cod kit tag production-postgres:1.0.0 --add deprecated

# Publish new version
cod kit update production-postgres --version 1.3.0 --tag stable,recommended

---

Advanced: Kit Templates

Create parameterized kits for flexible deployments.

Template Variables

cod kit create \
  --asset api \
  --name api-template \
  --template \
  --variables "SERVICE_NAME,DATABASE_TYPE,REPLICAS"

Deployment with template:

cod kit deploy @mycompany/templates/api-template \
  --cabinet team-a \
  --set SERVICE_NAME=payment-api \
  --set DATABASE_TYPE=postgres \
  --set REPLICAS=5

Use case: Single kit template creates different configurations based on input variables.

Conditional Components

Include components conditionally:

# kit-definition.yaml
components:
  - name: api
    image: node:20-alpine

  - name: redis
    image: redis:7-alpine
    condition: "{{ ENABLE_CACHE }}"  # Only deploy if ENABLE_CACHE=true

  - name: postgres
    image: postgres:14
    condition: "{{ DATABASE_TYPE == 'postgres' }}"

---

Troubleshooting

Problem: Kit deployment fails

Error: Kit not found: @mycompany/databases/production-postgres

Cause: Library not accessible or kit doesn't exist.

Solution:

# Check available libraries
cod kit library list

# Verify kit exists
cod kit search production-postgres

# Check permissions
cod kit library view @mycompany/databases

Problem: Deployed asset differs from kit

Issue: Asset deployed from kit has different configuration than kit definition.

Cause: Dynamic configuration overrides kit values.

Explanation: Kits provide base configuration. Cabinet/environment config takes precedence (by design).

Kit config (DATABASE_POOL_SIZE=10)
  ↓
Cabinet config (DATABASE_POOL_SIZE=50)  ← This wins
  ↓
Deployed asset uses 50, not 10

Solution: This is expected behavior. Kit provides defaults, environment config customizes.

Problem: Kit version conflicts

Error: Kit version 2.0.0 requires Kubernetes 1.26+, but cluster runs 1.24

Solution:

# Deploy older kit version compatible with cluster
cod kit deploy @mycompany/databases/production-postgres:1.5.0 \
  --cabinet prod-db

# Or: Upgrade cluster to meet kit requirements
cod cluster upgrade my-cluster --k8s-version 1.26

---

FAQ

Q: What's the difference between a kit and a cluster stack?

A:

• Kit: Single asset or group of related assets (e.g., PostgreSQL database, Node.js API)
• Cluster stack: Complete infrastructure foundation (ingress, monitoring, logging, etc.)

Q: Can I create kits from third-party Helm charts?

A: Yes. Deploy the Helm chart as an asset in Codiac, then create a kit from it. The kit captures the Helm configuration.

Q: Do kits include secrets?

A: No. Kits never include secret values (for security). They include references to secret names, but actual values come from your secret store.

Q: Can I modify a deployed kit asset?

A: Yes. Once deployed, the asset is independent of the kit. You can modify it freely. Changes don't affect the kit.

Q: How do I update all assets created from a kit?

A:

cod kit upgrade @mycompany/databases/production-postgres:1.3.0 --all

This updates all assets that were originally deployed from this kit.

Q: Can I export kits to share with non-Codiac users?

A: Export as Helm chart or Kubernetes YAML (Enterprise tier):

cod kit export @mycompany/databases/production-postgres --format helm

---

Related Documentation

• Cluster Stacks
• Asset Management
• Component Marketplace
• Infrastructure Enterprise
• Glossary: Kit

---

Need help creating kits? Contact Support or visit codiac.io to schedule hands-on kit creation guidance.