Concepts Overview
How Flipswitch organizes flags, environments, and permissions
Flipswitch organizes feature flags in a hierarchy:
Organization
├── Project (e.g., "Web App")
│ ├── Environment: Development
│ │ └── Flag rules + API keys
│ ├── Environment: Staging
│ │ └── Flag rules + API keys
│ ├── Environment: Production
│ │ └── Flag rules + API keys
│ └── Segments (reusable across flags in this project)
├── Project (e.g., "Mobile App")
│ └── ...Key Concepts
Feature Flags
Types, variants, and default values
Targeting Rules
Conditions, operators, and evaluation order
Segments
Reusable user groups for targeting
Real-Time Updates
SSE architecture for instant flag changes
Organizations
The top-level container. An organization has:
- Members - Users who can access projects
- Groups - Collections of users with shared permissions
- Projects - Containers for flags
Projects
A project typically represents an application or service. Each project contains:
- Flags - Feature flags with their definitions
- Environments - Isolated configurations (dev, staging, prod)
- Segments - Reusable targeting groups
Environments
Environments let you configure flags differently for each deployment stage:
| Environment | Purpose |
|---|---|
| Development | Local testing, all features enabled |
| Staging | Pre-production validation |
| Production | Live user traffic |
Each environment has its own:
- Flag states (enabled/disabled)
- Targeting rules
- API keys
Flags are defined at the project level, but their rules and states are configured per environment.