SOASAP vs Flagsmith

Introduction

SOASAP and Flagsmith both provide feature flag platforms and support local SDK evaluation in appropriate server-side deployments. Both can separate configuration delivery from request-time evaluation when the SDK is configured for local evaluation.

They differ primarily in operational philosophy. SOASAP is designed as a managed cloud platform: the vendor operates the control plane. Flagsmith can be used as a managed cloud service or deployed as a customer-operated, self-hosted control plane. This page explains the engineering implications of those architectural choices. It does not recommend one platform.

Use it to reason about deployment models, operational ownership, synchronization, local evaluation, offline behavior, infrastructure responsibilities, and production tradeoffs.

High-level architecture

SOASAP

Applications evaluate feature flags from a locally synchronized in-memory snapshot. Once a snapshot exists, evaluation is independent from cloud communication on the request path. See Local Evaluation.

Flagsmith

Flagsmith documents a platform architecture that supports managed SaaS and self-hosted (cloud or on-premises) control planes. The Core API powers the dashboard and SDKs; managed deployments may also use a globally distributed Edge API. In self-hosted deployments, the same conceptual components run on customer infrastructure, including the database that stores organizations, projects, features, and related persistent state.

Server-side SDKs can run in Local Evaluation mode (environment document downloaded and refreshed periodically; evaluations computed in-process) or Remote Evaluation mode. Client-side SDKs are documented as Remote Evaluation only. Optional components such as Edge Proxy change network topology for some architectures. Applications therefore synchronize and evaluate according to the selected deployment and SDK mode — not a single universal path.

Managed vs self-hosted control plane

SOASAP

Vendor-operated concerns typically include:

• control-plane infrastructure
• platform upgrades
• control-plane scaling
• control-plane availability
• routine maintenance of the managed service

Customers still operate SDK deployment, application readiness, secrets, and application-side monitoring. The control plane itself is not a customer-run platform service.

Flagsmith managed

In Flagsmith’s SaaS model, Flagsmith operates the hosted control plane: infrastructure, scaling, security updates, and related platform maintenance for the managed service. Customers integrate SDKs, manage keys and environments, and operate application-side observability. Operational ownership of the control plane remains with the vendor.

Flagsmith self-hosted

In self-hosted deployments, the customer operates the Flagsmith control plane on their own infrastructure (for example Docker or Kubernetes/Helm on a chosen cloud or private environment). Documented customer responsibilities generally expand to include:

• compute, networking, and storage
• database operation and backups
• upgrades and security patching of Flagsmith components and dependencies
• monitoring, alerting, and capacity management
• scaling and high availability design
• disaster recovery and incident response for the control plane

Self-hosting can satisfy data residency, network isolation, compliance, or customization requirements. It also transfers long-term operational lifecycle ownership of the control plane to the organization. That transfer is an architectural choice, not an automatic quality improvement.

Local evaluation

SOASAP

Request-path evaluation uses the local snapshot. Network I/O is reserved for synchronization and related control-plane communication, not for each flag read after a snapshot is present.

Flagsmith

In Local Evaluation mode (server-side SDKs), Flagsmith documents that the SDK downloads an environment document, refreshes it on a configurable interval (commonly documented as every 60 seconds by default), and computes flag decisions in-process without a network call per evaluation. Remote Evaluation mode resolves flags via API calls and is the documented mode for client-side SDKs. Edge Proxy deployments introduce an additional local evaluation surface that SDKs may call remotely relative to the application process.

Architects should select evaluation mode intentionally. Local evaluation, remote evaluation, and proxy-mediated evaluation have different network, security, and operational profiles.

Control plane vs data plane

In SOASAP, temporary disruption of the managed control plane primarily affects configuration freshness when a valid snapshot exists; request processing continues from local state. See High Availability.

Flagsmith exhibits the same conceptual separation when Local Evaluation is in use: the control plane (managed or self-hosted) supplies environment documents; evaluations run from local state between refreshes. In Remote Evaluation mode, request-path evaluation remains coupled to API reachability. Self-hosting changes who runs the control plane; it does not by itself change whether a given SDK call is local or remote.

Synchronization model

SOASAP

Configuration distribution and evaluation are separate concerns. Freshness is driven by real-time synchronization while connectivity is available. See Real-Time Synchronization.

Flagsmith

In Local Evaluation mode, Flagsmith documents asynchronous environment-document refresh on a polling interval. Freshness therefore depends on interval configuration, network success, and process lifetime. Remote Evaluation and Edge Proxy paths introduce different refresh and request patterns. Exact transport details can vary by SDK and should be taken from Flagsmith documentation for the chosen language and mode.

Startup

SOASAP

SOASAP documents non-blocking startup where supported: restore from persistent cache or use explicit defaults, then synchronize in the background. See Non-Blocking Startup and Persistent Cache.

Flagsmith

Startup behavior depends on evaluation mode and SDK. Local Evaluation typically requires an initial environment-document fetch (asynchronous on initialize) before local decisions reflect current remote state. Offline mode can use an offline handler to avoid API calls. Ready/wait semantics and default-flag behavior are SDK-specific and should be verified for each runtime.

Offline operation

SOASAP

Running processes continue from the last snapshot when synchronization is unavailable. Restarts can restore persisted state when cache is configured. See Offline Operation.

Flagsmith

Offline behavior depends on SDK capabilities and deployment model. Flagsmith documents offline mode with an offline handler so SDKs can avoid API calls and serve configured offline defaults or handler-provided state. Local Evaluation continues from the last successfully loaded environment document while the process remains up and refresh fails. Restart durability without network depends on whether offline handlers, local files, or other durable mechanisms are configured — not solely on whether the control plane is managed or self-hosted.

Latency characteristics

For SOASAP, evaluation latency on the request path depends primarily on local memory access and application execution once a snapshot exists — not on control-plane availability.

For Flagsmith, observed latency depends on evaluation mode, SDK, runtime, and synchronization state. Local Evaluation after a warm environment document is an in-process cost. Remote Evaluation includes API round-trips. Self-hosting can place the API closer to applications or inside a private network, which may change refresh and remote-evaluation latency, but does not automatically change the cost model of a chosen evaluation mode. This page does not publish comparative benchmarks.

Failure modes

SOASAP

Freshness is affected; evaluation availability is typically retained while the snapshot remains valid. See Outages.

Flagsmith

Failure modes differ by deployment and evaluation mode. With Local Evaluation, failed refreshes leave evaluations on the last environment document until a successful poll. With Remote Evaluation, API unavailability affects evaluation unless defaults or caches are configured. Self-hosted control-plane outages (database, API pods, networking) are customer-owned incidents; managed SaaS control-plane outages are vendor-owned for the platform tier, while application SDKs still need local resilience design.

Operational responsibility

SOASAP

Vendor typically operates:

• control plane
• platform upgrades
• control-plane availability and infrastructure

Customer typically operates:

• SDK deployment and application integration
• secrets and environment isolation
• application and SDK-side monitoring
• persistent cache storage where configured

Flagsmith managed

Similar split: vendor operates the hosted control plane; customer operates SDKs, keys, application readiness, and application-side observability.

Flagsmith self-hosted

Customer operational ownership expands to the control plane lifecycle. Typical platform concerns include Kubernetes (or equivalent) workloads, databases, persistent storage, networking and TLS, upgrades, monitoring, backups, horizontal scaling, security patches, and disaster recovery. Application teams still own SDK integration; platform teams additionally own the flag service as a production dependency.

Scaling

In SOASAP, each SDK instance typically owns synchronization, an in-memory snapshot, and optional persistent cache. Horizontal application scale increases aggregate memory and sync connections. See Scaling.

For Flagsmith, scaling considerations depend on mode and hosting. Local Evaluation scales with application processes holding environment documents and polling the API. Remote Evaluation scales with API call volume against managed Edge/Core APIs or a self-hosted API. Self-hosted deployments add control-plane scaling: API replicas, database capacity, and optional Edge Proxy fleets (each proxy instance polling upstream). Scaling the application and scaling the control plane are separate capacity problems.

Deployment complexity

SOASAP

Control-plane provisioning is not part of application delivery. Complexity concentrates on SDK configuration, secrets, cache paths, and sync-path network access.

Flagsmith managed

Similar application-side deployment: configure SDKs against the managed API, choose evaluation mode, manage keys. Control-plane operations remain with Flagsmith.

Flagsmith self-hosted

Application SDK deployment is joined by control-plane deployment: containers or Helm charts, databases, ingress, certificates, backups, and upgrade procedures. Additional infrastructure ownership is the cost of colocating or isolating the control plane inside customer boundaries. Teams already running mature platform engineering practices may absorb that cost deliberately.

Network dependencies

SOASAP separates the request path (local evaluation) from the synchronization path (managed real-time sync). Request processing does not depend on configuration transport once a snapshot exists.

Flagsmith network dependencies depend on mode: Local Evaluation depends on the API for refresh (and initial load), not for each evaluation after warm state; Remote Evaluation depends on the API on the evaluation path. Self-hosting relocates those endpoints into the customer network but does not eliminate the need for SDK-to-API connectivity for the chosen mode.

Observability

SOASAP operators typically monitor synchronization status, snapshot freshness, cache restoration, and last successful synchronization — separately from application HTTP success rates.

Flagsmith observability spans two layers when self-hosted: SDK/client behavior (refresh success, evaluation mode, offline handler usage) and control-plane health (API, database, proxies, certificates, capacity). Managed deployments shift control-plane metrics to the vendor; customers still need SDK and application signals for freshness and evaluation errors.

Security

Shared concerns include environment keys/secrets, environment isolation, least-privilege access to dashboards, and avoiding privileged server keys in public clients. SOASAP documents environment-scoped API keys and trust boundaries. See API Keys and Security.

With Flagsmith self-hosting, security ownership expands to the control-plane stack: host and cluster hardening, database encryption and access, network policies, identity integration, and patch management. Managed SaaS concentrates those controls with the vendor under the service’s security model. Feature flags on either platform are not a substitute for application authorization.

Self-hosting considerations

When operating a self-hosted Flagsmith control plane, architecture reviews typically cover:

• Kubernetes or equivalent orchestration
• database sizing, HA, and schema upgrades
• persistent storage and backup retention
• upgrade and rollback procedures
• monitoring, alerting, and on-call ownership
• API and proxy scaling
• disaster recovery objectives (RPO/RTO)
• security patching of OS, images, and dependencies
• incident response for control-plane outages that block configuration changes or refreshes

These are standard platform-service concerns. They apply because the organization chose to run the control plane, not because self-hosting is inherently fragile or superior.

Managed cloud considerations

With a managed control plane (SOASAP, or Flagsmith SaaS), operational focus shifts toward application deployment, SDK configuration, authentication and secrets, rollout strategy, and application-side monitoring of freshness and fallbacks. Control-plane capacity and upgrades are outside the customer change window, subject to the vendor’s service model and any contractual constraints (data residency, regions, compliance packages).

Architectural tradeoffs

When SOASAP fits well

• preference for a managed control plane without operating flag infrastructure
• local evaluation with a predictable request path
• explicit persistent cache and offline restart durability
• Kubernetes and backend API workloads where teams minimize platform overhead
• organizations that want operational focus on applications rather than a flag control plane

When Flagsmith may fit well

• organizations that require self-hosting for residency, isolation, or policy reasons
• teams with existing investment in operating Flagsmith or similar platform services
• operational requirements that favor a customer-operated control plane
• existing Flagsmith SaaS or self-hosted deployments and SDK integrations
• architectures that intentionally use Local Evaluation, Remote Evaluation, or Edge Proxy patterns documented by Flagsmith

Decision questions

• Who should operate the feature flag control plane?
• Does the organization prefer managed infrastructure for this dependency?
• Is self-hosting required by compliance, network, or data-residency policy?
• Who performs control-plane upgrades and security patches?
• Who owns disaster recovery for the flag service?
• How important is operational simplicity versus control-plane customization?
• Who monitors infrastructure for the control plane (platform team, vendor, or both)?
• Does the organization already operate Kubernetes platform services at the required maturity?
• Which evaluation modes will each runtime use (local, remote, proxy)?

Common misconceptions

"Managed cloud means no local evaluation."

False. Managed control planes can still distribute configuration for local in-process evaluation.

"Self-hosting automatically improves latency."

False. Latency depends on evaluation mode, topology, and SDK behavior — not solely on who hosts the control plane.

"Running your own control plane removes operational responsibility."

False. Self-hosting transfers operational responsibility to the customer.

"Offline behavior depends only on cloud availability."

False. Offline and restart behavior depend on local state, handlers, cache, and SDK mode.

"All SDKs behave identically."

False. Server-side local evaluation and client-side remote evaluation are different models; defaults vary by runtime.

"Self-hosting and managed SaaS imply different evaluation engines by definition."

False. Hosting model and evaluation mode are orthogonal choices. The same Local Evaluation concepts can apply against a managed or self-hosted API URL.

Related documentation

• Local Evaluation
• Real-Time Synchronization
• Persistent Cache
• Offline Operation
• Non-Blocking Startup
• High Availability
• Security
• API Keys
• Cache Strategy
• Quick Start

External references for Flagsmith deployment and evaluation models: Flagsmith: Platform Architecture, Flagsmith: SDKs Overview.