Clarify Quick Start scope and consider feature flags via .env for enterprise evaluation

[dgatti0213]

Description

The Quick Start Docker Compose deployment is often the entry point for teams evaluating FlowFuse, including for enterprise use.

While it works well for getting started quickly, it’s not always clear where the boundary is between:
• a quick demo
• an evaluation environment
• a production / enterprise deployment

Because of this, users often begin modifying the stack to add things like TLS, email, registries, or authentication. In practice this frequently leads to configuration drift or broken deployments, especially when people rely on AI-generated compose changes.

Suggested improvement

Instead of expanding the Quick Start stack, consider supporting optional features via environment flags along with a documented .env.example.

.env.example

DOMAIN=example.com

ENABLE_EMAIL=false
ENABLE_TLS=false
ENABLE_PRIVATE_NPM=false
ENABLE_TEAM_BROKER=true
ENABLE_FILE_STORAGE=true

POC option

POC_DNS=true

This would keep Quick Start simple while giving enterprise evaluators a clear and supported path to enable additional features without modifying the compose file.

[ppawlowski]

1. This is not possible - Docker Compose configuration file is a simple yaml where conditional logic cannot be applied
2. As explained in the docs, the quick start Docker Compose YAML file (docker-compose-quick-start.yml) is used for evaluation purposes only.
3. As mentioned in the docs, full deployment is available using the docker-compose.yml file. Full guide available here.

[dgatti0213]

So the ask is not really “add conditional YAML to Quick Start,” but rather make it clearer which features are intentionally disabled in Quick Start and how enterprise evaluators are expected to enable them.

Right now, several capabilities that are fairly typical in enterprise deployments are either missing or only partially represented in the evaluation path, for example:
• private npm registry for managing Node-RED dependencies
• TLS / certificate management
• email / SMTP configuration
• identity / auth integrations
• broker exposure patterns for multi-site deployments
• storage configuration beyond the default local setup

When teams evaluate FlowFuse for enterprise use, they typically start with Quick Start and then begin adding these capabilities themselves. In practice this often leads to configuration drift or broken deployments, especially when people rely on partial documentation or AI-generated Compose changes.

The core issue I’m trying to highlight is not Docker Compose syntax, but the lack of a clear, supported feature-enablement path between Quick Start and a fuller deployment suitable for enterprise evaluation.

[hardillb]

We should probably just remove the Quick Start option, the normal deployment will come up with just a domain adding to the .env file.

The fact it starts a bunch of extra unused containers is worth it to save on the problems of retro actively trying to enable them.

[dgatti0213]

I 100% agree! This way, when someone comes to me with some random YAML file, I can compare it to one golden source of truth. I currently get these weird middle grounds...

[MichaelBDavis]

@Yndira-E Please update the the quick start guide, https://flowfuse.com/docs/quick-start/, by removing the existing code blocks and replacing with how to set up an environment file for the full docker compose.

Change Step 2: docker-compose-quick-start.yml to docker-compose.yml
Add a section for setting up an environment file

This affected these two customers last week:
https://app-eu1.hubspot.com/contacts/26586079/record/0-3/252826054853
https://app-eu1.hubspot.com/contacts/26586079/record/0-3/307978792128

[ppawlowski]

This is the engineering part of the documentation. I will take care of it @MichaelBDavis .