Where a service runs sounds like a boring detail. In practice it shapes your costs, your risks and your team’s daily life for years.

A feature flag service sits in the middle of your product

A feature flag is a switch that lets you turn parts of your software on or off without releasing new code. Your application asks the flag service a question such as “should this user see the new checkout page?” and the service answers yes or no. Because that question can be asked on every page view, the flag service ends up close to the heart of your product. If it is slow, your product feels slow. If it is down, your product must decide what to do without an answer. If it leaks, your private targeting rules leak with it.

The two options in one sentence each

Flagsmith Cloud is the hosted version, operated by the Flagsmith team, which you use through a web address and pay for according to a plan. Self-hosted Flagsmith is the same open-source software that you install and operate yourself, on servers or containers that you control, usually inside your own cloud account or data centre.

What is at stake

Before comparing the two ways to run it, let us make sure we know what is being run.

What Flagsmith does

Flagsmith stores your feature flags and configuration values and answers questions about them. It gives people a dashboard to manage flags, and it gives applications a way to read them through small code libraries called SDKs. An SDK, short for software development kit, is a ready-made helper that your application uses so that you do not have to write the web requests yourself. There are SDKs for many languages, for web pages, for mobile apps and for servers.

The building blocks

Flagsmith organises things in layers. An organisation is your company. A project is one product. An environment is a copy of the world such as development, staging or production. A feature is a flag or a configuration value. A segment is a saved group of users, such as paying customers. An identity is one particular user. Each environment keeps its own state, so a feature can be on in staging and off in production at the same time.

Two kinds of requests

It helps to separate two traffic types. The first is management traffic: people using the dashboard to create flags, change values and read the audit log. That traffic is small and comes from humans. The second is flag evaluation traffic: applications asking what each flag should be for each user. That traffic can be enormous, because a busy product asks all day long. When people compare cloud and self-hosted, most of the heat is about the second kind, because it is where speed and availability matter most.

Where the software comes from

Flagsmith is open source, so its code can be read and run by anyone. The hosted service runs that same core software with extra infrastructure around it for global reach and scale. Self-hosting means you take the software and run it yourself. There is also a paid enterprise edition with additional features, which can be used in hosted or self-managed ways. Features and editions change over time, so always check the current documentation and your own plan before building a design around a specific capability.

Cloud sounds simple, and mostly it is. But it helps to know exactly what you get and what you hand over.

What you get

With Flagsmith Cloud you sign up, create an organisation and start working. The Flagsmith team runs the servers, the databases, the networks, the backups, the security patching and the monitoring. You use a web dashboard and an API that already exist and already work. When new versions are released, they arrive without you scheduling anything. When something breaks in the platform, the provider is the one who responds.

The edge idea

Large hosted flag services often add a layer designed for fast answers around the world. In Flagsmith’s case, the hosted service includes a globally distributed way of serving flag requests, often called the edge, so a user in Singapore does not have to wait for an answer from a server in another continent. The exact design and regions can change, and you should confirm them in the documentation, but the principle is important: a hosted provider can spread copies of your flag data near your users, which is expensive and difficult to build alone.

What you pay

Hosted plans are usually priced by tiers that depend on how much you use the service, for example the number of requests your applications make, plus the number of people and projects you need and the features you want. There is typically a free or low-cost starting level and higher levels for larger teams and extra capabilities. Pricing changes, so check the current plans instead of relying on any article, including this one.

What you hand over

Self-hosting is freedom with homework. Here is exactly what the homework involves.

What you run

When you self-host Flagsmith, you run the Flagsmith application on infrastructure you control. In simple terms, you need a place to run the application containers, a database to store flags and settings, and a way for users and applications to reach it over the network. Teams commonly run it with containers on a single server for small setups, or with a container orchestrator such as Kubernetes for larger ones. A database that stores everything permanently is essential, and many setups add a cache and a separate background worker for tasks like webhooks and audit processing.

Who is responsible

Everything the hosted provider would do for you becomes your job. You choose and size the servers. You apply updates, and you decide when. You back up the database and, more importantly, you test restoring from those backups. You watch the system, set up alerts and answer them when they fire. You secure the network, the database, the secrets and the certificates. You plan for failures and for growth.

What you pay

The software itself is open source, so there is no licence fee for the basic version. But the real costs are the servers, databases and network traffic you pay your cloud provider, plus the engineer time to build and run it. If you need enterprise features that are sold under a commercial licence, there is also that licence cost. People often compare only the licence fee and forget the human cost, which is usually larger.

Why teams do it anyway

A picture makes the difference clear. Here is how the pieces fit in each option.

flowchart TB
    subgraph CloudSide["Flagsmith Cloud"]
        direction TB
        CA["Your Apps and SDKs"] --> CB["Provider Edge Network"]
        CB --> CC["Provider Core API"]
        CC --> CD["Provider Databases"]
        CE["Your Team Dashboard"] --> CC
    end
    subgraph SelfSide["Self-Hosted Flagsmith"]
        direction TB
        SA["Your Apps and SDKs"] --> SB["Your Load Balancer"]
        SB --> SC["Your Flagsmith API Containers"]
        SC --> SD["Your Database"]
        SC --> SE["Your Cache"]
        SC --> SF["Your Task Worker"]
        SG["Your Team Dashboard"] --> SB
    end

Walking through the diagram

The top half shows Flagsmith Cloud. Your applications and your team connect to the provider, and everything behind the curtain belongs to the provider: the edge network that answers quickly, the core service that handles management, and the databases that keep everything safe. You never see those boxes, and you never pay to run them directly.

The bottom half shows self-hosted. Every box is yours. Applications reach a load balancer that you configure. Behind it are one or more Flagsmith containers that you run. Those containers talk to your database, your cache and your background worker. Your team uses the same entrance for the dashboard. Each box is a thing that can be sized well or badly, secured well or badly, and watched well or badly.

The components in plain words

Let us follow a single question, “is this flag on for this user?”, through both setups, and notice where time and risk hide.

sequenceDiagram
    participant U as User Device
    participant A as Your Application
    participant S as Flagsmith SDK
    participant F as Flagsmith Service
    participant D as Data Store
    U->>A: Opens a page
    A->>S: Is new checkout on for this user
    alt Answer already stored in SDK memory
        S-->>A: Returns stored answer instantly
    else Answer not stored or expired
        S->>F: Asks for flags for this user
        F->>D: Reads environment settings
        D-->>F: Returns settings
        F-->>S: Returns flag values
        S-->>A: Returns answer
    end
    A-->>U: Shows the right experience

Reading the sequence

A user opens a page. Your application needs to know whether to show the new checkout, so it asks the Flagsmith SDK. If the SDK already holds a recent answer in memory, it replies instantly and nothing leaves your server. If not, it asks the Flagsmith service, which reads the environment settings from its data store and returns the flag values. The SDK passes the answer back and your application shows the right experience.

The key lesson is that the Flagsmith service is not always in the path. Good SDK setups keep answers in memory, refresh them in the background and can even evaluate flags locally inside your own server using a copy of the rules. This means the speed and availability of the flag service matter less to each individual user request than you might fear, and it changes how you weigh cloud against self-hosted.

Pointing an SDK at the right place

SDKs normally talk to the hosted Flagsmith address by default. If you self-host, you tell each SDK the web address of your own deployment, using a setting that all SDKs provide. That one setting is the switch between cloud and self-hosted from the application’s point of view, which makes moving between them far easier than people expect, as we will see in the migration chapter.

Speed is the first thing people ask about. The honest answer depends on where your users are and how your SDKs are set up.

What latency means

Latency is the delay between asking a question and receiving the answer. It is mostly governed by distance and work. Distance matters because signals take time to cross the world, even at the speed of light in fibre. Work matters because the service must read data, apply rules and build a response. A request across an ocean can easily cost many tens of milliseconds more than a request across a city, and that cost is added every time the question has to leave your own machine.

Cloud and latency

A hosted provider with a distributed edge can place answers close to users in many regions. For a product with customers spread across continents, especially one that evaluates flags from browsers and mobile apps, this is a big advantage. Without any effort on your side, a user far from your main servers still gets quick answers.

Self-hosted and latency

A self-hosted deployment lives where you put it. If you deploy it in the same region as your servers, calls from your servers are very fast, often faster than going out to a public service, because the traffic stays on your own network. But a mobile user on the other side of the planet must travel to your region. To match global edge performance you would need to deploy several copies in several regions and keep their data in sync, which is possible but is real engineering work.

The SDK changes the story

For server-side applications, there is a powerful technique called local evaluation. The SDK downloads the flag rules once, keeps them in memory, refreshes them every so often, and answers every question locally without any network trip. When you use it, the flag service is only contacted occasionally in the background, so each user request is as fast as reading from memory. In that mode, the latency gap between cloud and self-hosted almost disappears for your server code. Browser and mobile apps are different, since they cannot safely hold all the rules, so they usually ask the service and benefit more from a nearby edge.

When the flag service has a bad day, what happens to your product? And who is responsible for fixing it?

Key words

Availability is the share of time a service is reachable and working, often written as a percentage such as ninety-nine point nine. Reliability is a broader idea, covering whether the service does the right thing consistently. A system can have a high availability number and still occasionally return wrong answers, so both matter. Redundancy means having spare copies so one failure does not stop everything. A single point of failure is any single part whose failure stops the whole system.

Cloud availability

A hosted provider runs the service as its core business, with teams on call, redundancy across zones and regions, and years of lessons from many customers. It is unlikely that a small company would match that quality for a flag service quickly. But you still depend on the provider. If they have an outage, you cannot fix it, and you wait for their recovery. Provider status pages and service agreements tell you what to expect, and larger plans may include stronger commitments.

Self-hosted availability

For self-hosted, availability is whatever you build. A single container on a single server is easy but fragile. To reach high availability you need several copies of the application behind a load balancer in more than one zone, a database that can survive a server failure, tested backups and monitoring that wakes someone up. Each of these is achievable, and a team that already runs databases well may find it natural. But each is something you must design, test and keep working.

Designing for the flag service being unavailable

Whichever option you choose, a wise design assumes that the flag service will sometimes be unreachable. Several protective habits help.

• Set default values in code so the application behaves safely when no answer arrives.
• Let SDKs keep the last known answers in memory or storage so a short outage goes unnoticed.
• Prefer local evaluation on servers, so flag decisions do not depend on a live call.
• Use short timeouts so a slow flag service never makes the whole page slow.
• Test the outage on purpose, by blocking the flag service in a test environment and watching what happens.

Security reviews often decide the question before anything else is discussed. Let us see what each option offers and demands.

What is actually sensitive in a flag service

People sometimes think flags are harmless on and off switches. In reality a flag service can hold sensitive material. It stores targeting rules that reveal business plans, such as which customers get a new pricing page. It may receive user identifiers and traits that you send for targeting. Its audit log reveals who changed what. Its administrative access can change what your application does in production within seconds. Protecting all this matters.

Cloud security

A hosted provider invests in security staff, monitoring, patching, encryption and independent audits, which large vendors usually describe through recognised certifications. Many buyers value that they can ask for the provider’s security documents and attach them to their own review. The shared responsibility idea applies: the provider secures the platform, while you secure your account, your users, your access keys and the data you choose to send. Strong sign-in, access controls and careful handling of keys remain your tasks.

Self-hosted security

With self-hosting, the platform security is also yours. You decide who can reach the service, how traffic is encrypted, where secrets are stored, how the database is protected and how quickly patches are applied. This can be a major advantage for organisations with strong security teams who want the service inside private networks with no public exposure at all. It is a risk for teams without that depth, because an unpatched or misconfigured server is an easy target.

Compliance in plain words

Compliance means showing that you follow certain rules, laws or standards, for example those that protect personal data or require records of changes. Auditors typically ask where data is stored, who can access it, how long it is kept, how it is protected and how changes are tracked. Hosted vendors often make this easier by providing ready documentation. Self-hosting can make some requirements easier, such as keeping everything inside a specific country or network, but you must produce your own evidence.

Some organisations are legally or contractually required to keep data in particular places. For them, this chapter may be the whole decision.

What data Flagsmith holds

Flagsmith holds your configuration data: projects, features, values, segments and the audit log. If you use identities, it can also hold user identifiers and traits that your application sends. You control how much personal information goes in. A privacy-friendly practice is to send only opaque identifiers, such as random user numbers, and only the traits you truly need for targeting.

Data residency and sovereignty

Data residency means keeping data in a certain geographic area. Sovereignty goes further, concerning which country’s laws apply to the data and who can compel access to it. Some public bodies, banks, hospitals and companies that serve them must meet these conditions. Hosted providers may offer deployments in particular regions, which helps in many cases, but the details vary and must be confirmed. When the rule is strict, self-hosting inside the required country or inside your own private network gives the clearest answer, since you know exactly where every byte sits.

Questions to ask

Prices on a web page tell only part of the story. The honest comparison counts everything, including people.

What total cost of ownership means

Total cost of ownership, often shortened to TCO, is the full cost of using something over time, not only the price you see at the start. For a flag service it includes the subscription or licence, the servers and databases, the network traffic, the monitoring tools, the security tooling, and above all the time of the engineers who build and run it. It also includes the cost of risk, such as the cost of an outage or a security incident.

Cloud cost shape

Cloud costs tend to be easy to predict at small scale and to grow with usage. You pay a plan fee that depends on tier and consumption, and you pay almost nothing in engineering time. At very large volumes, usage-based pricing can become a major line in the budget, so teams watch request counts and use caching and local evaluation to reduce unnecessary calls.

Self-hosted cost shape

Self-hosted costs tend to be fixed and front-loaded: you pay to build, then pay a steady amount to run. The software is free in its open-source form, but servers, database, network and monitoring all cost money, and several skilled people must spend part of their time on it. At small scale this is usually much more expensive than a hosted plan. At very large scale, an efficient team may run it cheaper, but only if it counts people honestly.

A simple cost comparison

Hidden costs people forget

• The engineer who knows the self-hosted setup goes on holiday or leaves the company.
• Upgrades are delayed because nobody has time, so security fixes pile up.
• The database grows, performance drops and nobody noticed until a busy day.
• A cloud plan jumps to a higher tier because traffic crossed a threshold unexpectedly.
• The cost of switching later, which is lower if you planned for it from the start.

Running a service is a job that never ends. Here is the full list of chores that self-hosting adds to your calendar.

Installing and configuring

Someone must choose how to deploy: plain containers, a container orchestrator or a managed container service. Someone must configure environment settings, certificates, domain names, secrets and network rules. This first stage is the part most people picture, and it is usually the easiest, because good documentation and deployment examples exist.

Upgrading

New versions arrive with fixes, features and security patches. Self-hosting means you read the release notes, test the new version somewhere safe, back up the database, apply the upgrade and watch for trouble. If you skip upgrades for too long, the jump to the latest version becomes bigger and riskier, and you may miss security fixes. A good habit is to upgrade regularly in small steps.

Backups and recovery

A backup is a copy of your data that you can restore if something goes wrong. The important truth is that a backup you have never restored is only a hope. Schedule backups, store them in a separate place, protect them with encryption and practise restoring them. Decide how much data loss you can accept, called the recovery point, and how long you can be down, called the recovery time, and design backups to meet both.

Monitoring and alerting

You need to know when the service is slow, failing or filling its disk. That means collecting measurements, drawing dashboards and creating alerts that reach a real person who knows what to do. Flagsmith provides ways to expose operational metrics that common monitoring tools can collect, but you must set up the monitoring tools and write the alert rules.

On-call and incident response

When the service fails at night, somebody has to respond. That means a rota, a runbook, access rights and the confidence to act. Even if the flag service rarely fails, the existence of the duty is a real cost, especially for small teams.

Today’s traffic is not tomorrow’s. Let us see how each option copes when usage grows tenfold.

What scaling means

Scaling is the ability to handle more load without breaking. Vertical scaling means making one machine bigger. Horizontal scaling means adding more machines to share the work. Stateless parts, which do not remember anything between requests, are easy to scale horizontally. The database, which does remember, is usually the harder part.

Scaling in the cloud

With a hosted service, scaling is mostly the provider’s problem. You send more requests and the platform absorbs them, possibly with a change in your pricing tier. The things to watch are plan limits, fair use rules and cost. This is a major reason fast-growing products start with the hosted option.

Scaling when self-hosted

For self-hosted, the application containers are straightforward to multiply behind a load balancer. The database is the point to plan for: you may need a larger instance, read copies to share the load, careful indexing and caching to reduce repeated reads. Background work such as webhooks and analytics processing may need its own dedicated workers so it does not compete with request handling. Load testing before launches shows where the first bottleneck will appear.

Ways to reduce load in both worlds

Both options share a common core, but the extras you can use depend on the edition and plan you have.

The shared core

Whether you use the hosted service or run it yourself, the core abilities are the same: feature flags, remote configuration values, environments, segments and identity-based targeting, multivariate values for experiments, an audit log, role-based team management, webhooks and a family of SDKs. Because the same open-source engine sits behind both, the way flags behave from your application’s point of view is consistent.

Editions and plans

Beyond the core, there are extras that are usually tied to paid plans or enterprise editions. Examples that products in this category commonly offer include single sign-on, finer access control, approval workflows for changes, scheduled changes, deeper audit capabilities, extended history and dedicated support. Which extras exist, in which edition, and on which plan changes over time. A common trap is to assume a feature included in a hosted plan is available in the free self-hosted version, or the reverse. Always list the features you truly need and then check them against the current documentation for the exact way you plan to run Flagsmith.

Features that depend on the hosting model

Sometimes the question is not where it runs but how much it can bend to your needs.

Integrating with your tools

Both options can talk to your other tools through the same mechanisms: a management API for automation, webhooks that announce changes, and built-in integrations with popular tools for chat, monitoring and analytics. Because these are features of the product, they behave similarly under either model. A key difference is networking: a self-hosted deployment can reach private internal tools directly, such as an internal chat server or a private monitoring system, while a hosted service can reach only what is reachable from the public internet, unless you open a safe path.

Private connections

When webhooks need to land on a private service, the self-hosted option is simpler. The sender lives in your network and can call internal addresses without any exposure. With the hosted option, you need a public receiver that is carefully protected with signatures and network rules, or you must place a small public gateway in front of the private service. This is an everyday reason why security-focused teams lean toward self-hosting.

Changing the software itself

Because the core is open source, a self-hosting team can read the code, tune settings in depth and, if truly necessary, make modifications. In practice, most teams should avoid modifying the code, because every change makes upgrades harder. The value of open code is more often transparency, the ability to inspect behaviour, understand failures and contribute fixes, than custom forks.

A good decision includes an easy way to reverse it. Here is how locked in you really are under each choice.

What lock-in means

Lock-in is how costly it is to leave a product once you depend on it. High lock-in means that leaving requires rewriting lots of code or losing data. Low lock-in means that you can move with modest effort. It is wise to ask about lock-in on day one, because the cheapest time to design an exit is before you need one.

Why Flagsmith lock-in is relatively low

Several features reduce lock-in. The core is open source, so a hosted customer always has the option to run the same engine themselves. Application code talks through Flagsmith SDKs using a small number of calls, and the address of the service is a setting. And the flag data itself, features, segments, environments, can generally be exported or recreated through the management interface, though the exact methods and completeness should be tested rather than assumed. These facts mean that moving between hosted and self-hosted is far easier than moving to an entirely different product.

Protecting your freedom to leave

• Wrap flag reads in a small layer of your own code so only one place knows which service you use.
• Keep a regular export of your flag configuration in a safe place under your control.
• Use clear, consistent naming for flags, segments and environments so they are easy to recreate.
• Avoid depending on a feature that exists in only one hosting model unless you truly need it.
• Practise the migration once in a test environment before you ever need it in earnest.

Enough comparison. Here is a simple way to reach a decision, followed by a questionnaire you can fill in with your team.

flowchart TD
    A["Start: where should Flagsmith run"] --> B{"Is data location or network isolation legally required"}
    B -- Yes --> C{"Can the hosted option meet the rule in writing"}
    C -- Yes --> D["Consider Cloud with the right region or private arrangement"]
    C -- No --> E["Choose Self-Hosted"]
    B -- No --> F{"Do you have a team able to run databases and be on call"}
    F -- No --> G["Choose Cloud"]
    F -- Yes --> H{"Do you need global low latency for browser and mobile users"}
    H -- Yes --> I["Lean to Cloud or a multi-region plan"]
    H -- No --> J{"Is your traffic so high that usage pricing hurts"}
    J -- Yes --> K["Model the cost and consider Self-Hosted"]
    J -- No --> L["Lean to Cloud and revisit yearly"]

Reading the decision path

The first question is about rules, because rules are not negotiable. If the law or a contract demands that data stay in a particular place or network, you check whether the hosted option can satisfy that in writing. If it can, cloud may still work. If it cannot, self-hosting is the answer and the rest of the discussion is about how to do it well.

If no such rule exists, the second question is about people. A team that cannot run databases and take night calls will struggle with self-hosting, and the honest answer is cloud. If you do have the skills, the next question is about your users. Global browser and mobile audiences favour the hosted edge. Finally, if usage is so large that pricing hurts, model both costs honestly before deciding. In most other cases, start with cloud and revisit the decision once a year.

A team questionnaire

Abstract advice is easier to trust when it is attached to a story. These imaginary companies show how the same questions lead to different answers.

Your first choice does not have to be your last. Many teams mix the two or move from one to the other as they grow.

Hybrid thinking

A hybrid setup uses both models for different purposes. A company might use Cloud for its public consumer product, where global reach matters, and self-hosted for an internal regulated system where isolation matters. Another might use Cloud for development and staging, where convenience wins, and self-hosted for production, where control wins. The key is to keep naming, structure and processes consistent so people do not need to learn two different ways of working.

Migration in simple stages

flowchart LR
    A["Plan and inventory flags"] --> B["Stand up the new Flagsmith"]
    B --> C["Recreate or import configuration"]
    C --> D["Verify values match in test"]
    D --> E["Point a small share of apps to the new address"]
    E --> F{"Everything healthy"}
    F -- Yes --> G["Move remaining apps in waves"]
    F -- No --> H["Roll back by restoring the old address"]
    G --> I["Keep the old setup read-only for a safety period"]
    I --> J["Retire the old setup"]

Walking through the stages

The journey starts by listing what you have: every project, environment, feature, segment, team member and integration. Then you stand up the destination, whether that is a new cloud organisation or a new self-hosted deployment. Next you bring configuration across, using the management interface and any import or export tools available for your version, and you verify that values for each flag match in a test environment. Remember that environment keys are different in the new place, and that each application must be updated to use the new keys and, when moving to self-hosted, the new service address.

Then you move gradually. A small share of applications switch first, so any surprises affect only a little traffic. If something looks wrong, you roll back by pointing the applications back at the old address. If everything is healthy, you move the rest in waves. You keep the old setup in a read-only state for a while as a safety net, and only then retire it.

Teams that have lived with either choice for years tend to repeat the same smart habits, and the same unhappy mistakes.

Patterns that work

Anti-patterns to avoid

A short checklist of habits that work under either option, and mistakes that cause pain under either option.

Protecting against the single expert problem

A self-hosted flag service often starts as one engineer’s project. That engineer builds it, understands it and fixes it. The risk is obvious: when they move on, the knowledge goes with them. Write simple documentation, share the on-call duty among several people and run recovery drills with different team members each time. A system that only one person can run is a system on borrowed time.

Protecting against the surprise bill

For cloud users, the equivalent risk is a bill that grows without anyone noticing. Set a budget alert if the plan allows it, watch your request counts each month and keep an eye on any release that changes how often SDKs ask the service. Often a single misconfigured polling interval creates most of the traffic.

If you are leaning toward self-hosting, use this checklist to find out honestly whether you are ready, before you build anything.

People and process

• At least two people can deploy, upgrade and troubleshoot the service.
• There is an on-call rota that includes the flag service, and a written runbook.
• Someone owns the upgrade schedule and the security patching.
• A named owner approves access to the production flag environment.

Infrastructure

• Several copies of the application run behind a load balancer, ideally in more than one zone.
• The database has a plan for failure, such as a standby copy, and enough room to grow.
• A background worker runs separately from the web-facing containers where load demands it.
• Certificates, domain names and secrets are stored and renewed with a clear process.

Data safety

• Backups are automatic, stored in a separate location and encrypted.
• A restore has been rehearsed recently and the time it took is written down.
• You know how much data you can afford to lose and how long you can afford to be down.

Visibility

• Dashboards show request rate, error rate, response time, database health and disk space.
• Alerts reach a human and are tuned so that they are not ignored.
• Logs are collected and kept long enough to investigate incidents.

The cloud versus self-managed question is not unique to Flagsmith. Many well-known products offer both, and their users have learned useful lessons.

Let us walk one imaginary company through the whole decision, so you can see the framework used on real-feeling facts.

The company

Imagine a travel booking company called Wayfarer. It has a website, two mobile apps and about forty engineers. It serves customers in Europe, North America and South-East Asia. Payments and personal data are handled by a separate, tightly controlled system. The product team wants to roll out new search results gradually, test a new booking flow and switch off risky features quickly during peak holiday traffic. There is no dedicated platform team, but there is a small operations group that runs the main database and the company’s cloud account.

Step one: list the constraints

The team starts by writing down what cannot be negotiated. They check with legal and security and learn that flag data will contain only random user identifiers and simple traits such as a plan type, never names or emails. The security team confirms that a hosted flag service is acceptable if the vendor can provide standard security documentation. There is no rule that forces the data to stay inside the company network. So the first branch of the decision framework leads to the next question.

Step two: assess the skills

The operations group is small and already stretched. They could run another database service, but it would compete with higher-priority work, and the idea of adding another night-time pager rotation is not welcome. This points toward Cloud.

Step three: look at the users

Wayfarer’s customers are spread over three continents and mostly use browsers and mobile apps. Every extra hundred milliseconds on a search page costs bookings. A hosted edge that answers near the customer is attractive. Building the same reach alone would require several regional deployments, each with its own database copy and its own monitoring.

Step four: model the cost

The team estimates monthly request volume from analytics, assuming good SDK habits such as caching and local evaluation on servers. They compare the hosted plan against a self-hosted setup in three regions, and they honestly price the engineer time: setup, upgrades, backups, monitoring and on-call. The hosted plan costs far less than the combined price of servers and people at their current volume. Only at many times their present traffic would the comparison become close.

flowchart TD
    A["Wayfarer constraints reviewed"] --> B["No legal need for private hosting"]
    A --> C["Small operations group already busy"]
    A --> D["Users spread across three continents"]
    A --> E["Cost model favours hosted plan"]
    B --> F["Decision: start with Flagsmith Cloud"]
    C --> F
    D --> F
    E --> F
    F --> G["Safe defaults and local evaluation in servers"]
    F --> H["Wrapper layer around flag reads"]
    F --> I["Yearly review with new traffic and cost data"]
    I --> J{"Rules or volume changed"}
    J -- Yes --> K["Plan a staged migration to self-hosted"]
    J -- No --> L["Stay on Cloud"]

Reading the picture

Four separate lines of evidence feed into one decision. Each is simple and independent, which is what makes the outcome trustworthy. Notice the three actions that follow the decision. The team adds safe defaults and local evaluation so the product works even if the flag service is unreachable. They add a thin wrapper around flag reads so the service address is a single setting. And they schedule a yearly review so the decision is revisited with real data rather than inherited by habit.

Eighteen months later

A year and a half on, Wayfarer signs a large contract with a public-sector customer who requires that all related systems run inside a specific country and within a private network. The team reviews the decision, as planned. For the new customer only, they deploy a self-hosted Flagsmith inside the required environment, using the same naming conventions and the same wrapper layer. The rest of the company stays on Cloud. Because the application code only needed a different service address and keys, the new deployment takes weeks, not months. The earlier habits turned a potential crisis into a project.

Everyone says compare the cost. Few explain how. Here is a simple, honest method that you can run in an afternoon with a spreadsheet.

Step one: estimate your traffic honestly

Begin with what your applications will actually ask. Count the number of application servers, the number of mobile and browser sessions per day, and how often each SDK refreshes or asks the service. Then apply your caching and local evaluation plans. Many teams find that smart SDK settings cut their service calls dramatically. Write the result as a monthly request estimate, with a pessimistic number for busy seasons and launches, since those are the months that decide costs.

Step two: price the hosted option

Take the current plan pages and find the tier that matches your traffic, your number of team members and the features you need, such as access controls or approval steps. Add any extra charges for usage above included limits. Then add a margin for growth over the next year. Because prices change, use the numbers from the vendor’s current page on the day you do the exercise, and note the date.

Step three: price the self-hosted option

List every component: application containers, a database with room to grow and a standby copy, a cache if used, a background worker, a load balancer, storage for backups, monitoring tools, log storage, certificates and network traffic charges. If you need multiple regions to match global reach, multiply the infrastructure accordingly. Add the licence cost if you need enterprise features sold commercially.

Step four: price the people

This is the step that most teams skip. Estimate the hours per month for patching, upgrading, backup testing, monitoring tuning, incident response and answering questions from colleagues. Add the one-off setup time, spread across a few years. Multiply by a realistic fully loaded cost for an engineer, which includes more than the salary. Include the cost of being on call, such as the extra people needed to share the rota fairly.

Step five: price the risk

Think about the cost of an outage or a security incident, and how the likelihood differs between the two options for your team. This is not an exact science. But it forces a conversation. If an hour of downtime in your product costs a lot, then a more mature operations setup, whether the provider’s or yours, is worth paying for.

Step six: test the answer

Change the assumptions and see how the answer moves. What if traffic doubles? What if one engineer leaves? What if you need a second region? What if the vendor raises prices by a fifth? A good comparison is not a single number but a range, and a clear idea of which assumption matters most. Often it is the cost of people, and in many cases it is the traffic estimate.

Every option fails sometimes. What matters is how it fails, who is responsible, and what you can do about it.

Scenario one: the flag service becomes unreachable

In Cloud, the provider’s service has an incident and requests fail or slow down. You can check the provider’s status page and wait for recovery, but you cannot fix the platform. Your protection is on your side: defaults in code, SDK caches, local evaluation and short timeouts mean your product keeps working in a known safe way. In self-hosted, the same symptom might come from a failed container, an overloaded database or a network fault. Your protection is the same defaults, plus the ability to act: restart containers, fail over to a standby, add capacity or roll back a bad upgrade.

Scenario two: a bad release of the flag software

In Cloud, a new version introduced by the provider could contain a bug that affects some customers. You depend on the provider’s testing and rollback. In self-hosted, you choose when to upgrade, so a bad release cannot surprise you unless you apply it. You test first, upgrade in a quiet period and keep the ability to roll back. This is one area where self-hosting gives you timing control, balanced by the risk of neglecting upgrades altogether.

Scenario three: a traffic surge

A marketing campaign sends five times the usual traffic. In Cloud, the platform absorbs the load, and you may move into a higher usage tier. In self-hosted, you must have capacity ready. If you tested for the surge and your containers can multiply quickly, all is well. If not, the database becomes the bottleneck, and requests slow down. Load testing before big events is the discipline that separates calm launches from stressful ones.

Scenario four: a leaked access key

Someone commits a management key into a public code repository. In either model, the immediate response is the same: revoke the key, create a new one, review the audit log for unexpected changes and check whether any flags were altered. In self-hosted, you may also need to review server logs, since you own the whole stack. In Cloud, the audit trail and access controls are provided by the product, and the provider can help with platform-level questions.

Scenario five: data loss

In Cloud, the provider is responsible for backups and recovery of the platform, and you can ask about their policies and test your own exports. In self-hosted, you carry the whole duty. A database failure with no tested backup is the nightmare scenario: all flags, segments and history may be lost. Scheduled backups, off-site copies and a rehearsed restore are essential. Even in Cloud, keeping your own export of configuration is a wise precaution.

The common thread

In every scenario, the best protection is the same, whichever model you choose: assume the service will occasionally be unavailable, design your application to behave sensibly without it and practise the recovery steps. The model decides who performs the repair. Your preparation decides whether anyone notices the fault.

Good decisions come from good questions. Use these lists in your evaluation meeting, one for the provider and one for your own team.

Questions for the hosted provider

Questions for your own team

Turning answers into a decision

After collecting answers, give each topic a simple score for each option: how well does it meet our need, how risky is it, and how reversible is it. Share the scores with the whole group, including the people who will carry the pager and the people who sign the contracts. Look for any single topic where one option fails outright, such as a legal rule, because that overrides everything else. For the rest, choose the option that satisfies your must-haves with the least ongoing effort, and write down the conditions under which you would review the choice.

Every important word used in this guide, in plain language, for quick lookup.

Short answers to the questions people ask most often when choosing.

Everything in this guide comes down to a handful of ideas you can carry into your decision meeting.

Flagsmith Cloud and self-hosted Flagsmith are two ways to run the same open-source engine. Cloud gives you speed, global reach and freedom from operations. Self-hosted gives you control, privacy and the ability to run inside your own walls, at the price of owning every chore. The decision is not about which is better in general. It is about which fits your rules, your skills, your users and your budget today, with a clear path to change later.