Automatic Updates in WordPress: A Production-Safe Configuration Guide

Automatic updates in WordPress are a trade-off. Enabled aggressively, they patch vulnerabilities within hours of disclosure but can push an untested change to production. Disabled entirely, they leave a site exposed during the window between a disclosure and your next manual update cycle. On a business-critical site, the right answer is neither extreme: it is a deliberate policy about what updates automatically and what goes through staging first.

This guide covers how automatic updates actually work, every constant and filter that controls them, and the update policy I recommend for production WordPress environments.

How WordPress handles automatic updates

Background automatic updates were introduced in WordPress 3.7 for minor core releases, and WordPress 5.5 added per-plugin and per-theme auto-update toggles in the admin dashboard. Out of the box, WordPress applies four types of updates:

1. Core updates, split into development, minor (security and maintenance), and major releases
2. Plugin updates, controlled per plugin since WordPress 5.5
3. Theme updates, controlled per theme since WordPress 5.5
4. Translation file updates, which are low risk and enabled by default

By default, only minor core releases and translations update automatically. Everything else waits for you, unless you change the configuration below. The full reference for this behavior lives in the WordPress advanced administration handbook.

The update policy I recommend for production sites

Before the configuration reference, here is the policy question that actually matters: which updates are safe to apply without a human in the loop? For most business-critical WordPress sites, this is the split that balances security against stability:

• Auto-update: minor core releases and translation files. Minor releases are almost exclusively security and maintenance fixes, and the risk of staying unpatched outweighs the risk of the update.
• Auto-update selectively: plugins with a strong release track record and a small footprint, especially security-focused plugins where patch speed matters. Use the auto_update_plugin filter with an explicit allowlist rather than turning it on globally.
• Never auto-update: major core releases, themes, and any plugin that touches revenue-critical paths such as checkout, forms, or membership. These go through staging, get reviewed, and deploy on your schedule.

If your code is under version control and deployed through a pipeline, WordPress will skip automatic updates when it detects a VCS checkout, and that is correct behavior. In that setup, updates belong in the deployment pipeline, not in a background process on the production server. Update policy is one part of a broader operational posture; the same thinking applies to access control and deployment discipline covered in WordPress security hardening for enterprise sites.

Configuring updates with wp-config.php constants

Constants give you a blunt, site-wide switch, and the wp-config.php documentation covers every option in detail. To disable or enable the entire automatic updater:

// Disable all automatic updates.
define( 'AUTOMATIC_UPDATER_DISABLED', true );

To control core updates specifically, use WP_AUTO_UPDATE_CORE, which accepts three values:

// All core updates: development, minor, and major.
define( 'WP_AUTO_UPDATE_CORE', true );

// No core updates at all.
define( 'WP_AUTO_UPDATE_CORE', false );

// Minor updates only (the default on production sites).
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

The default is minor on production installs and true on sites running a development version. For most managed environments, leaving it at minor is the right call.

Configuring updates with filters

Filters give you fine-grained control and belong in a small must-use plugin, not in a theme, so the policy survives theme changes. The master switch mirrors the constant:

// Disable the automatic updater entirely.
add_filter( 'automatic_updater_disabled', '__return_true' );

Core update types can be controlled individually:

add_filter( 'allow_dev_auto_core_updates', '__return_false' );   // Development releases.
add_filter( 'allow_minor_auto_core_updates', '__return_true' );  // Security and maintenance releases.
add_filter( 'allow_major_auto_core_updates', '__return_false' ); // Major releases.

Plugins and themes have their own switches:

add_filter( 'auto_update_plugin', '__return_false' ); // All plugins.
add_filter( 'auto_update_theme', '__return_false' );  // All themes.
add_filter( 'auto_update_translation', '__return_true' ); // Translation files.

Auto-updating an explicit allowlist of plugins

The auto_update_plugin filter passes the update item, which lets you auto-update only the plugins you have explicitly approved. This is the pattern I use on production sites:

/**
 * Auto-update only an approved allowlist of plugins.
 *
 * @param bool   $update Whether to update the plugin.
 * @param object $item   The plugin update offer.
 * @return bool
 */
function mg_auto_update_allowlisted_plugins( $update, $item ) {
	$allowlist = array(
		'akismet',
		'wordfence',
	);

	if ( in_array( $item->slug, $allowlist, true ) ) {
		return true;
	}

	return $update;
}
add_filter( 'auto_update_plugin', 'mg_auto_update_allowlisted_plugins', 10, 2 );

Version control, deployments, and update emails

WordPress skips automatic updates when it detects a version control directory such as .git in or above the install path. If you deploy through a pipeline, keep that behavior; the pipeline is the correct place to apply and test updates. Overriding it is possible, but should be a conscious decision, not a workaround:

// Allow automatic updates despite a VCS checkout. Use deliberately.
add_filter( 'automatic_updates_is_vcs_checkout', '__return_false', 1 );

Update result emails can be tuned so the right people are notified without flooding a shared inbox:

/**
 * Only send core update emails on failure or critical results.
 *
 * @param bool   $send        Whether to send the email.
 * @param string $type        One of 'success', 'fail', 'critical'.
 * @param object $core_update The update offer that was attempted.
 * @param mixed  $result      The update result, possibly WP_Error.
 * @return bool
 */
function mg_update_emails_on_failure_only( $send, $type, $core_update, $result ) {
	return in_array( $type, array( 'fail', 'critical' ), true );
}
add_filter( 'auto_core_update_send_email', 'mg_update_emails_on_failure_only', 10, 4 );

For larger fleets, checking update status across sites is faster from the command line; the same commands covered in WP-CLI commands I use on production WordPress sites handle updates in a scriptable, auditable way.

Frequently asked questions

Treat updates as policy, not configuration

The constants and filters above are the mechanics, but the decision that protects a production site is the policy: minor core and vetted plugins update automatically, everything with breakage potential goes through staging, and the whole thing is written down so it survives team changes. Configure once, document it, and review it when your plugin stack changes. Updates are also only one layer of a maintenance posture; pairing this policy with the server-level controls in hardening WordPress without a plugin and the workflow discipline in WordPress security best practices for developers and agencies covers the rest.