# Openfeature

> "OpenFeature in Feature Flagging - cloud native architecture, patterns" pitfalls, and best practices

- Skill: `paulpas/openfeature` (Agent Skill)
- Install (CLI): `npx skillmds@latest add paulpas/openfeature`
- Raw SKILL.md: https://api.skillmd.com/api/skills/paulpas/openfeature/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: paulpas (https://skillmd.com/u/paulpas)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/paulpas/openfeature

---





# OpenFeature in Cloud-Native Engineering

**Category:** application-definition  
**Status:** Incubating  
**Stars:** 1,000  
**Last Updated:** 2026-04-22  
**Primary Language:** Multi-language  
**Documentation:** [https://openfeature.dev/](https://openfeature.dev/)  

---

## Purpose and Use Cases

### What Problem Does It Solve?

OpenFeature addresses the fragmentation and vendor lock-in in feature flagging systems. Teams often build feature flagging directly into their applications, making it difficult to share configurations across microservices or switch between providers. OpenFeature provides a standardized, vendor-neutral API and SDKs for feature flagging that works consistently across different programming languages and backend providers.

### When to Use This Project

Use OpenFeature when you need:
- Consistent feature flagging across microservices
- Support for multiple programming languages
- Vendor-neutral feature flagging implementation
- Fine-grained targeting and segmentation
- Audit trails and compliance tracking
- Integration with existing observability tooling

### Key Use Cases

- **Gradual Rollouts**: Gradually roll out features to users
- **A/B Testing**: Test different feature variations
- **Kill Switches**: Instantly disable problematic features
- **Canary Releases**: Test features with small user segments
- **Team Isolation**: Enable features for specific teams only
- **Emergency Retire**: Disable features during incidents

---

## Architecture Design Patterns

### Core Components

- **OpenFeature SDK**: Language-specific client library for feature evaluation
- **Provider Interface**: Standard interface for feature flag backends
- **Flag Provider**: Implementation for specific flagging systems (Flagd, LaunchDarkly, etc.)
- **Evaluation Context**: User, environment, and device information for targeting
- **Logger**: Structured logging for flag evaluation events
- **Metrics Exporter**: Prometheus metrics for feature flag usage

### Component Interactions

1. **Application → OpenFeature SDK**: Request feature flag evaluation
2. **SDK → Provider**: Delegate to specific provider implementation
3. **Provider → Backend**: Query feature flag state from backend
4. **Provider → Logger**: Log evaluation events
5. **Provider → Metrics**: Export usage metrics
6. **Provider → Cache**: Store recent evaluations for performance

### Data Flow Patterns

1. **Feature Evaluation**: Application → SDK → Provider → Backend → Result → Cache
2. **Context Building**: Application → Context → SDK → Provider → Evaluation
3. **Event Logging**: Evaluation → Logger → Logging system
4. **Metrics Export**: Evaluation → Metrics → Prometheus → Dashboard

### Design Principles

- **Language Agnostic**: SDKs for multiple programming languages
- **Provider Interoperability**: Standard interface for any backend
- **Context-Aware**: Rich context for targeting and segmentation
- **Performance Optimized**: Caching and asynchronous evaluation
- **Observability-First**: Built-in metrics and logging
- **Evolution-Friendly**: Versioned API for future enhancements

---

## Integration Approaches

### Integration with Other CNCF Projects

- **Kubernetes**: Feature flags for Kubernetes deployments
- **Prometheus**: Feature flag metrics for monitoring
- **Grafana**: Dashboards for feature flag usage
- **OpenTelemetry**: Distributed tracing for feature evaluations
- **Helm**: Deploy feature flag backends via Helm charts
- **Tekton**: Feature flag integration in CI/CD pipelines
- **Envoy**: Feature flags in service mesh configurations

### API Patterns

- **Feature Evaluation API**: Evaluate feature flags by name
- **Context API**: Build rich evaluation context
- **Provider API**: Standard interface for flag providers
- **Webhook API**: Event notifications for flag changes
- **REST API**: HTTP interface for feature management

### Configuration Patterns

- **Provider Configuration**: YAML/JSON for provider settings
- **Flag Definitions**: Declarative feature flag definitions
- **Context Management**: Shared context across evaluations
- **Environment Variables**: Configuration via environment

### Extension Mechanisms

- **Custom Providers**: Implement support for new flagging backends
- **Custom Evaluators**: Implement custom evaluation logic
- **Webhook Integrations**: Extend to additional notification platforms
- **Metrics Export**: Add custom metrics collection

---

## Common Pitfalls and How to Avoid Them

### Configuration Issues

- **Provider Setup**: Ensure provider is correctly configured
- **Context Validation**: Validate context before evaluation
- **Default Values**: Define sensible defaults for missing flags
- **Environment Isolation**: Keep development and production flags separate

### Performance Issues

- **Evaluation Latency**: Use caching for frequent evaluations
- **Network Calls**: Minimize network calls with local evaluation
- **Memory Usage**: Optimize context memory footprint
- **Concurrency**: Handle concurrent evaluations efficiently

### Operational Challenges

- **Flag Drift**: Keep feature definitions in sync across environments
- **Testing**: Test feature flags in staging before production
- **Rollback Plans**: Test rollback procedures for flag issues
- **Access Control**: Restrict flag modification permissions

### Security Pitfalls

- **Flag Sensitive Data**: Don't expose sensitive data through flags
- **Access Control**: Secure flag management endpoints
- **Audit Logging**: Log all flag evaluation and modification events

---

## Coding Practices

### Idiomatic Configuration

- **Provider YAML**: Declarative provider configuration
- **Flag Definitions**: Declarative feature flag definitions
- **Context Templates**: Reusable context templates
- **Environment-Specific**: Separate configurations for environments

### API Usage Patterns

- **Feature Evaluation**: Simple feature flag evaluation
- **Context Building**: Build rich evaluation context
- **Provider Registration**: Register multiple providers
- **Webhook Subscription**: Subscribe to flag change events

### Observability Best Practices

- **Evaluation Metrics**: Track feature evaluation rates and patterns
- **Alerting**: Set up alerts for unusual flag patterns
- **Dashboard**: Use Grafana dashboards for feature flag monitoring
- **Audit Trail**: Log all flag evaluation events

### Development Workflow

- **Local Development**: Use local Flagd instance for development
- **Testing**: Test all feature flag variations
- **Staging**: Verify feature flags in staging environment
- **CI/CD Integration**: Integrate feature flags in CI/CD workflows

---

## Fundamentals

### Essential Concepts

- **Feature Flag**: Boolean or multi-variant switch for feature control
- **Evaluation Context**: User and environment information for targeting
- **Provider**: Backend implementation for feature flag storage
- **Default Value**: Fallback value when flag doesn't exist
- **Variants**: Multi-variant flag for A/B testing
- **Flag Version**: Version control for feature flags

### Terminology Glossary

- **Feature Flag**: Switch that controls feature availability
- **Provider**: Backend system storing feature flags
- **Context**: User and environment data for targeting
- **Evaluation**: Checking if feature is enabled for context
- **Variants**: Different versions of a feature flag
- **Stale Flag**: Flag not updated after provider change
- **Static Flag**: Flag defined in configuration

### Data Models and Types

- **Feature Flag**: Name, enabled status, variants, rules
- **Evaluation Context**: User, device, environment information
- **Flag Provider**: Provider configuration and status
- **Evaluation Result**: Flag value and metadata

### Lifecycle Management

- **Flag Lifecycle**: Create → Define → Evaluate → Update → Delete
- **Context Lifecycle**: Build → Evaluate → Cache → Cleanup
- **Provider Lifecycle**: Setup → Sync → Evaluate → Update

### State Management

- **Flag State**: Enabled, disabled, staged, rolled out
- **Context State**: Current context values for evaluation
- **Provider State**: Connected, disconnected, error

---

## Scaling and Deployment Patterns

### Horizontal Scaling

- **SDK Scaling**: Scale application instances with OpenFeature SDK
- **Provider Scaling**: Scale flag provider backend for high load
- **Caching**: Cache evaluations for frequently accessed flags

### High Availability

- **Provider Redundancy**: Deploy multiple provider instances
- **Cache Redundancy**: Cache flag evaluations across instances
- **Failover**: Graceful degradation when provider unavailable
- **Static Flags**: Fallback to static flag definitions

### Production Deployments

- **Production Provider**: Deploy production-grade flag provider
- **Caching Layer**: Use Redis or in-memory cache for evaluations
- **Monitoring**: Set up Prometheus and Grafana for monitoring
- **Audit Logging**: Enable audit logging for compliance

### Upgrade Strategies

- **Minor Version**: In-place upgrade with API compatibility
- **Major Version**: Test new SDK versions before deployment
- **Data Migration**: Plan for flag data migration
- **Rollback Plan**: Keep previous version available

### Resource Management

- **Memory**: Monitor memory usage for SDK cache
- **CPU**: Balance evaluation workload across instances
- **Network**: Monitor network traffic to flag provider
- **Storage**: Manage flag storage usage

---

## Additional Resources

- **Official Documentation:** [https://openfeature.dev/docs](https://openfeature.dev/docs)
- **GitHub Repository:** [github.com/open-feature](https://github.com/open-feature)
- **CNCF Project Page:** [cncf.io/projects/openfeature/](https://www.cncf.io/projects/openfeature/)
- **Community:** Check the GitHub repository for community channels
- **Versioning:** Refer to project's release notes for version-specific features

---

## Troubleshooting

### Common Issues

1. **Deployment Failures**
   - Check pod logs for errors
   - Verify configuration values
   - Ensure network connectivity

2. **Performance Issues**
   - Monitor resource usage
   - Adjust resource limits
   - Check for bottlenecks

3. **Configuration Errors**
   - Validate YAML syntax
   - Check required fields
   - Verify environment-specific settings

4. **Integration Problems**
   - Verify API compatibility
   - Check dependency versions
   - Review integration documentation

### Getting Help

- Check official documentation
- Search GitHub issues
- Join community channels
- Review logs and metrics
*Content generated automatically. Verify against official documentation before production use.*

## Examples

### Basic Configuration


```yaml
# Basic configuration example
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{project_name}}-config
  namespace: default
data:
  # Configuration goes here
  config.yaml: |
    # Base configuration
    # Add your settings here
```

### Kubernetes Deployment


```yaml
# Kubernetes deployment for {{project_name}}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{project_name}}
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: {{project_name}}
  template:
    metadata:
      labels:
        app: {{project_name}}
    spec:
      containers:
      - name: {{project_name}}
        image: {{project_name}}:latest
        ports:
        - containerPort: 8080
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
```

### Kubernetes Service


```yaml
# Kubernetes service for {{project_name}}
apiVersion: v1
kind: Service
metadata:
  name: {{project_name}}
  namespace: default
spec:
  selector:
    app: {{project_name}}
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP
```

---

## When to Use

Use this skill when:

- **Integrating a CNCF project into Kubernetes infrastructure** — You need to configure, deploy, or troubleshoot a cloud-native tool within a cluster
- **Designing cloud-native architecture** — You are selecting and integrating CNCF tools to solve specific infrastructure challenges
- **Resolving operational issues** — A CNCF component is misbehaving, underperforming, or needs configuration changes
---

## Core Workflow

1. **Assess Requirements** — Understand the use case, scale, integration needs, and existing infrastructure. **Checkpoint:** Document requirements, constraints, and success criteria.

2. **Design Architecture** — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. **Checkpoint:** Verify the architecture addresses all requirements and follows CNCF conventions.

3. **Implement & Configure** — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. **Checkpoint:** Validate all YAML against schema and test in a staging environment.

4. **Deploy & Monitor** — Apply manifests to the cluster, verify component health, and confirm observability is working. **Checkpoint:** Confirm all pods/services are running, probes passing, and metrics/alerts configured.

---

## Constraints

### MUST DO
- Include at least one complete working YAML manifest example
- Note when content is auto-generated vs. manually verified
- Reference relevant CNCF project documentation

### MUST NOT DO
- Deploy manifests without testing in a staging environment first
- Use deprecated API versions (e.g., apps/v1beta1)
- Omit resource limits and requests in Kubernetes manifests