LoginSign Up
← Back to all sparks
U

Unleash

INFRA · APIS
Velocity5.0

Open-source feature flag and feature management platform.

www.getunleash.io ↗

Unleash argues GitOps stops at deployment — and that flags own what happens after

feature-flagsgitopscompetitive-migrationself-hostingkill-switchescontent-marketing
◆Current state
The window is almost entirely written content with one release in it. The newest post makes the sharpest version of Unleash's argument: GitOps gives you a reconciliation loop, commit hashes and review for deployment and infrastructure, and nothing at all for the runtime decisions taken after the code lands. Around it sit two migration guides published a day apart — LaunchDarkly to Unleash on licensing cost, self-hosting and data residency, and GitLab to Unleash on the fact that GitLab's flags already speak the Unleash API — plus definitional posts on kill switches and dark launches. Unleash 8.1, the only shipped thing here, surfaced pending change requests on project cards.
◆Where it's heading
Unleash is not arguing about features; it is arguing about where the boundary of your delivery pipeline sits. The GitOps piece frames flags as the missing control plane for decisions rather than code, which is the same claim underneath the AI-generated-code kill-switch post and the deploy-versus-release explainer. That positions the product against a practice rather than against a vendor, and it gives the migration guides something to convert people toward. Product work is quiet by comparison — 8.1 was an attention-surfacing pass on the projects page.
◆Prediction
The content keeps pointing at tooling that doesn't yet exist in these entries: a scripted importer for LaunchDarkly and GitLab configurations, or a GitOps-adjacent way to version flag decisions the way manifests are versioned. Nothing here confirms either is being built.

◆Recent moves

  1. 16d ago

    GitOps Deploys Your Code. What Deploys Your Decisions?

    An argument that GitOps's reconciliation loop covers deployment and infrastructure but leaves runtime decisions ungoverned, positioning flags as the control plane for the second half. It is the clearest statement yet of the boundary Unleash is claiming, but it is a blog post, not a product change.

    View source ↗
  2. 23d ago

    How do I reduce risk associated with releasing new features?

    A Q&A post on separating deploy from release, using gradual rollouts and dark launches to contain a bad change to a small audience. Category education that restates the product's premise without changing it.

    View source ↗
  3. 24d ago

    How to Migrate from LaunchDarkly to Unleash

    A migration guide from LaunchDarkly built on licensing cost, self-hosting and data residency, claiming the data move can be scripted through the API. Switching content aimed at a competitor's install base, with no accompanying tool announced.

    View source ↗
  4. 24d ago

    From Feature Flagging to Feature Management: Migrating from GitLab to Unleash

    The GitLab counterpart to the LaunchDarkly guide, published within hours of it. The angle is stronger because GitLab's flags already point at an Unleash-compatible endpoint, so the conversion story needs no SDK rewrite — still marketing rather than a release.

    View source ↗
  5. 25d ago

    What is the difference between GitLab and Unleash feature flags?

    A history post explaining how teams ended up on GitLab feature flags through an Unleash-compatible API around 2019. It sets up the migration guide published the next day; on its own it changes nothing about the product.

    View source ↗
  6. 27d ago

    What is the difference between a dark launch and a kill switch?

    A definitional post separating dark launches from kill switches by timeline and how each is retired. Standard category education, part of the same search-shaped rotation as the rest of the window.

    View source ↗