Environment and WordPress config

Fluxo provides editors for application configuration that must remain on the server. Editors support standard selection, cut/paste, undo and redo, and Ctrl/Cmd+S to save. In environment and deployment-script editors, Ctrl/Cmd+/ toggles line comments. Copy or cut without a selection acts on the current line. Tab indents; press Escape then Tab to move focus out of the editor.

Environment file

Open Site > Settings > Environment to read and update the site's root .env file. Saving replaces the file contents used by the application.

The editor refreshes when you return to this page or refocus the browser, so changes made by features such as Nightwatch appear without a hard refresh. Unsaved edits are preserved.

When Fluxo provisions database configuration, it groups the host, port, database name, username, and password directly below DB_CONNECTION, replacing existing defaults instead of appending scattered values at the bottom.

Laravel provisioning uses .env.example when available and preserves a non-empty APP_NAME. Fluxo is used only when the name is missing or blank. Production environment and debug defaults are still applied. Existing sites are not renamed automatically.

In managed zero-downtime deployments, Fluxo links this persistent file into each new release. In standard deployments, it remains an untracked file in the site root and is deliberately preserved when tracked Git files are reset.

Python systemd services also load the persistent .env directly. A Python site with a nested application directory receives a symlink from that directory back to the root file, while process-level values are available without requiring an application-specific dotenv package.

Deployment exposure

By default, the environment exists as a file but its values are not exported into the deployment shell. Enable environment exposure only when build commands must read values directly from process environment.

Fluxo filters environment syntax and reserves names beginning with FLUXO_. Those variables describe the deployment lifecycle and cannot be replaced by application content.

Build-time secrets

Frontend frameworks can embed environment values into browser assets. Only expose variables intended for the build, and follow the framework's rules for public prefixes.

Apply changes

For Laravel sites, Rebuild configuration cache after saving runs php artisan config:cache using the site's PHP version after the environment save succeeds. Click Save environment to persist this preference for that site; it is restored on refresh and starts off for existing sites. It is a save preference, not an indicator of Laravel's current cache state. Turning it off does not clear an existing cache. Automatic rebuilding does not appear in Recent commands. A failed rebuild leaves the environment saved and displays a warning; correct the application's configuration or PHP dependencies and save again to retry. Existing command-history entries are not removed.

• PHP applications may read .env per request or cache configuration. Clear or rebuild framework caches after changing values.
• Long-running Node.js, Python, Queue Worker, Horizon, Octane, and custom daemon processes normally need a restart. Fluxo handles deploy-time restarts for its managed application and feature processes.
• Build-time variables require a new deployment.

WordPress configuration

WordPress does not use .env by default. Its dedicated WordPress settings page edits the active wp-config.php in the configured web directory.

Fluxo-generated WordPress configuration includes database settings, unique salts, the table prefix, forwarded-HTTPS handling, debugging defaults, ABSPATH, and the required wp-settings.php include.

Use the WordPress editor for constants such as WP_DEBUG, cache configuration, multisite settings, and application-specific values. Avoid duplicating WordPress database credentials into an unused .env file.

Secret handling

Do not paste environment or WordPress configuration into public issue reports. Remove credentials from deployment logs and command output before sharing them. Maintain a secure independent copy of values needed for disaster recovery.