Weik.io

Configuration Schemas Overview

Complete reference for Weik.io YAML configuration schemas

Weik.io uses YAML configuration files to manage platform resources. Each configuration type defines a specific resource or capability through a declarative schema.

Configuration Structure

All Weik.io configurations follow this structure:

apiVersion: weik.io/v1
kind: <ConfigurationType>
metadata:
  name: resource-name
spec:
  # Configuration-specific properties

Configuration Types

API Management

Configurations for managing APIs and their lifecycle:

  • Api - Define API base configuration and URL prefix
  • ApiVersion - Configure API versions with authentication and connection settings
  • ApiSubscription - Manage API access subscriptions
  • OpenApiEndpoint - Expose OpenAPI operations as REST endpoints
  • OpenApiConnector - Register OpenAPI connectors from packages

Integration

Configurations for building integration flows:

  • IntegrationFlow - Define integration flow orchestration
  • IntegrationService - Create reusable integration services
  • MFT - Configure managed file transfers between storage systems
  • Schedule - Define scheduled tasks with cron expressions

Eventing

Configurations for event-driven architecture:

Configuration and Variables

Foundational configurations:

  • Variable - Define variables and secrets for use across configurations
  • CoreSystem - Configure core system components (deprecated)

Common Patterns

Using Variables

Reference variables in configurations:

apiVersion: weik.io/v1
kind: Variable
metadata:
  name: database-password
spec:
  Value: super-secret-password
  IsSecret: true
---
apiVersion: weik.io/v1
kind: DatabaseChangeTracking
metadata:
  name: orders-tracking
spec:
  Type: postgresql
  Parameters:
    Password: ${database-password}

Multi-Document YAML

Define multiple resources in one file:

apiVersion: weik.io/v1
kind: EventChannel
metadata:
  name: orders-channel
spec:
  Type: memory
---
apiVersion: weik.io/v1
kind: EventSource
metadata:
  name: order-webhook
spec:
  Type: webhook
  EventType: com.example.orders.created
  EventSource: order-api
---
apiVersion: weik.io/v1
kind: EventSubscription
metadata:
  name: order-subscription
spec:
  Source: order-webhook
  Channel: orders-channel

Configuration Dependencies

Some configurations depend on others existing first:

# 1. Create API first
apiVersion: weik.io/v1
kind: Api
metadata:
  name: northwind-api
spec:
  Prefix: /northwind
---
# 2. Then create API version
apiVersion: weik.io/v1
kind: ApiVersion
metadata:
  name: northwind-v1
spec:
  ApiName: northwind-api
  IsActive: true
---
# 3. Finally create subscriptions
apiVersion: weik.io/v1
kind: ApiSubscription
metadata:
  name: customer-subscription
spec:
  ApiName: northwind-api
  ApiVersion: v1

Applying Configurations

Using the CLI

Apply configurations using the CLI:

# Apply a single file
weikio config apply configuration.yaml

# Apply with variable substitution
weikio config apply configuration.yaml --variables env.yaml

File Organization

Organize configurations by type or purpose:

configs/
  ├── apis/
  │   ├── api.yaml
  │   ├── api-versions.yaml
  │   └── endpoints.yaml
  ├── integrations/
  │   ├── flows.yaml
  │   ├── services.yaml
  │   └── schedules.yaml
  ├── eventing/
  │   ├── channels.yaml
  │   ├── sources.yaml
  │   └── subscriptions.yaml
  └── variables/
      ├── common.yaml
      └── secrets.yaml

Configuration Best Practices

Naming Conventions

  • Use lowercase with hyphens: customer-sync-flow
  • Be descriptive: stripe-payment-webhook not webhook1
  • Include purpose: nightly-backup-schedule
  • Use consistent prefixes for related resources

Security

  • Store secrets in Variable configurations with IsSecret: true
  • Never commit secrets to version control
  • Use environment-specific variable files
  • Restrict access to configuration files
  • Implement proper access controls

Version Control

  • Store configurations in Git
  • Use branches for environments (dev, staging, production)
  • Review configuration changes through pull requests
  • Tag releases for traceability
  • Document breaking changes

Documentation

  • Add comments to complex configurations
  • Document variable requirements
  • Include example values
  • Note dependencies between resources
  • Maintain a configuration catalog

Testing

  • Test configurations in development first
  • Validate YAML syntax before applying
  • Verify resource dependencies
  • Test with realistic data
  • Monitor resource health after deployment

Getting Help

View configuration help:

# General help
weikio config --help

# Apply command help
weikio config apply --help

For detailed information on each configuration type, see the individual reference pages linked above.