How Updates Work

EcoHub never writes over a plugin that is currently running. That is how you corrupt a live server. Everything below follows from that one rule.

The update pipeline

  1. EcoHub tells the plugin which resources have newer builds.

  2. Each build downloads to a temporary file.

  3. The download is checked against the SHA-256 hash EcoHub sent. If it does not match, the file is thrown away and nothing is installed.

  4. The file is checked to make sure it is actually a plugin jar.

  5. Only then does it move into plugins/update/, the folder Bukkit swaps in at the next startup.

Console output from an update check

Checking manually

/ecohub check                      # check, and report what is available
/ecohub update all                 # check, and install everything available
/ecohub update EcoCrates EcoShop   # check, and install only these

/ecohub check never installs, whatever auto-install-updates is set to. /ecohub update always installs the resources you name.

Filename changes

If a new build has a different filename to the one you have installed — for example EcoCrates-2026.29-polymart.jar being replaced by an EcoHub build — the plugin writes a small helper jar that renames the file on the next boot and then deletes itself.

This is cosmetic. The contents of the jar are already correct either way. The helper is a separate plugin with its own plugin.yml and a loadbefore list, so Bukkit runs it before the plugins whose files it is renaming.

Pending renames are recorded in plugins/EcoHub/renames.yml.

Version numbers

Versions look like 2026.35, which is the year and the week. A hotfix in the same week adds a third number, so 2026.35.1. Older Eco releases used the older style like 7.9.3, and the plugin understands both when it sorts them.

Revocation

If an EcoHub account is banned for winning a chargeback, the paid plugins tied to that account have their entitlement revoked, and this plugin deletes those jars from the server. Installing the plugin is what opts you into that.

Only paid resources are affected. Free plugins are never removed, whatever the state of the account.

Three things are worth knowing about how it behaves:

It fails safe. It only ever deletes a jar when EcoHub explicitly says that resource is revoked, in a response that came back cleanly. If your server cannot reach EcoHub, or gets a timeout, or an error, or a response it cannot read, nothing is deleted. An offline server will never remove its own plugins.

It handles locked files. If the operating system will not let the file be deleted because the plugin is still running, which happens on Windows, the plugin is disabled so it stops working straight away, and the deletion is retried on the next restart. Outstanding deletions are recorded in plugins/EcoHub/deletions.yml.

Where things are stored

plugins/EcoHub/
  config.yml        settings
  link.yml          your API key. Treat this like a password
  renames.yml       filename changes waiting for the next restart
  deletions.yml     revoked jars that could not be deleted yet
  events.yml        install records waiting to be sent
  history/          logs of updates and removals

Where to go next

  • Turn auto-install off: Plugin Config.

  • A download failed: Troubleshooting.

  • What gets reported: Data and Privacy.