V2 Alpha Feedback

[markphelps]

🚀 Flipt v2 Alpha Release

We're excited to share the alpha release of Flipt v2, a ground-up reimagining of Flipt focused on flexibility, composability, and GitOps-native workflows.

Re: #3828

🔍 What's New in v2?

• Environment-Scoped Configuration: Native support for managing multiple environments (e.g., staging, prod) in a single deployment.
• Composable Storage Backends: Choose between in-memory, filesystem, or Git-backed storage—per environment. Easily support GitOps-style workflows by syncing to Git remotes.
• Declarative by Default: All configuration is now defined via flat files in a directory structure—no embedded database, no hidden state.
• Improved DX and Simplicity: Cleaner architecture and lower operational complexity.

This alpha is not yet feature-complete with v1 (e.g., audit logs are still WIP), but it’s ready for early adopters and community feedback.

🐳 Get Started with Docker

docker run -d \
    -p 8080:8080 \
    -p 9000:9000 \
    -v $HOME/flipt:/var/opt/flipt \
    docker.flipt.io/flipt/flipt:v2-alpha

Check out the Configuration Overview for how to configure.

📚 Docs in Progress

There's still plenty of work ahead, but we’d love your feedback, questions, and ideas as we shape v2.

We’ve started updating the docs with key concepts, configuration details, and a Quickstart guide.

Note: the v2 docs aren't yet as complete as v1, but we’re shipping updates daily—check back often!

🛠️ Still TODO

We'll keep this list updated as we make progress. Feel free to suggest additional items.

• Realtime Client Updates
• Fix Analytics
• Audit Logs
• Git Change View
• Improved CLI Tooling
• Helm Chart for v2
• Production Hardening & Performance Tuning

💬 We Want Your Feedback

This is an alpha release. We're looking for early adopters to kick the tires and help shape the final version.

• Found a bug? Open an issue. Please tag with the v2 label!
• Have a question or idea? Reply here or start a new discussion.
• Want to contribute? PRs welcome!

[markphelps]

Little demo of branched environments in action! Ignore the error 😄

Next up we'll add the ability to create a new branch in the ui

[Jasz]

Could you describe the use case for branches? Looking at the demo you've posted I would assume it would be a good candidate for actual deployment environments (e.g. dev, uat, prod).

Will Flipt then ensure that flags are the same across all branches, specifically their keys, types and metadata? Is it the plan that creating a flag in the dev branch will create the same flag, with the same name, type and metadata in the uat and prod branches? And that deleting a flag in one branch will delete it across all branches? Currently, it's possible to have a flag with the same key be a boolean in one branch but a variant in the other.

In any case, I'm really excited for v2 🙂

[markphelps]

Hey @Jasz , sorry for. the delay

Branches are a way to create a copy of an environment. This allows you to test changes to your feature flags and configurations in a separate branch without affecting your users in production. You can think of branches just like environments, so they can be evaluated against/etc.

Branches are created from an existing environment and copy the base environment data and are completely independent of each other after creation.

They act just like Git branches where after the branch action they can diverge and so we wont automatically sync data between branches (although this could be a follow on feature potentially).

[markphelps]

I just updated the v2 docs to include info about branching: https://docs.flipt.io/v2/introduction#branching

[Jasz]

Thanks @markphelps, your explanation and the updated docs make it clear. I'll start a separate thread for syncing to further describe our use case.

[Jasz]

For us syncing between environments/branches would be really helpful. Our environments, dev, uat, prod, always exist, so we would want to create the branches/environments/spaces for them once and never remove them. Then, since every applications runs in every environment, we need to have each flag available in every environment, with the exact same configuration apart from the rules. This way we can, for example, have the feature enabled in dev, enabled in uat for specific users, and disabled in prod.

Currently I see two ways of doing this:

1. Have the user copy the flag across environments: this is additional work for each flag and there's room for mistakes (specifically, someone forgetting to copy a flag to one of the environments).
2. Use segments: but given the and/or structure of rules, it's harder to parse what exactly is enabled in each env and there's imho even more room for error, where a user could accidentally enable a feature in prod because they forgot a condition or used "any" instead of "all".

An environment could be seen as a special kind of condition that always exists in each flag. Maybe, for example, instead of having a single rollouts/rules form, the user would see multiple forms, one per environment.