Goploy: a Go web panel for deployment, cron, terminals and server monitoring on one box

One binary that collects a dozen small server tools

Goploy is described as a web deployment system tool, and the name is a contraction of go plus deploy. The pitch in the README is that it supports all kinds of code release and rollback, done through the web with one click, with complete installation instructions and no difficulty in getting started.

The feature list is a list of things that normally each get their own tool:

- Building projects - Support git svn ftp sftp - Deployment across os - RBAC - Monitor http tcp ping process script server - Second cron - Xterm - Sftp - LDAP

That is a very particular combination. A deployment panel, a cron scheduler, a monitoring dashboard, a web terminal, a file transfer client, an identity provider integration and a role system, all in one application with one binary. The list of topics matches, with cicd, deploy, devops, go, golang, nginx, terminal and vue.

The application is Go, with a Vue front end, and the repository root is laid out the way you would expect for that: cmd/ for the entry points, internal/ for the application code, web/ for the front end, config/, database/, docker/, docs/ and a build.sh. The module is github.com/zhenorzz/goploy and the go.mod requires go 1.24.0, which is a recent floor.

The project is GPL-3.0 licensed and the homepage is goploy.icu. The last push was on 2026-08-26 and the releases are v1.18.0 from 2026-07-23, 1.17.5 from 2025-11-05 and 1.17.4 from 2025-02-18.

The README also carries an important note about the branch: the master branch may be in an unstable or unavailable state during development, and you should use releases rather than master to obtain stable binaries. That is a warning to install from a tag, not from a checkout of the default branch.

The default credentials are in the README, and that shapes how you deploy it

The use section is three steps, and the third one contains the detail that every operator needs to see immediately.

Run./goploy, or goploy.exe, or goploy.mac. Then follow the installation guide. Then open the web interface at http://ip:port, with the account and password given as admin:admin!@#.

That default credential is not hidden anywhere, and the same pair is repeated for the demo instance, which is listed as admin:admin!@# with a parenthetical note that it may not be able to open depending on the mood.

The consequence is direct. This is an application that gives shell access and deployment control over servers, and it ships with a published default password. A Goploy instance reachable on a network with its default password is a full compromise of everything it manages, and the fact that the demo instance is openly documented with the same credentials means the combination is not obscure.

The other structural point is the single binary. The go.mod pulls in a MySQL driver, and the emphasis in the README is on one executable and one web port. The front end is compiled into the binary, or served from an asset directory, and the whole thing is a single process listening on an HTTP port.

Three ways to get it are offered. A release binary from the GitHub releases page, a Docker image at zhenorzz/goploy with a Dockerfile in the docker/ directory, or a build from a tag, which the README spells out:

git clone https://github.com/zhenorzz/goploy.git
cd ./goploy
git checkout -b tagname
cd ./web
npm install && npm run build
cd ../
go build -o goploy cmd/server/main.go

The build from tag path is the important one for reproducibility, and it shows the two halves of the project: the front end is built first with npm, and the Go binary is then compiled from cmd/server/main.go.

The dependency list is a map of the feature set

The go.mod is short enough to read as a specification of what the tool does, and every entry corresponds to something on the feature list.

The transfer and version control clients are there directly: github.com/pkg/sftp for the SFTP client, github.com/jlaffaye/ftp for FTP, and the git and svn support is presumably handled by shelling out or by the deployment layer. The Docker client is github.com/docker/docker at v26.1.5, which is the API for the Docker features, and containerd appears as an indirect dependency underneath it.

Identity is handled by two libraries. github.com/go-ldap/ldap/v3 at v3.4.1 is the LDAP client behind the LDAP feature, and Azure's go-ntlmssp appears as an indirect dependency, which is the NTLM protocol for authenticating against an Active Directory or Samba domain controller. The RBAC feature is not a library, it is the application's own table structure, and the role based access control is served by golang-jwt/jwt at v3.2.2 for the tokens.

The monitoring features are visible too. The hashicorp/go-version dependency is a semantic version parser, which is what a version-aware deploy target needs in order to decide whether a release is newer than what is running, and the websocket library github.com/gorilla/websocket is how the front end receives live output from a running task.

Configuration is handled by knadh/koanf, with its TOML parser, its file provider and its structs provider, which fits the goploy.example.toml file at the repository root and the instruction to copy it to goploy.toml. The loader, logrus for logging, and the go-playground validator for form validation, along with its locales and universal-translator packages for the error messages, are the rest of the standard stack.

One entry is worth calling out. github.com/wenlng/go-captcha is a captcha library, which tells you the login screen has a captcha, and that is worth noting next to the default credentials. The statigz dependency is what makes a single binary carrying the front end plausible, since the dependency list is the only evidence in the module file for how the built Vue assets reach the browser.

The satellite repositories are where the project is spreading

The README links four separate repositories, and they tell you more about the project's direction than the feature list does.

There is Goploy-Agent, in the same account, described as monitoring server performance. That is the piece that runs on the machines being managed, rather than the control panel itself, and having a separate agent repository means the monitoring data comes from a process on the target host rather than from a ping out of the control panel.

Then there are three under the goploy-devops account, and they are the interesting ones. Goploy-Vscode, described as searching Goploy in Visual Studio Code. Goploy-Jetbrains, the same for JetBrains. And Goploy-CLI, described as a CLI and MCP server for AI agent deployment.

That last one is the most consequential. An MCP server means a coding agent can drive deployments through Goploy, and that is a meaningful shift in what a deployment tool's interface means. The traditional model is that a human opens a web form, picks a release, watches the output. The MCP route lets an agent select a target, start a release and read the result, which is faster and also much harder to constrain. A team evaluating Goploy for agent-driven deployment has to think about what the agent is allowed to trigger, and the README does not describe any policy layer for that.

The editor plugins put Goploy in the search bar of an IDE, which is a small integration but a telling one. A deployment tool that is reachable from the editor competes with the terminal, and one that is reachable from an AI assistant competes with the terminal more directly still.

There is also a documented OpenAPI endpoint at api-doc.goploy.icu and documentation at docs.goploy.icu, so the project treats its API as a first-class interface rather than only a web form.

The development setup uses gin hot reload and a separate front end build

The backend and frontend sections describe the contributor's setup, and there is one line in the backend section that is worth pausing on.

The backend steps are: install go 1.16 or later, go mod is required, edit goploy.toml by copying goploy.example.toml to goploy.toml, build the front end, then run `cd cmd/server && go run main.go --asset-dir=../../`, and use gin with hot reload.

Two things stand out. The first is the inconsistency in the Go version, where the backend section says go 1.16 and go.mod says go 1.24.0. The module file is what the build actually enforces, so 1.16 in the README is stale text, and a contributor who reads the README and installs Go 1.16 will find the module requirement rejected.

The second is the asset directory flag. Passing --asset-dir points the server at the built front end on disk rather than at whatever assets ship with the binary, which is what makes front end hot reload possible during development.

The front end steps are separate and conventional: cd web, npm install or yarn install, edit.env.development, then npm run dev or yarn dev for development and npm run build or yarn build for a build. The.env.development file is where the front end is told where the API is, and the repository root holds the preview images.

The repository root also has an.air.toml, which is the configuration for air, the Go live reload tool that watches files and restarts the server, a reload.bat for the same on Windows, an AGENTS.md and a CLAUDE.md, and a CHANGELOG.md. The presence of AGENTS.md and CLAUDE.md means the project is set up for coding agents to work in the repository, which is consistent with the MCP server direction.

Where Goploy is the wrong tool

The limits here are mostly about what a web-driven deployment panel can and cannot do, and about the trust model it implies.

The first is the credentials. An application that publishes its default admin password, ships a captcha rather than a stronger authentication story, and provides a web terminal and deployment triggers for your production servers is a high-value target. The LDAP and RBAC features exist to address that, but they are opt-in, and the first thing an operator has to do is change the default. An organisation that cannot accept a web console with server-level privileges on its network should not run this.

The second is that the release mechanics are file operations driven from a form. The feature list says support git svn ftp sftp and deployment across os, and the description says release and rollback with one click, but the README does not describe a pipeline model with stages, gates, artefact promotion, or a deployment log that an auditor would accept. If your process already lives in a CI system, Goploy duplicates part of it without replacing the part that matters, and the useful part of the tool is then only the terminal and the cron manager.

The third is the architecture. One Go binary with a MySQL dependency, a Vue front end and a set of satellite tools is a system that has to be maintained by whoever installs it. There is no cluster mode, no multi-tenant model described, and the demo instance being flaky is a reminder of what a small project's infrastructure looks like. Goploy is a tool for one team running its own servers, and it is not a platform.

The fourth is the front end technology. Vue with a Go backend is a perfectly good combination, but it means two build toolchains and two sets of dependencies for a tool whose value is mostly in its server-side behaviour. The statigz embedding and the Docker image mitigate that, since a released binary needs neither node nor a build step, but a contributor needs both.

The fifth is the master branch warning. The README says the master branch may be in an unstable or unavailable state during development and to use releases instead. That is a sensible instruction and it also means anyone evaluating the project from a checkout is looking at something the author does not recommend running. The releases are the artefact to judge.

The sixth is the agent integration. Goploy-CLI being an MCP server for AI agent deployment is a capability, and it is also a new risk surface, because a deployment tool that an autonomous agent can call has to define what the agent is allowed to do. Nothing in the README describes such a boundary, so a team enabling it is designing that policy themselves.

Editorial conclusion

Goploy is worth adopting for a small team that deploys to a handful of servers and wants one browser tab for release, rollback, scheduled jobs and a terminal, because the single binary and the Docker image make it cheap to try. It is the wrong tool for a platform team with a proper pipeline, since the release mechanics here are file operations driven from a web form, and the wrong tool for a security-sensitive environment, because the default credentials are published and the login is a web form. Before deploying it, change the admin:admin!@# password, decide whether the Docker image or a build from a tag suits you, and read the goploy.example.toml, since the configuration is a file you have to copy before anything starts.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. zhenorzz/goploy on GitHub