Skip to content

Flagsmith on Flagsmith: Merge the API and frontend projects into one #7988

Description

@khvn26

Currently, the API and the frontend dashboard use two separate Flagsmith projects. Features that need gating in both layers currently require two flags in two projects, causing independently drifting state and segments.

Since API FoF is less state to move, we'd like to unify by merging "Flagsmith API" into "Flagsmith Website" (id=12).

The two sides evaluate with different identity models, which the merged project must accommodate:

  • Backend: targeting key org.<id>, traits organisation.id, organisation.name, subscription.plan.
  • Frontend: targeting key <user.id>, traits email, organisation.id, organisation.name, organisations.

Conventions for shared flags, to be documented: for gradual rollout, target organisation.id, not email or $.identity.key.

Tasks:

  • Frontend: send subscription.plan as a trait in flagsmithIdentify so plan-based segments work for shared flags
  • Create the 10 non-duplicated backend flags in project 12 with matching Staging/Production states, marked server-key-only, tagged api:
    • api_usage_alerting
    • api_limiting_stop_serving_flags
    • api_limiting_block_access_to_admin
    • api_usage_overage_charges
    • enable_feature_versioning_for_new_environments
    • sdk_metrics_labels
    • compress_dynamo_documents
    • code_references_ui_stats
    • get_current_api_usage_deprecated
    • segment_membership_inspection
  • Reconcile the 3 duplicated flags: verify FE/BE states agree per environment, extend their segments to cover both audiences:
    • feature_lifecycle
    • experimental_flags
    • experimentation_warehouse_connection
  • Rotate the FLAGSMITH_ON_FLAGSMITH_SERVER_KEY GitHub Actions secret to project 12's Production server key
  • Rerun updateflagsmithenvironment and commit the regenerated environment.json (will now include frontend feature states)
  • Update FLAGSMITH_ON_FLAGSMITH_SERVER_KEY in SaaS staging/production, and remap FLAGSMITH_ON_FLAGSMITH_FEATURE_EXPORT_ENVIRONMENT_ID/_TAG_ID which point at the old project
  • Verify on staging: evaluate each backend flag with a real org context against project 12 before touching production
  • Cut over production, archive the "Flagsmith API" project
  • Docs: update docs/docs/deployment-self-hosting/core-configuration/running-flagsmith-on-flagsmith.md and api/README.md for the single-project setup and the segment/trait conventions
  • Optional hygiene: project 12 carries 76 archived features and a pile of test segments worth purging.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions