Free Trial

Fortress Security Part 2: Quick Start Configuration Guide

  • Updated
24 min read

Table of Contents

Introduction

Snicco, the team behind Fortress, has invested a significant amount of time in creating a baseline configuration that will work for 95% of use cases. You can simply install the plugin, set up 2FA, and then you’re all set.

This article will walk you through how configuring the Fortress security plugin works, and the main settings that we believe you may wish to configure for those remaining 5% of websites.

Fortress Developer Documentation

For all other settings that are not covered, the official Developer Documentation for Fortress can be found here:
Official Fortress Developer Documentation

Customizing Fortress settings may seem complicated at first glance, but configuring the different modules is relatively straightforward, and multiple sites can share the same configuration. Once you understand the basic setup, you’ll have a tremendous amount of flexibility for configuring Fortress across all of your websites.

MyISAM Warning

Fortress will not work with the MyISAM storage engine (for MySQL databases). This storage engine is slow and outdated, and often a primary cause for unusual slow behavior in a website. To use Fortress, you will need to update any MyISAM database tables to use the InnoDB storage engine.

You can learn how to check for MyISAM tables and how to convert MyISAM to InnoDB in this article: 
Converting MyISAM to InnoDB

Part 1: GridPane Fortress Configuration

GridPane’s Auto-Configuration

For a smooth integration into GridPane, our Fortress install auto-configures necessary firewall and caching exclusions and sets up a consistent config directory that works with our cloning and staging systems. This includes:

  1. 7G WAF exclusions
  2. Nginx page caching exclusions
  3. A new /var/www/site.url/fortress directory is created on installation, where Fortress configurations are created and stored
  4. Secure handling of Fortress encryption secrets
  5. All necessary cron jobs needed for Fortress WP-CLI
  6. Logrotate set up

Our systems will also work with the following configuration files:

  1. A site configuration file named config.json
  2. A server configuration file named server-config.json

Fortress Installation

Our GP-CLI installation command installs Fortress as a must-use plugin. This is a necessity to ensure that malicious code can’t simply deactivate it – a major flaw in installing any security plugin as a regular plugin.

Notes on Redis Object Caching

Nginx: Redis Object Caching Plugin

If you haven’t yet made the switch from the older GridPane Redis Object Caching plugin to the official plugin, please make sure you switch over before activating Fortress. You can do this by simply toggling Redis Object Caching OFF and then back ON again.

OpenLiteSpeed (OLS) and Redis Object Caching

The LiteSpeed caching plugin’s Redis Object caching feature has been updated and is now fully compatible with Fortress.

Install and Uninstall Fortress 

To get started with Fortress and customize Fortress settings, you may need to connect to your server via SSH. If this is your first time connecting to a server, please see the following guides to get started:

Step 1. Generate your SSH Key

Step 2. Add your SSH Key to GridPane (also see Add default SSH Keys)

Step 3. Connect to your server by SSH as Root user (we like and use Termius)

Install/Uninstall via the UI

Fortress is now available to install and uninstall directly within your GridPane account if you’re on our Developer Plus plan. This will be available for all plans in the near future once our billing component is completed. 

To get started, head over to the Sites page inside your GridPane account and click on the name of the site you want to configure Fortress on to open up the website customizer.

Click through to the Security tab, and here you will see the option to toggle Fortress ON and OFF:

Install Fortress with GP-CLI

You can install Fortress on your websites with the following command (replace site.url with your website URL):

gpfort site.url -install

For example:

gpfort mywebsite.com -install

This will take care of everything necessary to install Fortress to your website’s must-use directory and run smoothly on GridPane.

Uninstall Fortress with GP-CLI

To remove Fortress from a website, you can run the following command – this handle everything necessary (replace site.url with your website URL):

gpfort site.url -remove

Setting Two-Factor Authentication for Your Own Account

Once Fortress has been installed, the only thing necessary to do is set up two-factor authentication for your account and any other administrators and/or editors.

Setting up 2FA

After a user whose role mandates TOTP-2FA logs in (administrator and editor by default), they will be intercepted and redirected to the TOTP setup page:

You can skip it initially, but only once.

After clicking the “Setup two-factor authentication” button, Fortress will generate and persist a new set of TOTP credentials for the user.

Scan the displayed QR code or copy the revealed secret.

To prevent account lockout through some mismatch between Fortress and the authenticator app, Fortress will not activate TOTP-2FA until the user provides a valid OTP.

Once setup, the next time you log in, you will be required to enter your 2FA authentication code or recovery code:

You can read the full TOTP developer documentation here.

Part 2: Customizing the Fortress Configuration

Configuring Fortress

With the exception of setting up 2FA, which is done inside of your WordPress admin, there are two ways that Fortress can be configured:

  1. WP-CLI via GPFort CLI
  2. The server and site configuration JSON files

WP-CLI via GPFort CLI

Support for WP-CLI is an afterthought in most WordPress plugins. Fortress is built with a CLI-first approach to allow maximum automation in your workflow. Full developer documentation can be found here.

At GridPane, we have our custom gpfort CLI, which, similar to GP WP-CLI, allows you to run Fortress WP-CLI commands as the root user (more details in this section below).

Fortress Configuration JSON Files

You can customize Fortress via the server and site configuration JSON files. All of the default settings for Fortress are stored in its baseline configuration, and these can be customized at the server level or site level by placing your settings inside the relevant configuration files. When customizations are added here, Fortress will read the file contents and overwrite the baseline configuration on a per-key basis.

This is all easier than it sounds and will be covered step by step below.

The complete configuration reference can be found here.

GPFort CLI and Fortress WP-CLI

As a part of our integration with Fortress we’ve created our gpfort CLI, and this is now our recommended way to Fortress’s WP-CLI.

When running Fortress WP-CLI via gpfort:

  1. The CLI will provide clean stdout (standard output)
  2. The stdout and stderr (standard error) both go to the stderr and to the info/err output and logging
  3. Commands can be ran for ALL sites on a server as well as individual sites

GPFort Syntax

gpfort follows a similar syntax to our GP-CLI but requires an extra flag that needs passing after the site.url. Here’s the syntax for individual websites:

gpfort {site.url} -cli {wp-cli-command} {args}

The following is the syntax for all sites on a server:

gpfort all-sites -cli {wp-cli-command} {args}

For example:

gpfort examplesite.com -cli shared cache:config
gpfort all-sites -cli shared cache:config

Baseline Configuration

Below is the baseline configuration for all Fortress modules. You can follow the formatting in this configuration edit your server and site configuration JSON files. As mentioned in the introduction, this configuration has been designed to work for 95% of all use cases.

To view the most up-to-date Fortress baseline configuration, please check the official developer documentation linked below.

IMPORTANT: Please note that the file path for the default-theme.css file in the default config is NOT correct for the GridPane integration. The following is the correct file path – please make sure that this line is correct in your configuration file:

 "theme_css_file": "/wp-content/mu-plugins/gridpane-snicco-fortress/snicco-fortress/default-theme.css",

Fortress Baseline Configuration

The Fortress Server Configuration File

If you would like to customize the default Fortress configuration for ALL websites on a server, you can do this using the server-config.json file.

You will then be able to overwrite these custom settings on a per-site basis by using the site-specific configuration files. 

The server-level configuration file can be added here (details in the next section):

/etc/fortress/server-config.json

Important

  1. You will need to ensure that the formatting follows the above baseline configuration, including the opening and closing brackets.
  2. We recommend setting your preferred server-level customizations as early as possible to prevent the need to clear the Fortress cache on a per site basis

Editing the Server Configuration File

First, you need to create the following directory to store your config:

mkdir /etc/fortress

You can now both create and edit the server-level configuration file with the following command:

nano /etc/fortress/server-config.json

Once you’ve added your customizations, save the file with CTRL+O, followed by Enter. Now you can exit nano with CTRL+X.

Fortress Syntax Check

To ensure that your configuration is valid, Fortress has its own syntax check that you can run with this WP-CLI command. This check can be ran via any site that has Fortress already installed (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success

This is similar to the nginx -t syntax check and will automatically clear the Fortress cache if successful. If unsuccessful, Fortress will provide you with detailed troubleshooting information.

Once you’ve confirmed the syntax is valid, you will need to run the above command for each site on the server for the changes to take effect.

The Fortress Site Configuration File

GridPanes Fortress integration works with a configuration JSON file named config.json in this location:

/var/www/site.url/fortress/config.json

You can customize Fortress settings on a per-site basis using this config, and, as mentioned above, the custom settings you add here will overwrite the baseline configuration AND server configuration file.

During cloning and staging pushes, this file and your customizations will be copied across.

Editing the Site Configuration File

You can create and edit the site specific config.json file with the following command (replace site.url with your website URL):

nano /var/www/site.url/fortress/config.json

For example:

nano /var/www/mywebsite.com/fortress/config.json

Once you’ve added your customizations, save the file with CTRL+O, followed by Enter. Now you can exit nano with CTRL+X.

Fortress Syntax Check

To ensure that your configuration is valid, Fortress has its own syntax check that you can run with this WP-CLI command (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success

This will automatically clear the Fortress cache if successful. If unsuccessful, Fortress will provide you with detailed troubleshooting information.

Important

Before you set any config changes live on a production website (or all production websites via the server config), please ensure you have thoroughly tested. This can be done a staging site or a clone.

View Fortress Configuration Sources with WP-CLI

Fortress offers CLI commands that can be used to view all your configuration sources as JSON.

View Configuration Sources

This command will allow you to view the current configuration sources (replace site.url with your website URL):

gpfort site.url -cli shared config:sources

Full developer documentation here.

View Cached Configuration

The following CLI command can be used to display the currently cached configuration as JSON (replace site.url with your website URL):

gpfort site.url -cli shared cache:config

Full developer documentation here.

Part 3: Configuring Fortress Modules

Two-Factor Authentication

By default, Fortress treats Administrator and Editor user roles as privileged users. Depending on your use case, you may wish to change these defaults and potentially add in other roles, such as shop_manager on WooCommerce stores. The following sections will look at how to make these changes and also how to enforce the requirement to successfully pass 2FA verification in order to be able to log in. 

This is done via the JSON configuration file. At the time of writing, the available 2FA “auth” settings are as follows:

"auth": {
  "totp_secrets_table_name": "snicco_fortress_totp_secrets",
  "totp_sha_algo": "sha1",
  "skip_2fa_setup_duration_seconds": 1800,
  "require_2fa_for_roles_before_login": [],
  "max_totp_attempts_before_lockout": 5,
  "require_2fa_for_roles": [
    "administrator",
    "editor"
  ]
}

The highlighted text are the two settings we’ll look at editing. Please see the sections above for how to edit the server and site configuration files.

Adjusting Privileged User Roles

Here’s an example of how to make the role “shop_manager” a privileged user inside of Fortress.

This can be done in either the site configuration file or the server configuration file but would be better enabled only when needed, and thus in the site configuration.

You can add the following setting to your site configuration file:

"auth": { 
  "require_2fa_for_roles": [ 
    "administrator", 
    "editor",
    "shop_manager"
  ] 
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Forcing 2FA for Privileged Users

Once all of your website’s privileged users have 2FA configured, you can now enforce that each user must have TOTP-2FA configured BEFORE they are allowed to log in.

This can be enforced by adding your websites privileged_user_roles to the require_2fa_for_roles_before_login setting inside the configuration file.

Protection

Forcing 2FA will protect your website against the following attack vectors:

  • An attack with WRITE access to the database can’t delete TOTP credentials to bypass 2FA.
  • An attacker with WRITE access to the database can’t insert new admin users since they can’t create TOTP credentials without the secret key stored in the filesystem.
  • An attacker with a stolen auth cookie can not create sleeper admin users.
  • A non-targeted malware can not insert new admin users using <codewp_insert_user.

Once configured, any privileged user without TOTP-2FA configured will see the following message when they attempt to log in:

JSON Settings

Only do this AFTER all of your website’s privileged users have 2FA configured for their accounts.

It’s best to set this inside the website configuration file instead of the server configuration, as it will make adding Fortress to new sites easier.

You can adjust the following and your settings to your site configuration file:

"auth": { 
  "require_2fa_for_roles_before_login": [ 
    "administrator", 
    "editor" 
  ] 
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Password Configuration

If you need to:

  1. Upgrade existing password hashing
  2. Reset passwords for privileged users
  3. Re-enable application passwords

You can find the necessary details below. For all other settings, please refer to the official developer documentation here.

Information

Fortress's password module will hash new passwords using Fortress's secure hashing. If you deactivate Fortress, any passwords that have been secured with upgraded cryptography will need to be reset.

Upgrade Existing Passwords to Secure Password Hashing

The following WP-CLI command can be used to upgrade all password hashes of existing users to Fortress’s secure password hashing:

wp snicco/fortress password upgrade-legacy-hashes

Here’s the GPFort version:

gpfort site.url -cli password upgrade-legacy-hashes

You will be asked to confirm. Type yes or no and then press Enter.

Additional Notes
  • You can read the official developer documentation here.
  • This command might take a significant amount of time, depending on the size of your database. This is because each password hash needs to be rehashed using libsodium, which might take up to one second per hash, depending on your configured default_hash_strength.
  • This command can be safely run on production sites with many users since it is executed in batches.

Password resets for privileged users

Password resets are disabled for privileged users by default. This applies to users of the roles:

  • administrator
  • editor

The following WP-CLI command can be used to set a new, randomly generated, and secure password for a user.

The command will output the plaintext password so you can copy it to a password manager.

wp snicco/fortress password reset {user_name}

Here’s the GPFort version:

gpfort site.url -cli password reset {user_name}

For example:

gpfort site.url -cli password reset john-smith
Additional Notes

Re-enable application passwords

You can re-enable application passwords on any sites that require them by setting the disable_application_passwords option to false.

This can be done in either the site configuration file or the server configuration file but would be better enabled only when needed, and thus in the site configuration.

You can add the following setting to your site configuration file:

{
  "password": {
     "disable_application_passwords": false
   }
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Disallow Legacy Password Hashes

You can add additional security to your website by setting the allow_legacy_hashes option to false.

This will prevent one of the most common WordPress hacks where an attacker will add a new user to your website using a password with the default and outdated md5 hashing and then logging in with their newly created credentials.

Fortress allows you to completely prevent this from happening by changing this setting to false.

Caution!

Only set allow_legacy_hashes to false if one or more of the following is true for your website:

  • You are using Fortress on a brand-new site.
  • You have upgraded all legacy hashes (see above).
  • You have already force reset all user passwords.
  • You’re using it as an alternative way to force every user to choose a new password.

If one or more of the above isn’t true, you might prevent yourself and other users from being able to log in.

JSON Settings

This can be done in either the site configuration file or the server configuration file but would be better enabled only when needed, and thus in the site configuration.

You can add the following setting to your site configuration file:

{
  "password": {
     "allow_legacy_hashes": false
   }
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Secure Sessions Configuration

If you need to increase sudo mode session timeouts or idle session timeouts, you can find the necessary details below. For all other settings, please refer to the official developer documentation here.

Increasing/Decreasing Sudo Mode Timeout Periods

  • Key: sudo_mode_timeout
  • Type: positive-integer
  • Default: 600 seconds (10 minutes)

The sudo_mode_timeout option is the interval in seconds during which Fortress will consider a session to be in sudo mode after logging in.

You can add the following setting to your server configuration file for ALL sites on a server, or site configuration file for an individual site:

{
  "session": {
     "sudo_mode_timeout": XXX
   }
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Increasing/Decreasing Idle Timeout Periods

  • Key: idle_timeout
  • Type: positive-integer
  • Default: 1800 seconds (30 minutes)

The idle_timeout option is the interval in seconds after which a user without activity is logged out.

You can add the following setting to your server configuration file for ALL sites on a server, or site configuration file for an individual site:

{
  "session": {
     "idle_timeout": XXX
   }
}
Fortress Syntax Check

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Vaults & Pillars

By default, no Vaults & Pillars are active when Fortress is installed. While some settings apply to the vast majority of WordPress websites, not all of them will, and so these need to be determined on a per-site basis.

Below we’ll look at recommendations for settings that you may wish to implement on the vast majority of your websites, and there are links to Snicco’s walkthroughs on securing Stripe API Keys.

To learn more about Vaults & Pillars, you can learn more on the Snicco blog and official Developer Documentation here:

  1. Snicco: Blog > Vaults & Pillars
  2. Vaults & Pillars Developer Documentation

Information

To learn how to implement Vaults & Pillars it is best to view Snicco's official developer documentation in full via the link above. Each section of this documentation is important and should be fully read and understood to ensure you understand both how this functionality works and the implications.

Important

ALWAYS ADD/TEST NEW VAULTS IN A STAGING ENVIRONMENT BEFORE IMPLEMENTING ON A PRODUCTION WEBSITE. NO EXCEPTIONS.

Running WP-CLI Commands for Vaults & Pillars

As the gp wp <domain> <command> wrapper is not intended for programmatic use, you may need to run regular WP-CLI for Fortress Vaults & Pillars when querying the database. The following 3 steps detail how to run regular WP-CLI via your website’s system user.

Step 1. Navigate to Your Website’s Directory

To make sure we’re in the right place, we’ll start by navigating to the websites /htdocs directory with the following (replace site.url with your website URL):

cd /var/www/site.url/htdocs
Step 2. Choose How You Want to Run Your Commands

You have 2 options for running your commands via the website system user. The first is to simply specify it as a part of the command, and may be the easier option if you’re just running a single command. Here’s an example:

sudo -u mysystemuser wp {command} {arg}

The second option is to swap over to your websites system user (make sure you use your website’s actual system user):

su mywebsiteuser

And from here, you can run your commands as normal. On the command line, it will then look a little different from running as the root user:

root@myserver:/var/www/mywebsite.com/htdocs# su testTEST38
testTEST38@myserver:/var/www/mywebsite.com/htdocs$
Step 3. Run your WP-CLI commands

We’re now in the right directory and you’re ready to go ahead and run your WP-CLI commands.

Once complete, if you swapped into your sites system user, you can return to the root user by typing:

exit

Vaults & Pillars Video Walkthrough

The following technical rundown is a recording by Paul Stoute, a long-time GridPane client, and Calvin Alkan of Snicco.

Strict Mode in Vaults and Pillars

Strict Mode provides a higher level of security by enforcing stricter checks and validations on the options. When enabled, it introduces the following changes and ensures that the system doesn’t fall back to insecure defaults:

  • An exception is thrown if an option with any Vaults or Pillars is missing in the database.
  • An exception is thrown if a required environment variable (ENV var) is not found in the runtime.
  • An exception is thrown if the database value for a Vault is not encrypted yet, as this might indicate that an attacker tried to update it.
  • All Vaults become immutable, just like Pillars, meaning their values can’t be changed after they’re initially set.
  • Updates of options with Partial Vaults/Pillars to a non-array value are disallowed and will return false.
  • An exception is thrown if any sub-key of a Partial Vault/Pillar, or its parent, is missing in the database during a fetch operation.
  • An exception is thrown if an option with Partial Vaults/Pillars is not an array in the database.
  • Options can no longer be deleted using delete_option() function.
  • Options associated with at least one Vault/Pillar can no longer be added using the add_option() function.

Strict Mode best suits environments where security is paramount, but it should be enabled with caution by first thoroughly testing in a staging environment.

Checking if Strict Mode is activated

By default, Strict Mode is NOT active, so it will not be active unless you have explicitly activated it in the past.

You can verify if strict mode is enabled with the following WP-CLI command:

$ wp snicco/fortress shared cache:config --key=fortress.vaults_and_pillars.strict_option_vaults_and_pillars

false

The returned value indicates whether the strict mode is active (true) or inactive (false).

Enabling Strict Mode

You can enable Strict Mode in your Fortress configuration JSON file by setting the strict_option_vaults_and_pillars attribute to true:

{
  "vault_and_pillars": {
    "strict_option_vaults_and_pillars": true
  }
}

The default value is false. However, enabling Strict Mode is highly recommended in production environments.

Disabling Strict Mode

Deactivating has no adverse effects.
You can turn off the Strict Mode by updating the strict_option_vaults_and_pillars option to false in your configuration:

{
  "vault_and_pillars": {
    "strict_option_vaults_and_pillars": false
  }
}
Reload Your Configuration

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Additional Notes

Recommended Pillar Defaults

Below is an example of our recommended default Pillars for WordPress Core settings/options.

Please note that these are not added by default when Fortress is activated and must be activated manually.

				
					{
  "vaults_and_pillars": {
    "option_pillars": {
      "users_can_register": {
        "value": "0"
      },
      "blog_public": {
        "value": "1"
      },
      "permalink_structure": {
        "value": "/%postname%"
      },
      "tag_base": {
        "value": ""
      },
      "category_base": {
        "value": ""
      },
      "default_role": {
        "value": "subscriber"
      }
    }
  }
}

The above configuration can help you make the following settings more secure and protect them from malicious abuse and/or user error:

  • users_can_register: This setting can prevent user registration on websites where it is not needed, and disallow it from being turned on in your production environment.
  • blog_public: Prevent anyone turning off search engine visibility in your production environment.
  • permalink_structure: Keep the URL structure consistent across your website by setting a fixed permalink structure. /%postname in the above configuration is an example. Set this according to your websites current settings to lock this setting in place. Changing permalinks on a production site can have many unwanted consequences if one does not know the entire site architecture.
  • tag_base: Same reason as for permalink_structure.
  • category_base: Same reason as for permalink_structure.
  • default_role: Guard your site against [common] potential security breaches by preventing the default user role from being updated to “administrator” or any other high-privilege role, which could allow for a full site takeover in combination with the users_can_register setting. You can also change “subscriber” to another low-privileged role using custom roles.

Below details how to create this configuration.

Step 1. Strict Mode Check

Please check and, if necessary, disable Strict Mode. Details here.

Step 2. Create Your Configuration

Add the above recommended settings to your configuration, and ensure that your permalink, tag, and category bases are all correct.

Step 3. Check and Reload Your Configuration

To ensure that your configuration is valid and set your changes live,  run this WP-CLI command to check the Fortress syntax and clear the cache (replace site.url with your website URL):

gpfort site.url -cli shared config:test --reload-on-success
Step 4.  Encrypt All Vaults & Replace Pillars With Placeholders
gpfort site.url -cli vnp options:seal-all
Step 5. Optional: Re-enable Strict Mode

If applicable, now you can re-enable Strict Mode.

Additional Notes

Securing Stripe API Keys

Calvin Alkan has written easy-to-follow step-by-step guides for securing Stripe API keys in WooCommerce, Easy Digital Downloads (EDD), and Gravity Forms. 

With the overwhelming majority of plugins storing Stripe API keys in plaintext in the database and the seemingly never-ending stream of SQLi vulnerabilities in WordPress Core, themes, and plugins that can expose these credentials, it is vital to take steps to encrypt them. 

  1. Secure Stripe API Keys in WooCommerce
  2. Secure Stripe API Keys in Easy Digital Downloads (EDD)
  3. Secure Stripe API Keys in Gravity Forms

Troubleshooting

Troubleshooting: Fortress Part 3

Our troubleshooting info has been moved to its own article. Please see part 3 in our Fortress series for further information:

Fortress Security Part 3: Troubleshooting

Bonus!

Fortress schema.json

For those of you that use PhpStorm or Visual Studio Code for development, Fortress offers a complete JSON schema for its config that you can use in your editor for auto-complete and validation.

You can download/reference it here.