The leader in modular sign based block protection


  • No databases. In-game signs only.
  • Super permissions support ONLY.
  • Protects any type of furnace, dispenser, chest, door, trapdoor, cauldron, enchantment table, or brewing stand.
  • Broadcast specific admin actions to those with ""
  • Denies explosions, pistons, and redstone from circumventing protection
  • Timed doors, [Timer:#], that toggle after a certain delay
  • Server-wide protected blocks, use [Everyone] on line 3 or 4
  • Modular plugin hooking system, add your own easily
  • Compatible with Lockette
  • Optional sign coloring
  • Localization support


As this is a Lockette-type plugin, also similar to Alerter or BlockLock, things may seem similar. This plugin was originally created as a continuation of Lockette by Acru to add trapdoor support and other recent developments. Portions of this project were reverse engineered from Lockette and the original idea for a sign-based locking system still belongs with Acru. Credit where credit is due. As this only supports super permissions, if you need a plugin that is more backwards compatible with older configurations, you may want to look at Lockette.

If you have another plugin such as Cenotaph or ChestShop3 that you have integrated with Lockette and would rather use Deadbolt instead, I have created a LocketteSimulator that will allow you to use Deadbolt.

Check GitHub for the most recent files, there is a slight delay in getting files posted here authorized by the staff.


Place a sign next to the item you want to protect and type in the following

  • Line 1: [Private]
  • Line 2: Your name will be automatically filled, users with "deadbolt.admin.create" can specify someone else.
  • Lines 3 and 4: You have a couple options for these lines
    1. Another player's name
    2. Unrestricted access via [Everyone] while preventing breaking
    3. Create an automatic timed door using [Timer:1] through [Timer:9]

Not enough room for all the names you need? Make another sign with the [More Users] on line 1
For ease of use in maintaining your signs without having to break them:

  1. Right click the sign to select it.
  2. Use "/deadbolt <line number> <text>" to directly modify that line. When placing signs, valid locations are to the NORTH, SOUTH, EAST, and WEST of the target block.
    Other valid blocks include:
  • Doors: The blocks above and below.
  • Trapdoors: The block that it is attached to (hinge-block) and directly above/below the trapdoor itself.
  • Fence gates: Any block horizontally adjacent to the gate itself.
    Use your imagination and hide those unsightly signs under walls.
    Also, color is now available! Just add "deadbolt.user.color" and use &1-9,a-f in your sign.


See relevant page


See relevant page

Developer's Corner

DeadboltListener is a new system designed to incorporate your favorite plugin directly into Deadbolt.
To create your own or to view Deadbolt's static API, head over to the Developer's Corner

Currently available for download

  • PermissionsBukkit, PermissionsEx, bPermissions, GroupManager
  • SimpleClans
    [ClanName] [ClanTag]
  • Towny
[TownName] [NationName] (All residents)
+TownName+ +NationName+ (Assistant/Mayor only)
4 Config options: mayor,assistant,wilderness overrides.


Have a completed localization? Drop me a link to it and Ill add it to the repository.
Once added, it is available for automatic downloading by changing the "language" setting in config.yml.


The following issues are known:

  • Double timer doors are broken
  • Force coloring of Signs placed directly onto walls is broken.
  • Vertical trapdoor chaining has been removed because it was only half implemented

Visit github and open an new issue.
Alternatively, try and find me at

Project Members


You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of TheBoomer TheBoomer Apr 10, 2014 at 17:25 UTC - 0 likes
    I saw that you had made a build about a week ago when i checked here, but correct if wrong, all it was was the addition of the trapped_chest to the list of lockable items, and a permission node.... Regardless, I had hoped to induce a comment that would indicate defensiveness ("Actually, we're going all the way with this, we have a plan...") or conclusiveness ("Whats the point, really, everyone should look elsewhere") in the coming days. EdgarL saying "whats the point anymore" for Lockette would either get an echo here, or a stand-up 'then we shall save the lockette people with a solution they can switch to as well' No matter what, Deadbolt was a wonderful plugin to have for the past 2 years.
  • Avatar of md_5 md_5 Apr 10, 2014 at 09:46 UTC - 0 likes

    Builds were released as recently as 8 days ago with fixes for some stuff you mentioned. But yeah with uuids this plugin becomes slightly less appealing.

  • Avatar of TheBoomer TheBoomer Apr 10, 2014 at 09:22 UTC - 0 likes

    The author hasn't addressed any of the comments posted here in well over a year.

    We all know of the issues with the hoppers and hoppercarts and such sucking items out of locked containers, he has not addressed that in a year, not even if you hunt down just the dev versions.

    The author is involved in a great number of projects.

    The simplicity of deadbolt (and the plugin it was meant to continue when that author dropped off the world and the plugin went unrepaired, broken for ages) is based on the fact that the name is on the sign, the sign interaction gets the info needed, bam, done. No heavy database overhead storage system like other lock solutions, and bright and simple and visible to see.

    The switch to UUIDs as the persistance identifier with namechanges means the entire infrastructure plan of such plugin is out the window, as the readable names on the sign will not be reliable. A heavy database is required to store the information one way or another, taking the simplicity of the solution out of the equation.

    _A_ possible db-compromise solution would be to log every sign location and uuid, and a cross-up of uuid/username in the db, and check when a player logs in if their name has changed and uuid is found in the db, then update every sign on the map with their old name to the new name. Then rather than using the db all the time for lookups, only those rare instances where an existing sign-holder name changes, and the rest of the time the plugin still works based on the sign-coverages. However, this could turn into a great way to lag out a server as well during the login event, and would require some well done scheduling and checks to avoid lag. But even if only one sign per minute got changed I'd call that fair punishment for the user to have to wait.

    I will be using such a solution in one of my own server plugins that uses names on signs.

    I have serious doubts that this plugin will continue, even the Lockette curator has expressed in other threads that there is no sense in continuing with Lockette since the whole point was lightweight security and the neccesity to have everything now in a database to make any bridge solution like mine work is still a lot of trouble and bother. I expect this author to have similar "Let this be the end" plans, and spend time and resources on other battles that are worth fighting.

    Assume that we have seen the last update here eons ago, and make contingency plans. Be pleasently surprised with myself if the author corrects me "Alas, I am working on a transitioning device, and will support this! And it will have the hopper-theft issue sorted out too! " but otherwise, for practical considerations, this plugin should be marked as abandoned and considered as working, but at high risk. It will continue to work in 1.8, the same way it is now, it just wont support the player changing his name - those signs are locked in stone and might as well be some other user - and if a user abandones his name and a different person picks up the old name, the locked in stone signs will allow the new person to have access to all those signs.

    Block users with changed names from logging into the server, period (and there will be an infinite supply of such plugins to pick from, that will be the new my-plugin-du-jour here) and deadbolt will function just as it has for the past year... Dont block them, and its just a low risk situation of the A->B, C->A two player renaming event with player C now getting all of player A chests, both A and C end up losing their original sign lockages as soon as they change names... I dont know about your servers, but mine has enough regulars who are going to race to change names, and I dont want to chase around breaking all their signs one by one... But I wont block changed-names from joining, so I need to plan on Deadbolt being Dead then.

    Will it work in 1.8? Absolutely, the same as it is now, treating each name-change as a new and different person, and doing a perfect job of allowing only the named players access to the locked system. But it wont support x=Joe, Joe changes name to Bob, now x=Bob.

    Will it be updated? It hasn't been updated in a year to address one particular well-harped, broadly known single-test case scenario, nor gotten a response from the author... The changes required for name-change support are not changes so much as totally rewriting the plugin and dropping a tonne of more stuff in on top of that, plus, a tonne more for coming up with a migration-solution getting servers from where they are now into a new solution. Thats like writing two whole plugins,with one being just a one-time task of importing/converting.

    Based on that history, and that amount of future work required, and the fact that the plugin would be so incredibly different that it defeats the original purpose and may be insanely inefficient to code... dont count on this plugin changing one bit more without some other author picking up the ball and running with it.

  • Avatar of FatherSouth FatherSouth Apr 05, 2014 at 19:30 UTC - 0 likes

    Will this plugin be updating to use UUIDs?

  • Avatar of BlackFing85 BlackFing85 Feb 20, 2014 at 18:06 UTC - 0 likes

    Is it going to update to 1.7.2?

  • Avatar of KevinEssence KevinEssence Feb 02, 2014 at 19:38 UTC - 0 likes

    @niquecraft: Go

    I agree, also got an error because of it and server crashed.

    KevinEssence Server owner at


  • Avatar of niquecraft niquecraft Dec 20, 2013 at 09:10 UTC - 1 like

    Placing hoppers and hopper-carts below protected containers needs to be disabled.

  • Avatar of KevinEssence KevinEssence Dec 19, 2013 at 07:41 UTC - 0 likes

    1. The expire expires instantly when set to 30 days when a player tries to lock chest. I turn it off and it's all fine. Not sure whatsup. 2. Minecart hoppers can steal items..

    Last edited Dec 20, 2013 by KevinEssence
  • Avatar of Paxination Paxination Oct 07, 2013 at 22:52 UTC - 0 likes

    @Jamz4455: Go

    Yeah your way behind. Even lockette has this issue as well.

  • Avatar of Nickbbeezy Nickbbeezy Sep 17, 2013 at 03:53 UTC - 0 likes

    @Danioxo: Go



Date created
Sep 03, 2011
Last update
Aug 05, 2013
Development stage
  • enUS
GNU General Public License version 3 (GPLv3)
Curse link
Recent files