Valheim console commands: a developer reference

Valheim console commands

On a fresh Valheim world, the first afternoon rarely behaves like the design document implied. A scout crosses a black forest, picks the wrong fight with a troll, and the team’s only copper vein is suddenly buried under a crypt entrance. In that moment, many players and technical users ask the same question: is there a debug console, and if so, what can it actually do. This guide answers that question with the precision of a developer reference. It explains what valheim console commands mean in practice, where the input surface lives in the official build, how enabling it differs between single-player, a self-hosted dedicated server, and a modded session, and which commands behave predictably across patches and which ones quietly break.

The goal is not to hand you a giant unsorted list copied from a wiki. The goal is to help you build a mental model of how the console connects to Valheim’s debug command set, where the boundaries are, and how to script repeatable workflows without damaging a world you have already invested hundreds of hours into. If you are building tooling around Valheim, evaluating how the debug console should fit into a mod, or simply trying to recover a corrupted base, this page should be read in order rather than skimmed.

What the Valheim console actually is

Valheim ships a debug command layer that the Iron Gate studio uses internally for testing, world seeding, and quick recovery during development. The commands themselves are not part of a public scripting API in the way a Unity application would expose one. They are a text interface into a small set of debug hooks, and the game can be configured to expose them in a console window that opens with a hotkey. In community shorthand, this surface is the Valheim console, and the typed strings entered into it are referred to as valheim console commands.

It is important to understand the limitations of that surface before you build a workflow around it:

It is a debug tool, not a sanctioned scripting language. Commands may change, be removed, or be reparameterized between updates without changelog notes.
Not every dev tool is exposed through the in-game console. Some debug features only exist when the game is launched with specific startup arguments or when a server runs a particular configuration.
Server-side commands and client-side commands are not interchangeable. A command that works in a single-player session may be silently ignored on a remote server, and vice versa.

That shape is familiar to anyone who has worked on an early-access Unity project: the developer keeps a private set of internal commands, then gradually either formalizes them into a documented API or leaves them in place for QA forever. Valheim’s debug layer is closer to the second pattern, with the addition of a robust modding community that has spent years documenting what is stable.

Enabling the debug console

Before any command can be typed, the console input has to be unlocked. Iron Gate exposes this through a small set of launch flags and configuration values. The exact mechanism differs between the local client and a dedicated server, so the workflow is best thought of as three separate cases.

Single-player and local listen servers

On the local client, the simplest approach is to add a launch argument to the executable. Most platform clients support the form -console, which asks the game to allocate a console window at startup. Once the world is loaded, a configurable hotkey opens and closes the input line, defaulting to F5 in many community builds.

If the executable does not accept the argument directly, the same effect can be produced by setting the environment variable that the Unity player reads for debug surfaces, or by using the launch options field on the platform client. A short checklist for the local case:

Close the game fully before editing launch options.
Add the console argument to the executable or platform launch options.
Restart the client so the change is read at process startup.
Load or create a world, then press the configured hotkey to toggle the console.
If the window does not appear, verify that the launch option was saved without extra spaces or quotes.

Dedicated servers

On a self-hosted Valheim dedicated server, the debug layer is typically enabled through the server’s own configuration and command-line interface rather than through a client hotkey. The server process reads its own flags, and operators can attach to it over a remote session or pipe commands through a wrapper script. The community has standardized on a small set of values that toggle the command listener, the log verbosity, and the admin password gate.

From a developer perspective, the dedicated server is the most useful surface for repeatable valheim console commands. Commands typed into the server console apply to the world state directly, and many server operators wrap those commands in scheduled scripts that run backups, respawn bosses, or rotate seasonal content.

Modded sessions with BepInEx

The BepInEx mod loader is the most common way to extend Valheim’s debug surface. Mods can register new console commands, intercept existing ones, and expose a richer scripting layer that survives across patches more reliably than raw debug hooks. For a developer audience, a BepInEx console is the most stable target for any tool that needs to talk to the running game. It also provides clearer error messages than the stock debug input, which is critical when you are iterating on a mod that itself depends on command outputs.

When a BepInEx console is present, it is best to treat the stock debug input as a fallback rather than a primary surface. Mods may register commands under the same names as debug hooks, and the order of registration is not always obvious. A small naming convention inside the team, such as prefixing project-specific commands, prevents silent shadowing.

Command categories and what they affect

Once the console is open, the commands available can be sorted into a handful of stable categories. The categories are not documented officially, but the community has converged on a useful taxonomy that holds up across recent versions.

Category	Typical targets	World persistence	Common failure mode
Player state	Health, stamina, inventory, skills, position	Usually non-persistent when used as a debug override	Reset on logout if written through the wrong subsystem
World and spawn	Time of day, weather, biome spawn rules, event triggers	Often persistent for time and weather	Spawn rules silently fail when a region is already loaded with chunk caches
Items and inventory	Spawn items, modify stacks, grant resources	Persistent for the receiving container	Item names are case-sensitive and version-pinned
Building and structures	Snap integrity, build distances, removal tools	Persistent edits to placed objects	Removing structures with shared IDs corrupts the build list
Server administration	Bans, kicks, save schedules, broadcast messages	Persistent at the world level	Requires operator privilege on dedicated servers

The categories are useful because they expose a simple truth: a command that mutates player state may behave very differently from one that mutates world state, and the difference between the two shows up when a player logs out or the server restarts. A practical habit is to record which commands are persistent in your team’s runbook, and to treat any command that touches world or building state as one that deserves a backup before it is run.

Player state commands in practice

Player state commands are the most frequently used part of valheim console commands because they solve the most common operational problems. A player loses their starter gear to a fall, a raid wipes a base and burns the workbench, or a developer wants to test a balance change without playing through ten hours of progression. The console can answer each of these without leaving the session. For the topic Take Command Console, the Wikipedia article places this part of the discussion in context.

The mechanics of a player state command are usually straightforward. The command accepts a target player identifier, a field name, and a value, and writes the value into the live character object. The persistence model depends on the subsystem. Health and stamina are recomputed from equipment and food buffs, so a forced value is often only stable until the next damage tick or stamina drain. Inventory and skill values, by contrast, are persisted through the character file, so a grant through the console is roughly equivalent to earning the item through gameplay.

That distinction is the single most common source of confusion in player state work. A developer who tries to lock a player’s health to a high value with a recurring command will find that the value holds only as long as no other system writes to it. A grant of an item, on the other hand, behaves the way most players expect: it stays.

World, weather, and event commands

World state commands are the second largest group, and they are the most sensitive to the order in which they are issued. A time-of-day command, for example, writes to a world clock that other systems sample on a tick, so the value is best set when the relevant region is loaded and idle. A weather command affects a region-level subsystem that caches its own state, so forcing a clear sky in a swamp biome does not always clear the cached weather flag, and the cloud cover can return on the next server tick.

Event triggers are an interesting middle case. The Valheim random event system is driven by a world-level scheduler that chooses a candidate event, then asks the target region whether it can host the event. A command that forces an event typically writes to the scheduler directly, which can lead to an event starting in a region that has not been loaded, and the visible effects only appear when a player crosses into the region. For repeatable testing, the standard pattern is to teleport a test character into the target region, wait for the chunk to load, and only then issue the event command.

World command type	Best issued when	Avoid when	Validation step
Time of day	Region loaded, no boss active	During a server save	Watch the sun shadow direction for a full cycle
Weather	Region loaded, no event active	Mid-raid or during a boss fight	Cross region border and re-enter
Event trigger	Target region loaded, test player present	All players offline	Confirm event banner in HUD
Biome reset	No players in the region	Active base in the region	Sample a known POI and verify state

The validation column is the part most guides skip, and it is the part that saves the most time in practice. A command that appears to succeed because the console prints an acknowledgement is not always a command that actually took effect. Sampling a known point of interest, a named mob, or a fixed timestamp is the cheapest way to confirm that the world state moved the way the command suggested it did.

Item and inventory commands

Item commands are where the console behaves most like a developer API. Each item has a stable internal name, a stack size, and a quality tier. The community has published a long list of those names, and the most reliable ones are the ones that have shipped across multiple patches without a rename. A grant command typically takes a player identifier, an item name, a quantity, and an optional quality, and the parser is usually strict about capitalization.

For a developer building tooling, the useful discipline is to centralize the item name list in a single source of truth inside the project. A typed table inside the project, rather than a free-form string passed to the console, prevents the most common class of silent failure: the command runs, returns success, and the item simply never appears because the parser could not match the name. The convention below is one we have used on similar projects and works well here.

Keep one file of canonical item names, indexed by an internal identifier.
Wrap each name in a helper that validates it against a hash or checksum before sending it to the console.
Log the exact string sent to the console, so a future regression can be matched to a server log line.
For grant tests, send a single item first and confirm receipt before scaling up to a stack.

The single-item-first habit catches another common failure mode: many item grant commands fail silently if the receiving inventory does not have the slot space. A single grant to an empty slot succeeds even when a batch grant to a partially full inventory would have been rejected, so the test order matters.

Building, terrain, and structure commands

Building commands are the area where the highest amount of irreversible damage is possible. Removing a structure through the console typically writes a removal record to the world save, and the operation cannot be undone by re-issuing a build command, because the underlying object no longer exists in the build list. For a player, this is the difference between a workaround and a setback. For a developer building a stress test, this is the difference between a controlled experiment and a corrupted fixture.

The mitigation is the same in both cases: snapshot the world before any structural command, and treat the snapshot as the source of truth. On a dedicated server, this is usually a tarball of the world directory. On a single-player session, the same idea is implemented by copying the player profile directory before issuing the command. The snapshot is cheap, the rollback is expensive, and the asymmetry is worth internalizing.

Terrain commands are an even more sensitive subset. Forcing a terrain flatten or a biome edge move touches a system that uses a deterministic seed and a quantization grid, and a command that lies about either of those can leave a world that boots but produces visible seams at biome borders. The community has a small set of trusted terrain commands, and any command outside that set should be tested in a throwaway world before it is allowed near a real one.

Server administration commands

Server administration commands sit on the boundary between valheim console commands and a proper server management surface. They include the obvious operations: broadcasting a message, kicking a player, banning an account, saving the world, and stopping the server. They also include the less obvious ones: rotating the admin password, toggling a whitelist, and forcing a backup. On a dedicated server, these are the commands that an operator is expected to know cold, and they are the commands that benefit most from being wrapped in a script.

The reason to wrap them is not convenience. It is reproducibility. A backup command typed by hand on Friday afternoon is not the same as a backup command run by a cron job with a known schedule, a known retention window, and a known exit code. For a developer audience, the most useful pattern is to treat the console as a primitive and the wrapper as the product. The console is unstable across patches. The wrapper, written against the console, can be updated in one place when a patch breaks the contract. In relation to jp software downloads, the jp software downloads adds context without changing the practical guidance here.

Performance and stability considerations

Every command issued through the console has a cost, and the cost is not always obvious. A grant of a single item is essentially free. A broadcast that triggers a UI refresh on every connected client is more expensive, and a forced event that loads every chunk in a region is the most expensive operation available. Issuing a flood of expensive commands from a script is one of the easiest ways to push a Valheim server into a state where the simulation thread falls behind the network thread and the world starts to rubber-band.

From a development perspective, the useful rule of thumb is to assume that any command that touches more than one region is potentially expensive, and to rate-limit such commands to a small number per second. A short list of operational limits that have held up in practice:

One world-wide event trigger per server per minute is usually safe.
One region-wide weather change per region per thirty seconds is usually safe.
Item grants should be batched by player rather than by item, to avoid repeated inventory writes.
Saves should be issued manually, not on a tight schedule, because the save itself is a stop-the-world operation.

The numbers above are not official, because no official numbers exist. They are a starting point, and any team operating a serious dedicated server should profile their own instance and replace the defaults with measured values.

Versioning, patches, and the cost of breakage

Valheim’s debug surface is not a stable API, and any tooling built on top of it has to accept that reality. Iron Gate ships balance patches, content patches, and engine upgrades, and each of those can change the behavior of a command in ways that are not announced. The most resilient teams treat the console as a moving target, and they build their tooling with two simple guarantees: a regression test that runs on every game patch, and a feature flag that can disable any console-driven path when the underlying command breaks.

For a player who is not building tooling, the practical version of the same advice is to read the patch notes for any major update and to check the community-maintained command lists for changes. For a developer, the discipline is to keep a record of which commands were tested against which patch, and to update that record every time a new patch ships. The record does not need to be elaborate. A simple spreadsheet with the command, the version, and a pass or fail column is enough to catch the silent failures that would otherwise show up in production.

Security, privilege, and shared worlds

The console has real privilege implications, especially on a shared world. A player who can open the console can grant themselves any item, teleport anywhere, and in some configurations remove other players’ structures. For a single-player world, that is the design intent. For a hosted world with friends, it is a social contract, and the technical answer is to lock the console behind an admin password or to require that the console be opened through a launch argument that only the host knows.

For a server exposed to the public, the same logic applies more sharply. A public console is an open door, and the standard mitigation is to run the server without a console attached and to drive it through a remote administration script that requires its own authentication. The principle is the same as for any other privileged surface: minimize the attack surface, log every privileged action, and assume that any capability that is reachable from a public network will eventually be reached.

How console commands compare to mod commands

For a developer audience, the most useful comparison is between stock console commands and the commands that BepInEx mods expose. The two surfaces look similar from the outside, but the engineering behind them is different, and the trade-offs are real.

Dimension	Stock console	Modded console
Stability across patches	Low; undocumented, can change without notice	Medium; tied to mod versioning, but more predictable
Documentation	Community-maintained lists	Per-mod documentation, usually maintained by the author
Customization	None; commands are fixed	High; mods can register new commands at will
Risk to world data	Medium to high, depending on command	Medium; depends on the mod’s quality and its handling of persistence
Performance ceiling	Limited by the surface Iron Gate exposes	Limited by the mod’s implementation and the host’s CPU budget

The right answer for most developer projects is to use the modded console as the primary surface, and to keep the stock console as a fallback for environments where BepInEx is not available. The risk profile is similar, but the modded surface is more controllable, and the documentation is closer to the implementation.

A safe workflow for repeatable console work

For teams that use valheim console commands as part of a regular workflow, a documented procedure is more valuable than a memorized list. The procedure below is a starting point that has worked on similar Unity projects and adapts well to Valheim.

Decide whether the work belongs in a throwaway test world or in a live world. If in doubt, use a throwaway world.
Snapshot the world directory before any state-changing command.
Issue a single command, then validate the visible effect before issuing the next.
Log the exact command string, the timestamp, and the issuing account, in a format that can be searched later.
After the workflow is complete, validate the world by walking it in a test client, then close the console.
If the world will be reused, take a final snapshot and store it in the same place as the previous one.

The discipline is the same as for any other privileged surface in a live system: minimize, log, validate, and snapshot. Teams that adopt the discipline early recover faster from the inevitable command that misbehaves, and the recovery story is part of the product even when the product is a private world.

When not to use the console

There are real cases where the console is the wrong tool. Any workflow that needs to run unattended, at scale, or across many worlds is better served by a proper server management tool. Any workflow that needs to be reproducible across teams is better served by a mod with a versioned API. Any workflow that needs to be auditable is better served by a logging layer that the console cannot provide. The console is a powerful escape hatch, and escape hatches are best used as escape hatches rather than as primary infrastructure.

For player-facing support, the same principle applies in a softer form. The console can solve a problem that the gameplay loop cannot, but it should not be the first answer, because the gameplay loop is the part of the product that the player paid for. A team that reaches for the console on every support ticket is signaling that the gameplay loop is not delivering the experience it was designed to deliver, and that is a design problem, not a tooling problem.

Working with the wider Valheim toolchain

For developers who want a deeper understanding of how the console fits into Valheim’s broader architecture, it is worth looking at the tools the studio uses in adjacent areas. The video game development process behind a survival title like Valheim is built on a toolchain of debug surfaces, scripting layers, and modding hooks, and the same patterns show up across the genre. For readers who are interested in how command-line tools shape the developer experience in other software categories, a useful comparison point is the Take Command Console, a long-running commercial command processor that has shaped how developers think about interactive shells. A second useful reference is the modern distribution and download experience that the same team provides, which is documented on the jp software downloads page and is a clean example of how a mature toolchain presents its build artifacts to its users. None of these are Valheim itself, but the engineering problems are close enough that the comparisons are useful.

Frequently asked questions

How do I open the Valheim console in the first place?

The most common path is to add a launch argument such as -console to the game executable or to the platform client’s launch options, restart the client, and then press the configured hotkey once a world is loaded. On a dedicated server, the console is typically attached to the server process itself, and operators send commands through a remote session or a wrapper script. If the console does not appear, the launch option is usually the first place to look, because a stray space or quote will silently disable the flag.

Are valheim console commands safe for an existing world?

They are as safe as the commands you issue. Read-only commands are essentially free. Player state commands are usually safe but can be reset by other systems if they are written through the wrong subsystem. World, building, and terrain commands are the most dangerous, and a snapshot of the world directory is the standard mitigation. A practical rule is to treat any command that mutates world or building state as a command that deserves a backup before it runs.

Do console commands work on a dedicated server?

Yes, but the surface is different from the single-player client. On a self-hosted dedicated server, the operator connects to the server console and issues commands that apply to the world state directly. Client-side commands that work in a single-player session are not always available on a remote server, and a few commands are available only on the server. For repeatable work, a wrapper script around the server console is usually more useful than typing commands by hand.

Will my commands be wiped by a patch?

No, because the commands are not stored on disk. The world save can be affected by a patch, especially if a command wrote state that the new patch interprets differently, but the commands themselves are not stored. The risk to your world is that a patch changes the meaning of a state value that a command wrote, not that a patch erases a command history. A backup before any major patch is still a good habit.

Can I script the console?

On a dedicated server, yes, and scripting is the recommended pattern for any workflow that runs more than once. On a single-player client, scripting is possible through a BepInEx mod that registers its own commands and listens for console input, but the surface is thinner and the tooling is less mature. For any project that will outlive a single patch cycle, a wrapper script with its own logging is the most resilient approach.

What’s the difference between the stock console and a BepInEx console?

The stock console is the debug surface that Iron Gate exposes in the official build. It is undocumented and can change without notice. A BepInEx console is a mod loader that registers additional commands and provides a more stable scripting layer. For developer tooling, the BepInEx surface is usually the better target, and the stock console is best treated as a fallback.

Do console commands disable achievements?

Valheim’s official policy on achievements and console use has changed over time, and the safe assumption is that any session that uses the console may be flagged for achievement eligibility depending on the platform and the current patch. If achievements matter to you, the cleanest answer is to keep a separate single-player profile for console work and a separate profile for the achievement run, rather than mixing the two on the same character.

How do I recover a world after a bad command?

The fastest recovery path is a snapshot of the world directory taken before the command was issued. If no snapshot exists, the next-best option is a backup from the dedicated server’s scheduled save, if one is configured. If neither is available, the world may be partially recoverable through a fresh load followed by targeted re-grants, but the structural part of the world is usually the part that is hardest to put back. The cheapest insurance is a snapshot taken before any structural command, every time.

Valheim console commands: a developer and modder reference