Feature Request: Native Support for Feature Flags

Feature Requests
1

Written by Ai to hopefully make more sense than if I wrote it - Alfred :grinning_face:

First off, I really appreciate how far Softr has come — especially the role-based visibility options and the way ACLs already make it possible to control who sees what.

That said, I’d love to see Softr add native support for feature flags.

Why Feature Flags Matter

Feature flags are one of the core practices that define elite software teams, according to the DORA research (see dora.dev). Instead of creating multiple app versions or “branches” to test features safely, high-performing teams keep one live production system and toggle new functionality on or off for specific user groups.

Platforms like LaunchDarkly are built entirely around this concept because it helps teams:

  • Ship faster — all development happens in one place (no “next version” copies).

  • Reduce risk — if something breaks, you can disable the feature instantly.

  • Improve QA — test in the real environment with only a few users exposed.

  • Simplify collaboration — no more merging or syncing multiple versions.

How This Could Work in Softr

Softr already has a great foundation for this through roles and visibility settings. Feature flags would extend that same concept but make it more flexible and less tied to ACLs. For example:

  • Allow toggles at the page, block, or data level (like hiding/showing new UI blocks).

  • Make flags runtime-controllable — through a simple UI or an API.

  • Support temporary rollout states (e.g., beta, staged, off, on).

  • Optionally, integrate with the Softr API so we can flip flags dynamically from n8n or another automation tool.

This would give Softr builders a clean, safe way to test features in production — without resorting to cloning apps or maintaining multiple “next versions.”

Reference Links