Configuration files
Most modern web applications rely on some type of configuration mechanism in order to specify how the application should connect to external services such as a database, a file storage system or a redis-backed cache.
Examples are WordPress (wp-config.php
holds database credentials) and Laravel (.env
holds database credentials, mail
transport details, and more generally the server environment context).
Shared paths
Using our build automation feature, you may specify files or folders to be "shared" - these will remain in place when a new version is published (in the case of zero-downtime SSH remotes, a symlink is created; in the case of FTP remotes, the file or folder at the shared path simply remains untouched).
This does the trick, but it still requires you to manually connect to your server via SSH or FTP to actually place the configuration file. This is where configuration files come in.
Configuration files to the rescue
Our configuration files feature allows you to define configuration files such as .env
or wp-config.php
on a
per-server basis. As such, you'll find the configuration files control in the server settings modal.
You can drag-and-drop configuration files, or manually specify their contents using the built-in editor.
This allows you to add various text-based configuration files that will be added to every build (as a part of the corresponding bundled "release") after the build commands have finished executing (this also means that if you update any of your configuration files, you'll have to create a new build for the changes to take effect - use the "retry" button).
Configuration file paths you specify may include (sub-)directories. Any non-existent directories within the release will
automatically be created (think mkdir -p
).
Note that for larger and/or binary files such as user uploads, you should consider using shared paths (please find the dedicated "shared" section within our build automation guide).
Happy deploying!