Joomla tutorials by Joomlaboratory

Automatic core updates can keep a Joomla 6 site patched within hours of a security release, but only if you turn them on deliberately and build a safety net around them. This tutorial shows site administrators how to make that decision and configure it, and shows developers what happens under the hood and how to keep extensions from breaking.

Why this feature exists

When Joomla ships a security fix, attackers study the patch to find the vulnerability and then script mass attacks. According to the Joomla project, that window can be as short as 10 to 12 hours for critical, easy-to-exploit issues (Joomla Community Magazine). Few people can update every site they manage that fast.

Automated core updates arrived in Joomla 5.4 and 6.0, released together in October 2025. They cover minor, patch and security releases, never a jump to a new major version (Joomla 5.4 new features). At the time of writing, the current release is Joomla 6.2, and Joomla 5.4 has moved to security-only support.

The feature is a genuine security win for unattended sites. For sites you actively maintain, it is a trade-off you should weigh, and that is what the rest of this tutorial is about.

How it works under the hood

Automated updates are a remote trigger for update functions Joomla already had: detecting a new version, downloading and extracting it, and running post-update scripts. Previously a person had to click through those steps in the backend. The new feature lets a central server on joomla.org ask your site to run them.

The cycle runs like this:

1. Registration. Your site registers with the update server and hands over an authentication token generated on the site.
2. Health checks. The server periodically checks registered sites. Registration sends technical details such as PHP version, database type and version, CMS version and server OS.
3. Trigger. When an eligible release is available, the server uses the token to tell your site to start the update.
4. Pull, verify, install. Your site downloads the package itself and verifies it with The Update Framework (TUF) before installing.
5. Notification. Super Users receive an email after a successful or failed update.

Two design choices matter most for security. First, the process is pull-based: the server cannot upload code to your site. The Joomla project describes the worst case of a compromised update server as an attacker applying a legitimate pending update early. Second, TUF, added in Joomla 5.1, verifies that update metadata was signed by the Joomla project, using separate signing roles, threshold signatures and expiring metadata. That protects you even if the distribution infrastructure is compromised.

What developers should know

The site-side endpoints are built on Joomla's Web Services system, as new API routes in com_joomlaupdate. The server talks to your site through the /api path, not the /administrator login. Two consequences follow:

• If you disable the Web Services API (the API plugins or the API application), automated updates stop working.
• Locking down /administrator with IP rules or HTTP auth does not block the update server, because it never uses that path. Factor the API path into your firewall and WAF rules.

The server application is open source, so you can read exactly what it does: Automated-Updates-Server on GitHub.

What is and isn't updated

The last row catches people out. Softaculous, Installatron and similar hosting tools can update Joomla on their own schedule, bypassing Joomla's setting and TUF entirely.

Should you enable it?

Enable it on sites nobody watches closely; keep manual control on sites where you test and guarantee every change. The real question is which risk is bigger for a given site: an unpatched vulnerability, or an untested update.

The defaults depend on how the site was created. New Joomla 5.4+ or 6.x installations have automated updates enabled. Sites upgraded from 5.3 or earlier have them disabled until an administrator opts in. A one-click install from your host, or a dev copy later pointed at a production domain, may therefore be auto-updating without anyone having chosen it. Audit your sites rather than assuming.

A middle path also works for agencies: disable core auto-updates, but keep monitoring that alerts you the moment a security release lands, and commit to applying it within a day.

Step by step: configuring automatic updates

All settings live in the Joomla Update component. Before you start, confirm the site meets the requirements: it is publicly reachable, uses the Default update channel, has minimum stability set to Stable, and has working mail so notifications arrive.

1. Check the update channel. Go to System → Update → Joomla and click Options. On the Update tab, set the update channel to Default and minimum stability to Stable. Automated updates will not run on the Testing or Next channels, which is also good practice for production sites.
2. Open the Automated Updates tab. In the same Options screen, select Automated Updates.
3. Turn the feature on or off. Set Automated Update to Yes or No. On save, the site registers with (or unregisters from) the update server.
4. Choose who gets emails. Set the user groups that receive success and failure notifications. Super Users is the default; consider adding a dedicated maintenance account whose mailbox someone actually reads.
5. Save and close.
6. Verify on the dashboard. The Home Dashboard shows an Automated Updates quick icon with the current registration status. If it shows an error, see the troubleshooting notes below.

On a brand-new installation, the final screen of the installer offers a Disable Automated Updates button. It disappears once you remove the installation folder, so decide before you click through. If you miss it, use the steps above.

If the dashboard says registration failed

• WAF or bot protection. Cloudflare Bot Fight Mode and aggressive firewall rules have been reported to block the update server with 403 errors. Allow requests to the site's /api/ path from the update server.
• API disabled. Check that the API application is reachable and the Web Services plugin for Joomla Update is enabled.
• Not public. Sites behind HTTP auth, on intranets or on localhost cannot register.
• Wrong channel. Anything other than Default plus Stable blocks registration.

Build a safety net

Automated updates go straight to the live site with no staging step, so the safety net has to exist before the update fires. The Joomla project itself calls a complete backup concept optional but important; treat it as mandatory.

Backups you can actually restore

• Schedule daily backups with a tool such as Akeeba Backup, run by a real cron job rather than a visitor-triggered pseudo-cron. You cannot predict when an update will run, so daily is the minimum.
• Store copies off the server, in cloud storage or a remote host. A backup on the same disk does not help if the account is compromised or the disk fails.
• Test a restore to a scratch subdomain at least once a quarter. An untested backup is a hope, not a plan.
• Keep at least seven days of history so you can roll back past an update you only notice was broken days later.

A staging canary

For sites where you want automation and safety, let a staging clone act as a canary. Keep a staging clone on the same hosting stack, with the same extensions, and give it a public URL behind a robots block so it can register. When staging updates, run a quick smoke test there. The order in which sites update is not guaranteed, but a canary still gives you a second signal and a ready place to reproduce problems.

Monitoring

• Uptime monitoring that checks a meaningful page, not just the home page. Probe a page that loads your key extensions.
• Error-log alerts for new PHP fatal errors.
• A working notification inbox. Failure emails depend on the site still running after the update. If an update takes the site down, you will hear about it from uptime monitoring, not from Joomla.
• A version check in your monitoring dashboard, so you notice when a site's version changes without you.

For developers: keeping extensions compatible

Core updates but your extension doesn't, so compatibility is now your responsibility on someone else's schedule. Minor releases can land on thousands of sites within hours, and users will blame whatever broke first.

Test against releases before they ship

• Follow the release calendar. Joomla publishes alpha, beta and release-candidate builds before each minor version. Run your extension against the RC on a test site, not the final release.
• Automate it. Add the upcoming Joomla version to your CI matrix. A nightly job that installs the latest RC, installs your extension and runs your tests catches most breakage. Joomla's own CI and the GitHub Codespaces environment added in 5.4 are good references for setting this up.
• Test on the PHP versions your users run. A core update and a host's PHP upgrade often arrive close together.

Write code that survives updates

• Use public APIs only. Stick to documented services, events and MVC classes. Reaching into core internals or overriding core classes is what breaks on minor releases.
• Watch the deprecation log. Enable deprecation logging in Global Configuration on your dev site and fix every entry that points at your code.
• Keep layout overrides thin. If your extension ships template overrides, override as little markup as possible, so core output changes have less to collide with.

What the Backward Compatibility 6 plugin does and doesn't do

Joomla 5.4 added the Behaviour - Backward Compatibility 6 plugin. It keeps older class aliases and APIs working, so sites can move from 5.4 to 6 without every extension being fully updated first. Treat it as a bridge, not a foundation:

• It covers code removed or changed in the move to Joomla 6, not bugs in your own extension.
• It is expected to go away in a future major version, so test your extension with the plugin disabled and aim for zero dependency on it.
• Your extension's documentation should say clearly whether it needs the plugin.

Give admins an update path that matches core

Publish your updates through a proper Joomla update server (an update site XML in your manifest), so admins see your fix in the same place as core updates. When a core release breaks your extension, ship a patch quickly and say so on your changelog and support channels.

When an update goes wrong

Work from least to most drastic: confirm what changed, fix the specific breakage if you can, and restore the backup if you can't fix it quickly. Downtime is usually worse than rolling back one patch release.

1. Confirm the version. Check System → System Information and compare the version with what you expected. Read the release notes for that version to see what changed.
2. Pause further updates. Set Automated Update to No while you investigate, so a follow-up release doesn't land mid-diagnosis.
3. Read the logs. Look at the PHP error log and Joomla's administrator/logs folder for entries timestamped around the update. A fatal error usually names the extension or file at fault.
4. Isolate the cause. If the backend loads, go to System → Manage → Extensions and disable the suspect extension. If only the frontend is broken, check template overrides under System → Site Templates, where Joomla flags overrides whose core files changed.
5. Repair a half-finished update. If the update stopped partway, check for leftover packages in the temp folder and in administrator/cache/com_joomlaupdate. Delete stale package files before retrying, because Joomla may reuse a corrupted download. Then rerun the update from the Joomla Update component, or upload the full update package manually.
6. Restore if needed. If you can't fix it within your agreed downtime limit, restore the latest pre-update backup, keep auto-updates off, and reproduce the problem on staging.
7. Report it. If an extension broke, tell its developer with the Joomla version, PHP version and error message. If core broke, report it on the Joomla issue tracker.

After recovery, write down what happened and the fix. That record helps you decide whether this site should stay on automated updates.

Quick checklist

Automatic updates are neither good nor bad by default; they are right for some sites and wrong for others. Make the choice per site, then build the safety net either way.

• Audit every site: is Automated Update on or off, and was that a deliberate choice?
• Check the hosting panel (Softaculous, Installatron) for a separate auto-updater
• Confirm update channel is Default and minimum stability is Stable
• Set notification emails to an inbox someone reads
• Schedule daily off-server backups and test a restore
• Set up uptime and error-log monitoring
• Allow the update server through your WAF on the /api/ path, if auto-updates are on
• Developers: add the next Joomla RC to your CI matrix and test with Backward Compatibility 6 disabled
• Write down your recovery steps before you need them

Sources

• Automatic core updates in Joomla, David Jardin, Joomla Community Magazine
• Joomla 5.4 new features, Joomla Developer Manual
• Joomla 6.0 and 5.4 are here, Joomla.org announcement
• How to disable automated Joomla core upgrades, mySites.guru (vendor perspective, detailed on mechanics and requirements)
• Automated Core Update Client pull request, Joomla issue tracker
• Automated-Updates-Server, source code on GitHub