---
title: "Updating Plugins on a Live Server Without Downtime"
excerpt: "Why AMX Mod X cannot hot-swap a plugin binary, how to stage a new .amxx safely, use amxx pause and a map change to reload cleanly, and roll back the moment something breaks."
category: "administration"
tags: "plugins, maintenance"
image: ""
read_time: "8 min read"
---
<p>You want to push a new version of a plugin to a busy server without kicking everyone. The honest constraint first: AMX Mod X <strong>cannot hot-swap a compiled plugin at runtime</strong> &mdash; there is no "reload this <code>.amxx</code> in place" command. Plugins are loaded when the map loads. But you can absolutely update without a visible outage by staging the file and letting the next map change pick it up, and by using <code>amxx pause</code> to neutralize a bad plugin instantly. Here is the safe procedure.</p><h2>1. Understand when plugins actually load</h2><p>The plugin list in <code>plugins.ini</code> and the <code>.amxx</code> files are read once, at map load. Replacing <code>myplugin.amxx</code> on disk mid-map changes nothing until the map changes &mdash; the running server holds the old code in memory. This is why "I uploaded the new version and nothing happened" is not a bug. The map change is the reload event. See <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a> for how the list is processed.</p><h2>2. Stage the new file, do not overwrite blind</h2><p>Keep the current version so you can roll back in seconds:</p><pre>cd addons/amxmodx/plugins
cp myplugin.amxx myplugin.amxx.bak     # keep the known-good build
cp /tmp/myplugin_new.amxx myplugin.amxx</pre><p>Now the new binary is on disk but the running server is still executing the old one in memory. Nothing has changed for connected players yet. This staging step is what makes the update safe: you have the new file ready and the old one preserved, and you have not disrupted the live map.</p><h2>3. Trigger the reload on your terms</h2><p>Let the reload happen at a natural boundary. Two options:</p><ul><li><strong>Wait for the next map change.</strong> Zero disruption &mdash; the plugin updates when the map rotates anyway, and players never notice.</li><li><strong>Force a controlled change.</strong> If you cannot wait, change to the same or next map when the round count is low. From RCON: <code>changelevel de_dust2</code> reloads every plugin cleanly. Warn players first with a <a href="/plugins/csb-adverts">chat notice</a>.</li></ul><p>A <code>changelevel</code> is a few seconds of reconnect, not a real outage. It is the closest thing to a graceful restart and it reloads the whole plugin set from disk, including your new file.</p><h2>4. Kill a misbehaving plugin instantly with pause</h2><p>If a plugin starts causing problems and you need it gone <em>now</em> without a map change, pause it from the server console:</p><pre>amxx pause myplugin.amxx
amxx unpause myplugin.amxx</pre><p><code>amxx pause</code> stops the plugin executing its forwards immediately, for the rest of the current map, without editing any file. This is your emergency brake: a new version is spamming chat or throwing runtime errors, you pause it, the server stays up, and you sort the file out before the next map. Confirm the state with <code>amxx plugins</code>, which shows each plugin as <code>running</code>, <code>paused</code>, or <code>bad load</code>.</p><h2>5. Verify the new version loaded, then roll back if not</h2><p>After the map change, check the plugin loaded and reports its new version:</p><pre>amxx plugins</pre><p>Find your plugin in the list &mdash; it should read <code>running</code> and, if the version string was bumped, show the new number. If it says <code>bad load</code>, the new build is broken (a missing module, a compile targeting the wrong AMXX branch). Roll back instantly:</p><pre>cp myplugin.amxx.bak myplugin.amxx
changelevel de_dust2</pre><p>You are back on the known-good build in one map change. Never delete the <code>.amxx</code> while its line is still in <code>plugins.ini</code> &mdash; that produces a <code>bad load</code> on every map load; comment the line instead.</p><h2>Common errors</h2><ul><li><strong>New version has no effect</strong> &mdash; you overwrote the file but did not change the map. Plugins reload at map load; force a <code>changelevel</code>.</li><li><strong><code>bad load</code> after the update</strong> &mdash; the new build needs a module you do not have, or was compiled for a different AMXX version. See <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>.</li><li><strong>Server crashed on the new plugin</strong> &mdash; roll back to the <code>.bak</code> and change map; investigate offline with the <code>debug</code> flag.</li><li><strong>Paused plugin came back next map</strong> &mdash; <code>amxx pause</code> only lasts the current map. To disable it durably, comment the line in <code>plugins.ini</code>.</li><li><strong>Two versions loaded / duplicate</strong> &mdash; the file exists under two names both listed in <code>plugins.ini</code>. Keep exactly one line per plugin.</li></ul><h2>Verification</h2><p>Do a dry run on a test server first: bump the plugin's version string, deploy with the steps above, change map, and confirm <code>amxx plugins</code> shows the new version <code>running</code>. Then rehearse the rollback &mdash; restore the <code>.bak</code>, change map, confirm the old version is back. Once you trust the procedure, apply it live at a low-population moment. Pair this with the <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> settings so new plugin cvars are configured before they load.</p>