Self-Host FeatBit and Expose Only the SDK Endpoints You Need

One practical way to reduce the attack surface of your feature flag infrastructure is to self-host FeatBit, keep its services on a private network, and expose only the SDK endpoints your public applications actually need through a reverse proxy.

Recently, more FeatBit customers have been asking how to keep their deployments private while letting applications reach only the interfaces they need. We wrote this article to explain the security principles behind that choice.

Why a smaller public surface matters now

Serious security disclosures in 2026 have reached across language runtimes, certificate infrastructure, cloud platforms, and AI tooling. Some concern newly discovered vulnerabilities; others describe intrusions that already happened. AI features in both vulnerability discovery and attack execution, while exposed services and powerful credentials remain recurring problems.

Several examples show why teams are revisiting what they make publicly reachable:

• PHP: critical unauthenticated remote code execution, 21 October 2026. The PHP team released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two memory-safety vulnerabilities that could allow unauthenticated remote code execution. Its advisory identified PHP installations serving web requests as at risk, with a demonstrated exploit against mod_php that could run before application code. See the official PHP security advisory.

• eMudhra: compromised intermediate certificate keys, reported 17 October 2026. Mozilla confirmed compromise of eight intermediate CA private keys: six used for TLS certificates and two for code signing. Investigators independently recovered the keys because of flawed key generation, and Mozilla moved to distrust the affected certificates. An investigator also reported recovering them with local AI agents. The Mozilla incident record documents the affected keys and response. This was a failure in certificate infrastructure itself.

• Wiz CIRT: an AI-driven intrusion across cloud infrastructure, 19 October 2026. Investigators described an operation that entered through an exposed Kafka UI instance using a Java remote code execution vulnerability, then harvested credentials and moved across Kubernetes, cloud accounts, CI/CD, and identity systems. The Wiz investigation shows how an internet-facing developer service can become an entry point into a much larger environment.

• Binance: a major intrusion involving internal AI tooling, initial findings published 3 November 2026. Binance reported that approximately $6.34 billion in digital assets were affected by its 29 October incident. Its initial findings described compromised endpoints, stolen credentials, and an internal AI tool used as a springboard toward wallet infrastructure. The initial incident report states that the investigation was ongoing.

• Zeabur: exposed administration and platform credentials, 19 October 2026. Zeabur's preliminary report described attackers using leaked internal credentials to enter its shared cluster and other systems and read environment variables from the platform database. The report identified long-lived administrative credentials usable from the public internet and described blocking public access to management interfaces as part of containment. See Zeabur's October incident report.

• METR: an AI-built dashboard exposed an API key, disclosed 31 August 2026. A fail-open authentication flaw left an agent dashboard publicly accessible. An attacker prompted the agent to reveal a provider API key and consumed donated credits valued at approximately $600,000. METR reported no evidence of sensitive information being accessed. Its security update describes the incident and subsequent network-isolation changes.

• FortiGate: AI-assisted compromise at scale, reported 20 February 2026. Amazon Threat Intelligence reported more than 600 devices compromised across over 55 countries. It attributed access to exposed management interfaces and weak credentials with single-factor authentication, with AI helping scale the operation. Amazon's investigation gives a concrete example of familiar security gaps becoming easier to exploit repeatedly.

These events have different root causes and require different responses: runtime patches, certificate and trust-store remediation, credential rotation, stronger authentication, and network isolation. Reducing public ingress adds another layer by removing entry points that applications do not need. Internal access controls also limit what a compromised public-facing component can reach.

Our takeaway for feature flag infrastructure is practical: every service that does not need to accept internet traffic is a candidate to keep private. Every public route should have an application requirement behind it.

Self-hosted feature flags give your team control over those network boundaries. Keeping management and supporting services private, while exposing a small SDK allowlist, is one way to use that control. Patching, authentication, credential management, and monitoring remain part of operating the deployment.

Keep management private and SDK access narrow

A system's attack surface includes the places an attacker can try to enter or extract data. Reducing it means removing unnecessary opportunities to interact with the system, including services that applications never need to reach from the internet.

Separate the work people do to manage the platform from the requests applications need to make. Staff can reach management tools through approved private access. Public applications get a narrow gateway to necessary functions; databases and supporting services stay behind that boundary.

Private services with a narrow public SDK gateway. AI-generated illustration.

The reverse proxy is a policy boundary: it admits explicitly allowed application traffic and rejects the rest. That boundary works when the services behind it also remain private, so requests cannot bypass the gateway.

Self-hosting gives your team control over this separation. If every application already runs within a private network, you may need no public FeatBit endpoint at all. Access within that network should still require the appropriate identity and permissions.

Allow only the routes your client SDKs use

For a deployment where server-side SDKs and management traffic stay private, start with the policy below. Confirm the paths and behavior against the Agent and SDK versions you deploy.

The Agent's SDK controller, event controller, and management controller provide a concrete reference for these HTTP routes. The /api/public/ prefix is a route name; it is not a recommendation to publish the whole prefix.

Treat streaming connection types separately

Both client and server SDKs use /streaming. A proxy rule that allows that path without inspecting the connection type is broader than the policy above.

When only client streaming is needed publicly, permit type=client and reject other types. Parse query parameters consistently with the upstream, reject ambiguous duplicate type parameters, and preserve the token and protocol parameters the SDK sends. A query value is a routing condition, not proof of identity: FeatBit's SDK authentication must still run. The streaming connection types distinguish client, server, and relay-proxy.

Use client SDK keys in public applications and protect server SDK secrets and Agent management credentials. The server and client evaluation key guide explains that separation. Keep sensitive values out of client-visible flag data, and enforce application permissions on the backend.

Choose streaming, polling, and events deliberately

The smallest allowlist depends on actual SDK behavior:

• Streaming only: allow client streaming. Close the client polling route after confirming the SDK does not need it for initialization or recovery and polling fallback is disabled.
• Polling only: allow client polling and keep streaming closed. Flag update timing follows the configured polling interval.
• Streaming with polling fallback: allow both client synchronization routes so fallback can work.
• Events: allow tracking when the public SDK sends events you use. If you intentionally disable reporting, close the route and account for the loss of evaluation or experiment data.

For example, the JavaScript SDK exposes enablePollingFallback and disableEvents in its SDK options. Other SDKs and versions can differ; verify each one your applications use.

Illustrative configuration: streaming and events enabled, polling closed. AI-generated illustration.

Security comes from layers of protection

Network isolation determines who can connect. Authentication establishes identity. Authorization limits what that identity can do. Each contributes a different boundary. This is the idea behind defense in depth: several layers of protection, so a failure in one layer meets another barrier.

Three principles matter alongside a smaller public surface:

• Least privilege: give each person and service only the access needed for its job. An application that reads a flag should not gain the authority to manage the platform. NIST's least-privilege principle applies to both people and software.
• Containment: assume a public-facing component or credential could be compromised. Restrict its permissions and internal reach so that one failure has a smaller impact. Private networks also need access controls between services.
• Ongoing maintenance: keep software and certificates current, protect and rotate credentials, and monitor unusual activity. These controls address risks that remain even when unnecessary public routes are closed.

Review reachability, authority, and the consequences of compromise together. That gives self-hosting a concrete security purpose: control the boundaries around your infrastructure and keep them aligned with what your applications actually need.

Basic security work deserves our attention

Private networks, small public interfaces, and scoped permissions are familiar security foundations. Helping customers apply them is part of making self-hosted feature flags useful in production.

Customers should be able to keep FeatBit under their own control and make the public surface as small as their applications allow. Even when the work is basic, we are willing to help teams strengthen those boundaries. Our customer security and privacy principles reflect that commitment.

Image disclosure: The cover and illustrations in this article were generated with AI.