Skip to main content

Flagsmith Platform Architecture

Flagsmith architecture supports a range of deployment models to suit different organisational needs, from fully managed SaaS to self-hosted and on-premises solutions.

Conceptual Overview​

The most important components in Flagsmith's architecture are:

  • Frontend dashboard: A web interface for managing projects, environments, feature flags, and user permissions. This is where most configuration and management tasks are performed.
  • Core API: RESTful API that powers the dashboard and SDKs. These endpoints are used for automation, integrations, and direct management of Flagsmith resources.
  • Edge API: A globally distributed API for low-latency flag evaluation, especially useful for applications with users around the world.
  • SDKs: Client libraries (available for many languages and platforms) that connect your applications and services to Flagsmith, enabling real-time feature flag evaluation and remote configuration.
  • Integrations: Optional connectors to third-party tools and services (e.g., analytics, notifications, monitoring). These can be configured via the dashboard or API.
  • Database: Stores all persistent data, such as organisations, projects, features, and audit logs. Managed by Flagsmith in SaaS, but by your team in self-hosted/on-prem deployments.
  • Ingestion server: A web service that receives events from SDKs (e.g. for experimentation) and writes them to Kafka.
  • Kafka: Message bus used to reliably deliver events to the warehouse.
  • Warehouse delivery: Inserts events into each environment's warehouse, retries failed inserts, and records delivery status.
  • Warehouse: Analytical database that stores events and runs the aggregations the Core API requests.

The architecture is REST-based, with both SDK clients and the dashboard interacting with the Core API. The platform is designed to be cloud-native, supporting containerisation and orchestration for scalability and reliability.

Deployment Models​

Flagsmith can be deployed in three main ways, each with conceptual differences in management, control, and responsibility. The following diagrams illustrate the architecture for each model:

1. SaaS (Cloud-Hosted)​

  • Managed by Flagsmith: No infrastructure to manage; get started instantly.
  • Automatic scaling, security, and updates: All handled by the Flagsmith team.
  • Global Edge API: Provides low-latency flag delivery worldwide.
  • Best for: Teams who wish to focus on product development and avoid infrastructure overhead.

SaaS Architecture

The diagram above shows the SaaS deployment model, where all infrastructure is managed by Flagsmith and the Edge API ensures global low-latency delivery.

Experimentation on SaaS​

Flagsmith runs the whole experimentation pipeline. Events go to the Flagsmith-managed ClickHouse warehouse directly from Kafka, or to your own warehouse through warehouse delivery.

SaaS Experimentation Architecture

The diagram above shows how experiment events flow on SaaS, to the managed warehouse or to your own.

2. Self-Hosted (Cloud or Private Cloud)​

  • Managed by your team: Deploy Flagsmith on your own cloud infrastructure (e.g., AWS, GCP, Azure, DigitalOcean) using Docker, Kubernetes, or other orchestration tools.
  • Full control: You manage scaling, security, updates, and integrations.
  • Customisation: Integrate with your own authentication, analytics, and infrastructure.
  • Best for: Teams with specific compliance, data residency, or custom integration requirements.

3. On-Premises (Enterprise Edition)​

  • Deployed in your private data centre or isolated cloud: For maximum control and data sovereignty.
  • Enterprise features: Advanced authentication (Okta, LDAP, SAML, ADFS), custom fields, support for additional databases (Oracle, MySQL), and more.
  • Orchestration support: Kubernetes, OpenShift, AWS ECS, GCP AppEngine, Azure Container Instances, and more.
  • Best for: Organisations with strict regulatory, security, or data sovereignty requirements.

Self-Hosted / On-Prem Architecture

The diagram above illustrates the Self-Hosted and On-Premises deployment models, where your team manages the infrastructure and has full control over security, compliance, and integrations.

Experimentation on Self-Hosted and On-Premises​

Your team runs the ingestion server, Kafka and warehouse delivery alongside the Core API. Events go to your own warehouse through warehouse delivery. See Connect a Warehouse for supported warehouses.

Self-Hosted Experimentation Architecture

The diagram above shows how experiment events flow on Self-Hosted and On-Premises deployments, where every component, including the warehouse, is run by your team.

What's next​