mayfly-go, an operations console that spans terminals, files and eleven databases

Terminal, files, scripts, processes, tasks, and then eleven databases

The scope statement is dense and it is best read as two halves with a different character.

The first half is Linux system operation, described as comprehensive, and the list is specific: terminal management including terminal replay and command filtering, file management, script execution, process monitoring, and scheduled task configuration. That is a complete remote operations surface for a single host, and the two parenthetical features are the ones that distinguish it from a plain web terminal.

Terminal replay records what happened in a session so it can be reviewed afterwards, which matters for two different reasons. Operationally it is an audit trail for a tool that hands out shell access. Legally it is evidence, in a regulated environment where the question who ran that command and what did it return is a question someone will ask. A tool that records sessions by default is making a different assumption about its users than one that does not.

Command filtering is the other feature, and it is more interesting because it is the security control rather than the evidence. A filtered terminal is one where a user can type anything except a configured set of patterns, which is how you let an operations team do routine work on production without letting a typo become an outage. The cost is that the filter is a denylist or an allowlist of patterns matched against text, so it is bypassable by anything that expresses the same operation differently, and it cannot prevent a legitimate command from having a legitimate bad effect. The README does not describe the matching semantics, which is exactly the detail an evaluator needs and the one that is missing.

The second half is data operations, and the database list is the real content of this project. Relational: MySQL, PostgreSQL, Oracle, SQL Server, Dameng, Gauss, SQLite and ClickHouse. Non-relational: MongoDB, Redis, Elasticsearch and Milvus. Twelve engines, which is far more than an operations console needs, and the two Chinese engines among them explain why.

Dameng and Gauss are domestic Chinese database products, and their presence alongside Oracle and SQL Server tells you this project was built for organisations that run Chinese database engines and cannot use a tool that only speaks MySQL. A tool that connects to Gauss is a tool written by people who work in that environment, and that context also explains the mirror choices and the sponsor block later in this article.

Redis with modes, and why Elasticsearch and a vector database are in the same tool

The repository description names Redis in three forms, and the detail is more useful than the rest of the list.

The description says Redis standalone, sentinel and cluster, in that order. Those are the three deployment topologies Redis actually has, and they are not variations on a theme. A standalone Redis is one process and a port. Sentinel is a failover arrangement with sentinels monitoring a master and promoting a replica. Cluster is a sharded arrangement with a hash slot model and a different client protocol, including redirection on cross-slot operations.

A Redis administration tool that handles only standalone is a key browser. One that handles cluster has to deal with slot addressing, and a tool that handles sentinel has to show you which node is currently the master. Saying all three in a comma-separated phrase in a repository description is a claim about coverage, and the README's screenshots section confirms a Redis operations view exists. The screenshot list is the real evidence: home page, a resource tree, terminal operations, file operations, file viewing, an SQL editor, table selection and data browsing, Redis operations, Mongo operations, Elasticsearch operations, container operations, approval workflow, and then the three system-management screens for accounts, roles and menu resources.

That last group of three tells you the permission model. Accounts, roles, and menu resources. Menu resources are the interesting one, because it means authorisation is expressed as which interface elements a user can see, not only as what the server will let them do. That is a common and imperfect pattern: a hidden button is a usability decision, not a security control, and any implementation of a menu-based permission system has to pair it with a server-side check. The presence of a separate roles screen suggests the two are distinct concepts, but the README does not describe how they interact.

Elasticsearch and Milvus in the same tool is worth a moment. Elasticsearch and a vector database are both search systems, and neither is a database in the sense the other entries are. Including Milvus means the operations console also covers retrieval infrastructure, which is a coherent direction: a team running a search-based product has two search systems to watch, and one console for both is genuinely useful. It also means the console is one step further from being a general-purpose admin panel and closer to a product operations surface.

Container operations appear in the screenshot list too, though not in the description. So the tool covers host, container and data, which is the scope of a small platform team's entire job.

The approval workflow, and what a web terminal inherits

There is a feature in the description that deserves its own section because it is the control that makes the rest of this defensible: work-order approval flow.

The idea is straightforward and it is the correct answer to the problem this tool creates. A system that gives a browser a terminal on your production hosts is a very large privilege to hand out, and the standard mitigations are all partial. Network segmentation helps. Short-lived credentials help. Neither stops a person who is authorised from running a destructive command at the wrong moment, and neither leaves a record.

An approval workflow addresses the second problem directly. A user requests an operation, someone else authorises it, the operation runs inside a scope that can be bounded, and there is a record. It is the same pattern as a database change management system, and it works for the same reason: the person who knows whether this particular operation is safe at this particular moment is rarely the person who needs it done right now.

The screenshots confirm both halves exist, with a dedicated flow approval screen alongside the terminal and file screens, which means the approval is a first-class workflow rather than a checkbox.

What the README does not say is who can approve. That single question determines whether the feature works. A workflow where an administrator can approve their own request has added a screen and no control. A workflow where approval is separated by role has added a genuine second pair of eyes. Given that the system administration screens include a roles screen, separation is possible, and given that most single-administrator deployments will have one account, it is also likely to be switched off in practice. An evaluator should establish this before relying on it, which is why it belongs in the conclusion rather than in a feature list.

The deeper point is about what a web terminal inherits. This is not a tool that can be deployed casually, because the blast radius of a compromise is every host and every database engine you have configured, including the ones holding credentials. The platform deserves the same caution as any bastion host, and the approval workflow is the feature that makes it closer to one.

Three mirrors, a Tencent image, and an Alpine image fetched through a Chinese hub

The repository layout answers the question of who this is for more clearly than any documentation would.

The project is mirrored in three places. There is a Gitee repository, and there is a GitCode repository, and there is the GitHub one you are reading. The badge block in the README links star and fork counters from all three, and the sponsorship section asks for stars on all three. Gitee and GitCode are Chinese code hosting platforms, and mirroring onto both rather than one is an unusual level of commitment to a domestic audience.

The Docker Compose file uses an image from a Tencent container registry, and the default database image is MySQL 8 with a root password in plaintext in the file. The application image has both an image line and a build section, so a user is expected to be able to switch between pulling the published image and building it, and the registry is not Docker Hub.

The Dockerfile is the most revealing file in the repository, because it does not build anything. Its first stage downloads a release zip from a Gitee releases URL, using a build argument for the version and a build argument for the target architecture, unpacks it, and moves the result. The second stage copies the prebuilt binary out of the builder stage into a fresh Alpine image and runs it. There is no Go toolchain in the image and no compilation step, which means the published image ships a binary that somebody built on a build machine, and the only guarantee available to you is the integrity of that download at build time.

That is a reasonable way to keep an image small, since compiling a Go binary and then copying it into a scratch-ish base is faster and produces a smaller result than building inside the image. It is also a supply chain decision worth naming. The base image is pulled from a Chinese mirror of Docker Hub with a pinned Alpine version as the default, the release artefact comes from a mirror, and the application binary was compiled somewhere else. Three external points of trust before your server starts, none of them visible from the repository's own contents.

There is a second Dockerfile, named for source builds, which presumably does compile. Having both is the right structure: the small fast path for users, the reproducible path for anyone who does not want to trust a prebuilt binary. The Makefile has a Docker target and a CLI build target, and the CLI is a separate Go module in its own directory.

The demo environment, published with its credentials

The README publishes a demo environment address and a username and password for it, and this deserves a paragraph rather than a passing mention.

The demo is at a public hostname, and the credentials are given in the text as a short pair. The account is a test account with a trivial password. The instance is running the current release, and anyone can log in.

For a demo of an operations console this is more than a mild risk, because of what the tool does. A user who logs into a shared demo is looking at a resource tree, and the question is what that tree contains. A well-run demo has one or two throwaway hosts attached and a database with fake data, and a poorly run one has a connection to something real. There is no way to tell from the outside, and the people best placed to know are the people who set it up.

The pattern is common in Chinese open source projects and it is not a criticism of this one specifically. Demo instances are how a user evaluates a tool before installing it, and for a tool that requires eleven database engines and a fleet of Linux hosts to be worth anything, a demo is the only practical way to see it work. The credential being published is the correct trade for a demo and the wrong default for a deployment.

So the operational advice follows directly from the design. The port is eighteen thousand eight hundred and eighty-eight, published in the Compose file and exposed in the Dockerfile. Anyone deploying this should treat the console as a privileged internal service: behind a VPN or an authenticating proxy, with the platform's own login, on a network segment that is not reachable from the general corporate one. The account and role screens are the mechanism for control once it is reachable, and the approval workflow is the mechanism for control of individual operations, but neither of those is a substitute for the network position.

It is also worth noting what is in the repository that helps with this. There is a configuration file mounted into the container from the server directory, so settings are external to the image and editable, and a wait-hosts environment variable that makes the application wait for the database to be ready, which is the kind of detail that indicates the Compose file has actually been used to start the thing.

Apache-2.0, a maintained cadence, and Go 1.26 with Vue 3

The licence is the Apache License 2.0, which is the permissive grant with an explicit patent clause, and it is the right licence for infrastructure that companies modify. The licence file is at the repository root.

The maintenance record is the healthiest in this group of projects. Three releases in a six-week window, v1.11.3 in May 2026, v1.11.4 in early June and v1.11.5 later that month, with the last push on 2026-09-27. Patch releases inside a minor line, several per quarter, and the repository is not archived. A 1.x version also means there is a compatibility promise, which for a tool that people point at production systems is the property that matters most.

The stack is stated plainly. Go on the back end with the Gin web framework and the GORM ORM, requiring Go 1.26 or later. TypeScript and Vue 3 with Element Plus on the front end. Those are the mainstream choices in their ecosystems, and naming them is useful because it tells you what a contributor is walking into: GORM in particular means the database adapters are built on an ORM rather than on raw drivers, which is efficient for a tool that browses arbitrary tables and less flexible for the operations that need exact control over a statement.

The repository structure is a standard split, with a server directory, a frontend directory, a CLI directory, a docs directory, a Makefile, a build script, a Compose file and two Dockerfiles. There is an agents file at the top level, which in a project of this kind usually means instructions for coding agents working on the repository rather than anything the application reads.

The community channels are also telling. There is a QQ group, which is the primary support channel for most Chinese open source projects, a Yuque documentation site, and a collection of operation videos on a video platform. Video walkthroughs of an operations console are a genuinely good idea, because the questions a new user has are all about where a control is rather than what it does, and a screenshot of the home page answers fewer of those than a two-minute screen recording does.

Editorial conclusion

Adopt mayfly-go for a team that already runs a mix of Linux hosts and database engines and wants one audited console with role-based approval for terminal and file operations, and if you are deploying in China the three mirrors in the repository are a genuine convenience. Do not expose it the way the demo environment is exposed, because it publishes a fixed username and password for an instance that grants terminal access to machines. Verify first by reading the command filtering and terminal playback behaviour before giving anyone access, changing the demo credentials pattern for your own deployment, and checking whether the approval workflow applies to your own account, since an operations console that lets an administrator approve their own terminal sessions has lost the point of the approval screen.

Frequently asked questions

Official sources

1. dromara/mayfly-go on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases