eysp/portainer-ce packages Portainer CE as a Chinese localised Docker image

What this repository is: a localised image build, not the Portainer project

The repository description is the clearest signal of what you are looking at. It describes portainer-ce as a Chinese localised Docker image for version 2.33.x, supporting X86, ARM, ARM64 and Windows, and the homepage points to a Docker Hub repository at hub.docker.com/r/6053537/portainer-ce rather than to portainer.io. That is the artefact you get: an image, not a contribution path into the upstream project. The README tells a different story, because it is the upstream Portainer README. It describes Portainer CE as a lightweight universal management GUI for Docker, Swarm, Kubernetes and ACI environments, and it links to the upstream issue tracker on github.com/portainer/portainer, the upstream Slack and community channels, and the upstream security mailbox. At the end, the README adds a Chinese sponsorship note crediting ZMTO for providing compute resources through its open source VPS programme. So the tree is a full upstream checkout with a localisation layer and a build pipeline on top. The top level entries confirm it, with api/, app/, build/, distribution/, a build.sh script, gruntfile.js, webpack.config.js, extensions.json and pay/ directories, plus a docker-compose.pull-dog.yml file. For a reader deciding whether to depend on this repository, the distinction matters. Depending on the Docker image is one decision. Depending on the source tree as your Portainer fork point is a different one, and the documentation in the tree will mislead you on version numbers and licensing.

The upstream engine underneath: one container managing four orchestrators

Understanding what Portainer does helps you decide whether the localised image is worth using at all. The upstream description is that Portainer consists of a single container that can run on any cluster, and can be deployed as a Linux container or as a Windows native container. The same container image serving a Docker host, a Swarm cluster, a Kubernetes cluster and an Azure ACI environment is the reason the upstream project calls it universal. The interface exposes orchestrator resources directly: containers, images, volumes, networks and more. The audience is operators and platform engineers who need to see and change the state of running containers without going to a command line on each host. Two deployment facts from the README are worth keeping in mind. A fully supported commercial version exists for business use, while the community edition is supported by the community through the issue tracker and Slack. And the project supports only the current and previous two Docker versions, with earlier versions possibly operating but not supported. That last point is the real constraint for a container management UI. Portainer sits next to the Docker API, so a Docker API change is a Portainer compatibility question, and the answer is that you should track the Docker version your fleet actually runs.

The build pipeline is upstream Grunt and webpack, plus a Go server bundle

The package.json in this tree is upstream Portainer's, versioned 2.9.1, authored by Portainer.io, and it describes a JavaScript front end and a Go server compiled together.

{
  "author": "Portainer.io",
  "name": "portainer",
  "homepage": "http://portainer.io",
  "version": "2.9.1",
}

The scripts show the shape of a build. The client is compiled with webpack, and the server is a Go binary produced with CGO disabled.

"build:server:offline": "cd ./api/cmd/portainer && CGO_ENABLED=0 go build --installsuffix cgo --ldflags '-s' && mv -f portainer ../../../dist/portainer",
"dev:client": "grunt clean:client && webpack-dev-server --config=./webpack/webpack.develop.js",
"format": "prettier --loglevel warn --write \"**/*.{js,css,html}\"",

There is a separate documentation step, which installs the swaggo/swag command pinned at v1.7.1 and runs it over the api directory to generate the API reference.

"prebuild:docs": "go install github.com/swaggo/swag/cmd/[email protected]",
"build:docs": "cd api && swag init -g ./http/handler/handler.go --parseDependency --parseInternal --parseDepth 2 --markdownFiles ./",

The dependency list in the tree includes the Swagger tooling, and the file structure shows both a Go server under api/ and a JavaScript client under app/. The presence of build.sh and distribution/ at the root is what makes this a fork whose product is a distributable container image rather than a source library.

Running it: the upstream quickstart, plus a demo you can try first

The README does not contain a docker run command or a compose snippet, so there is nothing to copy here. Instead it points at the upstream deployment guide at documentation.portainer.io/quickstart/, which is where the install steps live, and at the general documentation site. The repository does publish a Docker Hub image, at hub.docker.com/r/6053537/portainer-ce, and the release list here shows two tagged lines: 2.33.x-LTS dated 2025-11-06 and 2.27.x dated 2025-07-15. Those names are the tags to choose between, and the LTS suffix on the newer one is the one to prefer for a deployment you intend to keep running. Before touching your own cluster there is a public demo. The README gives the address at demo.portainer.io with the username admin and the password tryportainer, and it warns that the public demo cluster is reset every 15 minutes. That is a fair way to see the interface, but a fifteen minute reset also means it is useless for evaluating anything involving persistence. The upstream project states that Portainer CE is updated regularly and that it aims to do an update release every couple of months.

Two licence statements that do not agree

This is the sharpest defect in the tree, and it deserves more than a footnote. The README says Portainer is licensed under the zlib license, pointing at the LICENSE file, and it then carries a second heading reading Apache License 2.0 pointing at the same file. The package.json agrees with the first statement, declaring the licence type as Zlib. The repository licence field, meanwhile, says Apache-2.0.

"licenses": [
  {
    "type": "Zlib",
    "url": "https://raw.githubusercontent.com/portainer/portainer/develop/LICENSE"
  }
],

Upstream Portainer is zlib licensed, and the package.json and the first README statement reflect that. The Apache-2.0 value in the repository licence field appears to be a local modification, and the second README heading looks like an attempt to align with it without removing the original text. None of this is legal advice, but the practical point is simple: read the LICENSE file that the build actually ships rather than trusting any single metadata field. A localised image adds translation strings to the client bundle, and who owns those strings is a separate question from the licence of the upstream code.

Version numbers in the README disagree with the version this fork ships

The README states that the latest version of Portainer is 2.6.x, and explains that Portainer is on version 2 with the second number denoting the month of release. The release list of this repository says something different: 2.33.x-LTS from 2025-11-06 and 2.27.x from 2025-07-15. The package.json in the tree says 2.9.1. Three numbers, three different points in the history of the same project, none of them describing the image this repository actually publishes. This is the practical cost of a fork whose documentation was not updated. Anyone reading the README to answer the question what version is this will get it wrong, and the mistake is easy to make because the README looks authoritative and the version section reads like current information. The repository itself is not archived and the last push was on 2026-10-11, so work on the fork continues even though the published image tags stop at November 2025 for the LTS line. Check the Docker Hub tags against the release list in this repository before pinning anything, and treat the README as upstream documentation rather than as a description of this image. Other details in the README are equally upstream: the Matomo analytics disclosure, with a choice to disable analytics at first start and a claim that no personally identifiable information is sent or stored, and the responsible disclosure process with reports going to [email protected]. Both apply to upstream Portainer. Whether the localised image keeps that behaviour is a question for whoever publishes it.

Editorial conclusion

Adopt eysp/portainer-ce when you run a Chinese language Portainer CE deployment and want a prebuilt image rather than the upstream container. Do not adopt it as a source of Portainer development, because the documentation, the version numbers and the licence statements in this tree still describe upstream Portainer rather than this fork. Before pulling the image, confirm the tag you intend to use against the release list in this repository, and check which of the two licence statements, zlib in the README and Apache-2.0 in the repository licence field, applies to the code you are actually shipping.

Frequently asked questions

Official sources

1. eysp/portainer-ce on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases