How to install and configure Code Lock on a DayZ server

By Niko Catarino

Updated 3 October 2026

To add electronic Code Locks to a DayZ Steam PC server, install the original client-required package, register its loot entry and configure the generated files in the server’s active profiles directory. Test access with two normal players and confirm the gate and lock state after a supported restart.

This procedure covers Code Lock, Workshop item 1646187754, published by Room Service. Expansion Code Locks and similarly named repacks are separate packages. Xbox and PlayStation servers cannot load this Workshop mod.

Prepare the server and recovery set

Start with a server that accepts a vanilla client join. Record the game branch, active mission, current mod list and installed Code Lock package. Read the current Workshop requirements and change notes before applying it to your game build.

Take a stopped backup of the mission, world, profiles and mod-owned data. Rehearse on a separate instance before using existing community gates or structures. Locate both the active mission template and the directory selected by -profiles= or your panel’s corresponding service setting.

The author requires use of the original Workshop distribution and prohibits repacks. Server monetization requires the author’s permission under the published terms. Keep your server settings separate from the original package.

Install the original package

In VXPanel:

1. Stop the test service and open Mods.
2. Find item 1646187754, check the publisher through its Steam link and choose Install.
3. Wait for the package to appear under Installed mods. Keep it in client-required scope and include any current author-required dependencies.
4. Check its accepted .bikey in the server’s central keys/ directory. The locally inspected package supplies Keys/CodeLockv3.bikey; use the file shipped with your release.
5. Start once and read the new logs, then join with a matching client. Stop before editing the generated settings.

For a self-managed server, follow manual package and key deployment. Retain your existing launch command and append the installed folder to its normal mod argument. For a folder called @Code Lock, the package entry is:

"-mod=@Code Lock"

Keep the rest of your client-required mod list in that same argument, separated with semicolons. Quote the complete argument when folder names contain spaces, retain dependency order and keep signature verification enabled. Putting Code Lock into -serverMod= would omit the client’s required assets.

Add Code Locks to the loot economy

The locally inspected original package includes XML/types.xml. It contains a single <type name="CodeLock"> fragment, rather than a complete <types> document. Uploading that fragment as a complete additional economy file would leave it without the expected root.

Copy the entry from the installed release and wrap it as follows. The comment represents the complete copied entry; it is not a working lock definition:

<types>
    <!-- Paste the complete supplied CodeLock type entry here. -->
</types>

1. Save this complete document in the active mission as codelock_ce/codelock_types.xml.
2. Register it inside the existing <economycore> root of that mission’s cfgeconomycore.xml:

<ce folder="codelock_ce">
    <file name="codelock_types.xml" type="types" />
</ce>

3. Preserve the other registrations. Check for a previous CodeLock definition before loading another copy.
4. Validate the XML, start the service and inspect the new economy logs.

The inspected entry uses Industrial and Farm locations. Review its population, lifetime and counting flags against the installed release and your terrain. Follow the loot guide when changing those values. Keep a lock’s loot population separate from the permissions and raiding settings below.

If your community supplies locks only through a trader, configure that mod’s inventory and stock instead of assuming a types entry adds a listing. The Expansion Market guide covers that separate path; use classname CodeLock only after confirming it exists in your installed release.

Find the generated Code Lock files

In the inspected original package, the scripts resolve these paths relative to the active profiles directory:

<profiles>/CodeLock/CodeLockConfig.json
<profiles>/CodeLock/CodeLockPerms.json

Code Lock also maintains logging beneath its profiles folder. Use Files and SFTP in VXPanel to inspect the directory belonging to the running service.

Generate the files with a first startup, then stop the service and back them up before editing. Keep fields generated by your installed release. An older root-level CodeLockConfig.json is a migration input in the inspected code; editing it is not the same as editing the generated file inside CodeLock/.

The examples below match the locally inspected package. If your generated schema differs, use that release’s instructions and fields rather than replacing it with an older complete configuration.

Set attachment and raiding behavior

The inspected configuration stores the following switches as strings. Preserve the quotes around "true" and "false"; JSON booleans are different values.

Field	Job
CanAttachToGates	Allows the mod’s gate attachment action.
CanAttachToTents	Controls its supported tent attachment action.
CanRaidGates	Controls the mod’s gate-lock raid action.
CanRaidTents	Controls its tent-lock raid action.
DeleteLockonRaid	Controls lock deletion after this mod’s successful raid action.
OwnerOnlyDismantle	Restricts dismantling of a vanilla fence carrying this mod’s lock to the lock owner when enabled.

Scroll to see all columns →

For a test that permits gate locks and disables this mod’s lock-raid actions, edit these replacement fields in the complete generated CodeLockConfig.json:

{
  "CanAttachToGates": "true",
  "CanAttachToTents": "false",
  "CanRaidGates": "false",
  "CanRaidTents": "false"
}

Keep the other generated fields. This fragment is not a replacement for the complete file. Validate the edited document and restart the test service.

Turning off these lock-raid actions does not establish protection against wall damage, explosives or another raiding mod. Test those paths under your intended PvE or raiding rules.

For communities that permit lock raiding, review the generated GateRaidTime, TentRaidTime, RaidIncrements and ToolDamageonRaid values with that release’s behavior. Positive validation limits exist in the inspected code, so setting a time to zero is not a reliable way to disable raiding. Use the supported switch and measure the completed action on the test instance.

Retain ActionRateLimit and UIRateLimit unless you have an author-supported reason to change them. Record each edit and its observed effect before changing another field.

Configure Code Lock admin permissions

Code Lock’s permissions are separate from VPP permissions and the server’s join whitelist. The inspected CodeLockPerms.json contains an array of entries with playerId and playerPerms.

To grant a selected administrator permission to open locks without granting passcode changes or removal, use the following entry format. Replace YOUR_ADMIN_STEAM64_ID with that administrator’s actual Steam64 ID before uploading:

[
  {
    "playerId": "YOUR_ADMIN_STEAM64_ID",
    "playerPerms": {
      "CanOpenLocks": "true",
      "CanChangePasscodes": "false",
      "CanRemoveLocks": "false"
    }
  }
]

This is a complete single-administrator array for the inspected schema. Reconcile it with the administrators you intend to retain, remove sample identities and keep the ID as a string. The permission switches are strings too. Leave capabilities disabled when the administrator does not need them.

Stop before editing, validate the array and restart. The inspected code also reloads permissions on its configured interval; a stop and restart gives the test a known starting point. Test an administrator and a normal player separately. Avoid taking screenshots that expose players’ chosen lock codes.

Test a gate with two normal players

Use the installed CodeLock classname and a supported test gate. With VPP, an admin can supply the lock, but perform the player-access checks without elevated lock permissions.

For the inspected vanilla-gate action, use a fully constructed player-built gate. Existing map doors need a supported integration; the gate attachment setting does not establish that every building door accepts the lock.

1. Have the first player attach the lock and set a temporary test code through its UI.
2. Close the gate. Confirm the second player cannot open it without the required access.
3. Enter the test code with the second player and check the intended guest access.
4. Change the code as the owner and recheck access. Record what happens to existing authorized access rather than assuming a code change clears it.
5. Attempt the lock-raid action under your chosen rule, and test other enabled damage paths separately.
6. Stop and start the same test world. Confirm the gate, lock, code and owner/guest behavior are preserved as intended.
7. Check the administrator’s permitted action and verify that a normal player cannot perform it.

For BBP, tents or other supported objects, repeat these checks on the actual object class. The BBP installation guide covers building deployment; a successful vanilla gate test does not prove the same lock integration works on every modded door.

Fix common installation failures

Symptom	Check
Client rejected	Matching original package, .bisign files, accepted key and client-required scope. Follow missing-PBO troubleshooting.
No configuration appears	The service’s actual profiles path, a successful mod startup and permission to write the directory.
Setting has no effect	Active CodeLock/CodeLockConfig.json, complete generated schema, exact field case and string-valued switches.
Locks do not spawn as loot	Correct classname, <types> root, active mission, one registered definition and supported location restrictions.
Lock will not attach	Supported object, attachment setting, existing attachment and conflicts with another lock system.
Admin option absent	Actual Steam64 ID, Code Lock permissions array, supported capability and a fresh player join. VPP permissions are independent.
Locks vanish after restart	World compatibility, class loading, the affected object’s definitions and persistence errors; preserve the failed logs.

Scroll to see all columns →

Roll back without losing the old world

Stop the test instance, retain its logs and restore the previous launch list, mission and compatible saved state from the same recovery set. Restore the profiles configuration too if it was part of the change.

Before removing Code Lock from an existing world, follow mod removal and handle gates or containers that retain mod-owned lock state. A blanket persistence deletion would erase the world you backed up and would not repair a malformed configuration.

Related documentation: Bohemia’s mission-file registration reference.

Return to the DayZ guide directory for the next server task.