Applications
Applications define where Fluxyn can run, which runtime features are enabled, and how branches become production releases.
An application is the top-level boundary for a website or web experience in Fluxyn.
It answers four practical questions:
- which domains are allowed to use this runtime
- which built-in listeners should be enabled
- which flows belong to this runtime instance
- which application release is live in production
Application Architecture
An application holds the settings that should be true across all of its flows:
- Allowed origins for security and environment control
- Runtime listener settings such as click tracking, history changes, scroll tracking, and error capture
- Event queue settings for holding browser events until a Release Queue flow runs
- Application branches so changes can be grouped before a production release
Allowed Origins (Security)
Allowed origins tell Fluxyn where this application is allowed to run.
This matters for both safety and clarity. A runtime intended for www.example.com should not quietly execute on an unrelated site.
Use this setting to:
- allow production domains explicitly
- allow QA domains without mixing them into production
- allow local development hosts when you need to test locally
If the field is left empty, the runtime is more permissive. That can be convenient during early setup, but it is not a good long-term production default.
Trigger Configurations
Application trigger settings tell the client runtime which built-in browser listeners it should attach when the page loads.
Typical examples include:
- click tracking
- history change tracking for SPAs
- element visibility observers
- scroll depth tracking
- JavaScript error capture
- timer-based triggers
These settings do not send data anywhere by themselves. They simply make the browser signals available so your flow triggers can react to them.
That split is intentional:
- the application decides which listeners may exist
- the flow decides what should happen when they fire
The Deployment Path
Applications also give you a clean promotion path.
- Branch is where you edit flows and configurations.
- Live Preview is where you validate the saved branch before release.
- Production is what real users receive.
For anything beyond a trivial change, use Live Preview before release. It is the fastest way to catch selector mistakes, bad expressions, consent issues, and vendor payload problems before they reach live traffic.