--- title: "Storing private information in the file system" date: "2024-02-14T06:18:38+00:00" summary: "Securely store API keys and credentials on Acquia Cloud Platform using the nobackup directory—outside your codebase and protected by SSH." image: type: "page" url: "/acquia-cloud-platform/storing-private-information-file-system" id: "7db1fcbc-2dd5-4067-88dd-a2e9fe959441" --- Important The methods described on this page do not apply to Site Factory. Site Factory subscribers should instead use the procedures described in [Storing sensitive information outside of your codebase](/secrets). You can store sensitive keys, certificates, and other credentials securely on Cloud Platform by using a `nobackup` directory that is available in the file system. This is the best place to store environment-specific keys, as it is not in the [docroot](/definitions/docroot) or part of the code repository, but is protected by SSH access. To use the `nobackup` directory in [Cloud Platform](/acquia-cloud-platform#cloud-next-cloud-classic) environments, ensure that you update all commands and logic referencing the directories described here and test the behavior thoroughly, especially after code, database, and file copy operations. The platform excludes the `nobackup` directory at the platform level from all file migration operations, such as when you synchronize files between environments or create an On-Demand Environment (ODE) from production. The platform never copies its contents to non-production environments. Important The `nobackup` directory is not protected or covered by Cloud Platform [disaster recovery backups](/acquia-cloud-platform/architecture/security/availability#cloud-dr-multiregion). Note The platform excludes the `nobackup` directory at the platform level from all file migration operations. The platform does not copy the contents of `nobackup` to the target environment when you copy files between environments through the Acquia Cloud Platform User Interface (UI) or Application Programming Interface (API), or after an On-Demand Environment (ODE) is created from a production environment. You must provision the appropriate credential files separately on each environment. For a recommended approach, refer to the environment-specific file naming guidance. To place this directory: 1. Sign in to your infrastructure [using SSH](/acquia-cloud-platform/manage-apps/command-line/ssh/getting-started). 2. Create the following directory: /mnt/gfs/[sitename].[env]/nobackup 3. Create any required subdirectories in the `nobackup` directory for organizing your files, such as the following: * `/mnt/gfs/mysite.dev/nobackup/apikeys` * `/mnt/gfs/mysite.test/nobackup/apikeys` * `/mnt/gfs/mysite.prod/nobackup/apikeys` Because the system does not copy the `nobackup` directory between environments, you must create and populate the `nobackup` directory and its credential files **separately on each environment**. You can now use the `nobackup` directory and any of its subdirectories to store your private files. Retrieving sensitive keys ------------------------- If you are storing required credentials in the `nobackup` directory, you can use [Acquia-provided environmental variables](/acquia-cloud-platform/develop-apps/env-variable) to retrieve those credentials for your application. To enable this functionality: 1. In your `nobackup` directory or one of its subdirectories, create a PHP file. The PHP file can have any name, including the following example: /mnt/gfs/$AH_SITE_GROUP.$AH_SITE_ENVIRONMENT/nobackup/apikeys/mysite_apikeys.php 2. Edit the PHP file and add one or more environmental variables, similar to the following: putenv('MY_API_KEY_NAME=[key_value]'); 3. Save the PHP file. 4. Edit your application's `settings.php` file and add code similar to the following to dynamically build the path to the credentials file and include it: $env = $_ENV['AH_SITE_ENVIRONMENT']; $site_group = $_ENV['AH_SITE_GROUP']; $key_file = "/mnt/gfs/{$site_group}.{$env}/nobackup/apikeys/mysite_apikeys.php"; if (file_exists($key_file)) { require $key_file; } 5. Create settings variables for Drupal's use by adding the following lines to your `settings.php` file: **Drupal version** **Code** Drupal 7 $conf['mysite_apiname'] = getenv('SOME_API_KEY_NAME'); $conf['mysite_apikey'] = getenv('SOME_API_KEY'); [Current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version) $settings['mysite_apiname'] = getenv('SOME_API_KEY_NAME'); $settings['mysite_apikey'] = getenv('SOME_API_KEY'); 6. Save the `settings.php` file. Best practice for environment-specific credential file naming ------------------------------------------------------------- As a belt-and-braces approach, consider naming your credential files with an environment suffix. This ensures that each environment loads only its own credentials even in the unlikely event that files are synchronized between environments. Recommended naming conventions: * `apikeys.prod` * `apikeys.dev` * `searchstax.prod.json` * `searchstax.dev.json` The full path pattern using environment variables is: /mnt/gfs/$AH_SITE_GROUP.$AH_SITE_ENVIRONMENT/nobackup/apikeys.$AH_SITE_ENVIRONMENT Add the following code to your `settings.php` to dynamically load the correct credential file for the current environment: $env = $_ENV['AH_SITE_ENVIRONMENT']; $site_group = $_ENV['AH_SITE_GROUP']; $key_file = "/mnt/gfs/{$site_group}.{$env}/nobackup/apikeys.{$env}"; if (file_exists($key_file)) { require $key_file; } The `AH_SITE_ENVIRONMENT` environment variable contains the current environment name, such as prod, dev, or test. For On-Demand Environments (ODEs), this value displays as ode1 or ode2. Therefore, each ODE searches for its own uniquely named credential file. For documentation on the `AH_SITE_GROUP` and `AH_SITE_ENVIRONMENT` environment variables, refer to Using environment variables [Using environment variables](https://docs.acquia.com/acquia-cloud-platform/using-environment-variables).