> For the complete documentation index, see [llms.txt](https://developers.weglot.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.weglot.com/cms/wordpress/use-cases/how-to-store-your-api-key-outside-the-database.md).

# How to store your API key outside the database

{% hint style="info" %}
Available since Weglot 6.3.
{% endhint %}

By default the plugin keeps your Weglot API key in the WordPress database, in the `wp_options` table. On hosting where secrets are managed outside the codebase and outside the database — WordPress VIP environment variables, Docker secrets, a `.env` file — you can supply it as a PHP constant instead.

When the constant is defined and non-empty, it becomes the only source for the key: the plugin reads it instead of the database, and stops writing it to the database entirely.

### The constant

Only one constant is needed: `WEGLOT_API_KEY_PRIVATE`, set to the API key shown in your Weglot dashboard — the same key you would otherwise paste into the plugin's API key field.

| Constant                 | Value                           | Replaces the option                |
| ------------------------ | ------------------------------- | ---------------------------------- |
| `WEGLOT_API_KEY_PRIVATE` | Your API key from the dashboard | `weglot-translate-api_key_private` |

The constant must be set before WordPress loads plugins, so it belongs in `wp-config.php` — above the `require_once ABSPATH . 'wp-settings.php';` line — or in your host's equivalent configuration file.

### Reading the key from an environment variable

The plugin only checks that the constant exists and is non-empty. Where the value comes from is up to you, so any secret store that PHP can read works.

#### WordPress VIP

Store the key as an environment variable with VIP-CLI. The command prompts for the value rather than taking it as an argument, which keeps it out of your shell history:

```bash
vip @your-app.production config envvar set WEGLOT_API_KEY_PRIVATE
```

Then read it in `/vip-config/vip-config.php`, which is loaded before WordPress core and before any plugin:

```php
// Weglot reads its API key from this constant instead of the database.
if ( function_exists( 'vip_get_env_var' ) ) {
	define( 'WEGLOT_API_KEY_PRIVATE', vip_get_env_var( 'WEGLOT_API_KEY_PRIVATE', '' ) );
}
```

Each VIP environment carries its own variables, so set it on every environment you deploy to. An environment where it is missing falls back to the database.

#### Any other host

```php
define( 'WEGLOT_API_KEY_PRIVATE', getenv( 'WEGLOT_API_KEY_PRIVATE' ) ?: '' );
```

Keep the empty-string fallback. If the variable is missing the constant stays empty, and the plugin reads the database as before instead of breaking.

### What changes in the admin

The API key field in the Weglot settings is filled in from the constant and becomes read-only, with a note saying where the value comes from. Saving the settings still validates the key against the Weglot API — it simply does not store it.

Resetting the Weglot settings no longer disconnects the site either: that action clears the plugin's options, and the key is no longer among them.

To rotate the key, change it in your secret store and deploy. Nothing needs to change in WordPress.

### Migrating a site that is already configured

On a site that ran Weglot before, the key is already in the database and defining the constant does not remove it. Once you have confirmed the front end still translates, delete it explicitly:

```bash
wp option delete weglot-translate-api_key_private
```

Nothing rewrites it afterwards.

You can check the result at any time with:

```bash
wp option get weglot-translate-api_key_private
```

It should report that the option could not be found.

### Limitations

The plugin caches its configuration in a WordPress transient, and that cache contains the key. With a persistent object cache — which WordPress VIP provides — transients are held in memory and never reach the database. Without one, WordPress stores transients in the `wp_options` table, so a copy of the key lands there despite the constant.

The key also remains visible in the admin: the settings field is read-only, not hidden. Anyone who can reach the Weglot settings screen can read it.