# dst-admin-go wraps a Don't Starve Together server in a web panel

> dst-admin-go is a Go web panel for Don't Starve Together servers, handling room and world configuration, mod management, save backups, player lists and log collection from a browser. It ships as a single binary for Linux and Windows and needs only a small config file to start.

**carrot-hu23/dst-admin-go** — Don't Starve Together server panel. Manage room with ease, featuring visual world and mod management, player log collection。饥荒联机服务器面板。轻松管理房间，支持可视化的世界和模组管理，玩家日志采集

- Repository: https://github.com/carrot-hu23/dst-admin-go
- Stars: 922 · Forks: 134
- Language: Go
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/carrot-hu23-dst-admin-go

## One binary, a browser, and a directory with write permission

dst-admin-go is a server management panel for Don't Starve Together, written in Go, presented as a modern web interface. The README lists its selling points as simple deployment, low resource use, a clean interface and a full feature set.

The deployment claim is the one to test first, because it is the one that decides whether you can use the panel at all. The panel is a single executable file with no complicated configuration, and the README adds one operational requirement in bold: the directory must have read and write permission. That is not a detail about hosting. It means the panel manages the game's own files in place, writing cluster configuration, world saves and mod directories directly into the tree it points at.

The startup configuration is three keys, and the repository ships a config.yml with them filled in at their defaults.

```yaml
bindAddress: ""
port: 8082
database: dst-db
```

bindAddress is empty in the shipped file, port is 8082, and database names the SQLite file the panel keeps its own state in. The comments are in Chinese in the original file, marking them as the bind address, the startup port and the database.

Because the port is fixed at 8082 by default and the bind address is empty, the sensible question before exposing anything is what the empty bind address means on the host, since that decides whether the panel is reachable from outside the machine. The README does not document the semantics of that field beyond labelling it.

The repository layout confirms the shape of the thing. There is a cmd/ directory holding the server entry point, internal/ for the application code, static/ for frontend assets, docs/ for images and documentation, scripts/ for the packaging helpers, and multi-language READMEs in English, Chinese and Spanish, which tells you the project has users beyond the author.

## Running from source with go run, and the Go versions it expects

The run instructions are two commands, and they are aimed at someone who has Go installed rather than someone who downloaded a release.

```bash
go mod tidy
go run cmd/server/main.go
```

go mod tidy resolves the dependency graph from the module file, and go run compiles and starts the entry point at cmd/server/main.go, which is the same path used by the packaging scripts. So the source route and the binary route produce the same program.

The module file states the toolchain requirement precisely. The module is named dst-admin-go, it declares go 1.23.0 as its language version, and it pins a toolchain directive of go1.24.7.

```go
module dst-admin-go

go 1.23.0

toolchain go1.24.7
```

That combination has a practical consequence worth understanding before you hit a confusing error. The go directive states the minimum language version, and the toolchain directive asks the go command to use that specific toolchain if it is available, downloading it if necessary. A machine with an older Go installation will therefore try to fetch go1.24.7 rather than failing outright, which needs network access on the build machine.

The dependency list is what a web panel in Go looks like. gin-gonic/gin is the HTTP framework, with gin-contrib/sessions for session handling and gin-contrib/gzip and sse alongside it. glebarez/sqlite is a pure Go SQLite driver, used with gorm.io/gorm as the ORM. robfig/cron/v3 provides scheduled jobs, which is how periodic tasks such as update detection fit in. hpcloud/tail is for following log files, and shirou/gopsutil for process and system information. The swaggo packages generate and serve Swagger documentation for the HTTP API, and yuin/gopher-lua embeds a Lua interpreter, which is worth noting given that the game server itself is driven by Lua.

## Packaging for Linux and Windows, including cross-compiling from cmd

The build scripts produce a single file per platform, and the README documents three ways to get one.

On Linux the helper script builds the binary.

```bash
bash scripts/build_linux.sh
```

On Windows the equivalent script produces the executable.

```bash
bash scripts/build_window.sh
```

The third route is cross-compiling a Linux binary from a Windows machine, done in cmd with the environment variables set first.

```bash
set GOARCH=amd64
set GOOS=linux
go build -o dst-admin-go cmd/server/main.go
```

That last form is plain Go tooling rather than a project script, which is a good sign for a build that is not doing anything unusual. Setting GOOS and GOARCH and running go build with an output name is the standard way to produce a cross-compiled binary, and it explains why the project can claim support for both Windows and Linux from a single codebase.

The version note in the README is worth reading closely, because it is the one place where the project names its own compatibility boundary. The panel supports Windows and Linux platforms, but Windows Server low version systems should use a version before 1.2.8, while higher version systems use the latest version. The split is at 1.2.8 specifically, which suggests an operating system API or platform difference that the newer build relies on.

So the deployment story is: build or download one binary, put it next to the game installation, point config.yml at the right database and port, and make sure the directory is writable. Everything else happens in the browser.

## What the panel actually manages: clusters, worlds, mods, saves and players

The feature list in the README is what a server operator would actually want, and it is worth separating the categories because they need different parts of the game installation.

Room and world configuration is first. The panel offers visual configuration of game room and world parameters, and it supports unified management of multiple clusters and worlds. Multi-cluster support is the feature that separates this from a single-server script, since a Don't Starve Together cluster is a set of shard processes sharing a shard configuration, and running several of them is normal for a community server.

Mod management comes next. Mods can be managed and configured online, which in practice means the panel writes into the mod configuration of the cluster rather than asking an administrator to edit files by hand.

Save handling is the third group. The panel offers game save backup and snapshot restore, which is the feature that most changes how you run a server, because it moves the backup job out of a cron script and into the same interface.

Player administration covers whitelist, blacklist and administrator lists. The README's preview images include dedicated screenshots for the player view and for the lobby.

Logging and control come last: real-time log viewing, a game console, and automatic update detection for the game server. The preview screenshots in the repository include one named playerlog, which indicates a dedicated view for collected player logs rather than only the raw server log stream.

What none of this implies is any guarantee about game server internals, because the panel's own documentation is separate. The README links to deployment documentation hosted on GitHub Pages, and the preview of the interface is hosted at dst-admin-go-preview, so both the docs and a visual preview are available before you install anything.

## Where dst-admin-go is the wrong tool

The clearest boundary is hosting. The panel manages files in a directory it can write to, so it needs the game's own installation on a machine you control, with filesystem access. On a hosted Don't Starve Together service where the provider gives you a panel of your own and no shell, this tool has nothing to attach to.

The second boundary is the operating system. Windows Server low version systems are directed to a build from before 1.2.8, so if your host is on an older Windows Server you are running a different, frozen version of the panel with whatever features it had at the time rather than the current feature set.

The third boundary is scope. This is a panel for one game. If you run several different game servers, you are running several panels, each with its own database file, its own port and its own directory to keep writable. The README points at a newer sibling project for another game, the Terraria panel, which suggests the author works this way deliberately rather than building one console for all servers.

A fourth, quieter limit is the dependency on a Lua runtime inside the panel itself. gopher-lua is embedded in the dependency list, which means the Go binary carries a Lua interpreter. That is the sensible way to talk to a game whose server logic is Lua, but it also means the panel is executing game logic, and a server whose mod set includes a Lua error is a scenario the README does not discuss.

The licence is GPL-3.0. For a panel that reads and writes files in your own game directory, the practical effect is on redistribution rather than on use, but it is the licence to check before you fork it into a hosted product.

## How it differs from the author's Terraria panel

The README itself names the alternative, a newer project from the same author called terraria-panel-app, and describes it as supporting Windows and Linux with one-click startup and a built-in version 1449. That difference in approach is the point.

dst-admin-go is delivered as a Go program you compile or download and run against a game directory you already have. The Terraria panel is described as a one-click start that bundles the game version itself, so the panel and the game arrive together rather than the panel attaching to an installation you set up.

For a Don't Starve Together operator, that distinction decides the workflow. The dst-admin-go route assumes the game server exists and that you understand its directory layout, because the panel is editing cluster and world files in place. The one-click route assumes none of that and carries the game with it.

The practical trade is between control and convenience. The dst-admin-go model gives you a panel that works against your own installation and your own cluster layout, which is what you want when a server has been running for a while and its configuration is settled. The bundled model is faster to start from zero but takes over the version of the game you get.

Both are the same author's approach to the same problem, so the design language is similar: a Go binary, a web interface, a local database file, and a deployment that expects filesystem access. The difference is in what you are expected to already have.

## Release cadence, the licence, and what the README advertises

The release history is regular. Version 1.6.1 was released on 2026-02-16, 1.5.3 on 2025-12-16 and 1.5.1 on 2025-07-16, and the last push to the repository was on 2026-08-27. The repository is not archived, so work has continued in the tree since the last tagged release, and the gap between the 2026-02-16 release and the 2026-08-27 push is the normal shape of a project that ships when it is ready.

The licence field on the repository says GPL-3.0, and the repository carries a LICENSE file at the root. The panel is distributed as a binary, and the code is open, which means the practical question for an operator who wants to change behaviour is whether their modification is something they are willing to publish under the same terms.

One presentational note, since the README is the primary document you will read. The project description on the repository is bilingual, giving the English line and the Chinese one, and the README includes a section offering advertising space with a contact address. There is also a link to a cloud hosting promotion. None of that affects the software, but it does tell you the project is run by an individual with commercial interests attached, which is normal for a game server panel and is worth keeping in mind when you judge how features are prioritised.

The documentation split is what a new user should start with. The README links deployment documentation on GitHub Pages, and a preview of the interface at dst-admin-go-preview, plus screenshot images for the dashboard, panel, player view, home, level, mod management, player log and lobby screens. The panel, the world, the mod and the log screenshots are the fastest way to judge whether the interface matches what you currently manage by hand.

## Conclusion

Adopt dst-admin-go if you run one or more Don't Starve Together servers on your own hardware and want cluster, world, mod and player administration in a browser instead of editing server files by hand. Do not adopt it if you are on an older Windows Server release, where the README directs you to a version before 1.2.8, or if your hosting provider gives you no filesystem access, since the panel needs write permission on its directory. Before deploying, edit config.yml with your bindAddress and port, confirm the directory has read and write permission as the README insists, and check whether version 1.6.1 from 2026-02-16 matches the features you need.

## FAQ

### How do I run dst-admin-go?

Edit config.yml with your bind address, port and database, make sure the directory has read and write permission, then run go mod tidy and go run cmd/server/main.go from the source. Prebuilt binaries are produced by scripts/build_linux.sh and scripts/build_window.sh.

### What does dst-admin-go let me manage?

Visual configuration of game room and world parameters, online management and configuration of mods, unified management of multiple clusters and worlds, game save backup and snapshot restore, player management for whitelist, blacklist and administrators, real-time log viewing with a game console, and automatic update detection for the game server.

### Does dst-admin-go work on Windows Server?

The README states that Windows Server low version systems should use a version before 1.2.8, while higher version systems should use the latest version. The project supports Windows and Linux platforms.

### What does dst-admin-go need from the host?

The README states that the directory must have read and write permission. The panel manages the game's own files in place, including cluster configuration, worlds, saves and mods.

### Which Go version does dst-admin-go need?

The module file declares go 1.23.0 and a toolchain directive of go1.24.7, so the go command will fetch that toolchain if the machine does not already have it.

### What licence is dst-admin-go released under?

GPL-3.0, according to the licence field on the repository and the LICENSE file at the repository root.

## Sources

- [carrot-hu23/dst-admin-go on GitHub](https://github.com/carrot-hu23/dst-admin-go)
- [Issues](https://github.com/carrot-hu23/dst-admin-go/issues)
- [License: GPL-3.0](https://github.com/carrot-hu23/dst-admin-go/blob/main/LICENSE)
- [README](https://github.com/carrot-hu23/dst-admin-go/blob/main/README.md)
- [Releases](https://github.com/carrot-hu23/dst-admin-go/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/carrot-hu23-dst-admin-go