PluginPulse

Add auto-updates to a plugin jar you already have

For a compiled Paper or Spigot plugin — no source code, no build tools, no account.

Not what you need?

  1. Choose your plugin jar

    The file stays on your computer. Nothing is sent anywhere.

    • Your original jar is never changed. You get a brand-new copy back, saved to your downloads — the file you picked stays exactly as it was.
    • Nothing is uploaded. The whole process happens inside this page, so it works with the internet switched off once the page has loaded.
    • You can look before you leap. Preview shows you what's inside the jar and whether it can be updated, without changing a thing.
    
    
    2. 

    
  2. 
      
    Where do updates come from?
    
      
    Fill in at least one — this is the page the plugin will check for new versions.
        If more than one is filled in, #1 is tried first and the others are backups.
        How do I find these?
    

      
    
        
    
          Modrinth
          modrinth.com/plugin/viaversion
        
    
        
    
          
          
        
    
      
    

      
    
        
    
          GitHub
          github.com/ViaVersion/ViaVersion
        
    
        
    
          
          
        
    
        
    
          
        
    
        
    Leave the second box empty for a normal, public project. If the code is kept
          private, GitHub won't let the plugin look at it without a pass key, and that box is where the
          key goes. Safest way: type ${GITHUB_TOKEN} and put the real key in
          a setting called GITHUB_TOKEN on the server that runs the plugin — then the key
          itself never goes into the file you hand out. Typing the key here instead puts a copy of it
          inside the jar, so only do that for a jar that stays on your own server.
    
      
    

      
    
        
    
          Hangar
          hangar.papermc.io/kennytv/ViaVersion
        
    
        
    
          
          
        
    
      
    

      
    
        
    
          Jenkins
          the job page, e.g. ci.athion.net/job/FastAsyncWorldEdit/
        
    
        
    
          
          
        
    
        
    
          
        
    
        
    For plugins that publish test builds from their own build server. These are
          work-in-progress builds rather than finished releases, so expect rough edges. Builds like these
          come without the security check the tool normally does, so the tool turns that check off for
          this plugin — otherwise it would refuse every download.
    
      
    
    
    3. 

    
  3. 
      
    How should it behave?
    
      
    What the plugin does when it finds a newer version.
    
      
      

      
    
        Advanced settings
        
        
        
        

        
        
    Sometimes an author publishes an update that turns out to be broken and puts out a
          fix a few hours later. Tick this and the plugin ignores a release until it has been available for
          the number of hours below, so those quick fix-ups land first. It goes by the date shown on the
          plugin's own page, and an admin can still install a release straight away with the update command.
    
        

        
        
    Normally an update waits for your next restart. With this on, the plugin swaps
          itself over while the server keeps running — players stay connected. It checks first, and if
          swapping would be risky (on a Folia server, when other plugins are built on top of this one, or
          when the plugin loads a helper file the server can only load once), it leaves the update waiting
          for your next restart instead. Safe to leave off if you're unsure.
    

        
      
    
    
    4. 

    
  4. 
      
    Generate your updated jar
    
      
    You'll get a new file called yourplugin-pulse.jar in your downloads.
    
      
      
      
    
      
    Try the new jar on your own server before giving it to anyone else.
        The tool can't start the plugin for you, so it can't promise the plugin still runs.
    
    
    5. 
  


  

    
Good to know

    
    

      Technical detail, for developers
      
The page uses the wrapper strategy: it generates a subclass of the plugin's main class, repoints
        the descriptor at it, and relocates the shaded core under the plugin's own package. A
        final main class (the Kotlin default) has that flag cleared so the wrapper can
        subclass it, which only permits subclassing and is safe for a plugin main class. The
        pluginpulse-inject CLI instruments final mains in place instead. Both produce the
        same wiring; the class-file version is irrelevant to either.