BoCloud/FOLib: a repository manager built around supply chain graphs and model hubs

Twenty three package ecosystems, and two things that are not package managers

The list of formats is the sales pitch and it is long. The project describes itself as a full language artefact repository covering npm, Maven, PyPI, Docker, Gradle, SBT, Cocoapods, Swift, RPM, Debian, OPKG, PHP, Go, Pub, Ivy, NuGet, Conda, Cargo, Conan, Yarn, GitLFS, Helm and OHPM, and it counts them as more than twenty three repository types. The repository's own topic tags place it alongside the categories a reader would expect, naming Artifactory, Nexus, Harbor and docker registry, which is a statement of where the maintainers think it belongs rather than a feature list. Two entries break the pattern of a proxy cache, and they are the reason the positioning is different. The first is model repositories, where the project describes proxy and synchronisation for HuggingFace, Ollama and ModelScope, plus private upload of tools and a promotion and distribution path for them, so weights and model artefacts are treated as something the repository manages rather than something you pull from a hub directly. The second is the agent story, where the project claims multi-dimensional graph data across metadata, requirements, services, artefacts, security vulnerabilities and dependency certificates, queryable and displayable, with support for the Model Context Protocol so an AI agent can query and recommend artefacts, propose remediation for vulnerabilities and drive the promotion flow. Neither of those is a package format. Both are attempts to make the repository a system of record about what your software is made of, and they are the features to interrogate, because a cache can be rebuilt and a graph cannot.

Fourteen Maven modules, and what the names imply about the design

The top-level file list is a Maven reactor with fourteen named modules, and reading the names is a reasonable way to infer the architecture without a design document. There is an API module, a core module, a commons module, a configuration module, a storage module, a security module, a job module and an event API module, which between them suggest a service with its own scheduling and its own event layer rather than a single web application. Two names are more informative than the rest. One is a gremlin service module, and Gremlin is the traversal language of a property graph, so the multi-dimensional graph the README describes is backed by a graph store rather than by relational tables with a graph query bolted on, which is a defensible choice for a supply chain graph where the interesting query is a path. The other is the web layer, split into a web core module and a web Vue module, so the interface is a single page application talking to a separate API rather than server rendered pages. The build module produces the distributable tarball the virtual machine instructions tell you to unpack, the package script sits at the root for building a release, and there is a root Maven settings file for the build's own dependency resolution. Two more files are worth a look for a project that proxies other people's software. There is a licence header template and a document titled as a licence compliance explanation, which together suggest the project treats licence reporting over proxied artefacts as part of the product rather than as an afterthought. The readme exists in English and Chinese, with the English version as a separate file, and the project is mirrored onto a second Git host.

The container command publishes six ports, runs privileged, and points at itself

The container deployment is the first documented path, and it is worth reading line by line because it contains the kind of detail that decides whether your first hour goes well. MySQL has to exist first, the directory is created, and then the server is started with a long run command. Two things in it deserve comment. The first is the port list, which publishes six of them, 38080 for the application itself and then 7010, 7011, 7199, 49142 and 8182, with no indication in the readme of what each one serves. Publishing every port the process might listen on is the shape of a command written for a demonstration rather than for a network you care about, and the sensible approach is to publish only the application port and leave the rest on the container network until you know what needs them. The second is the database host, which is set to the loopback address of the machine running the container. Inside a container, loopback is the container, and there is no host networking and no mapping for the database port in the command, so as written the server will look for MySQL inside its own network namespace and not find it. Nothing else in the command is wrong, and the fix is small, either point the variable at a host address reachable from the container or add host networking, but it does mean the documented command does not start on a clean machine.

mkdir -p /data/folib/folib-data/logs
docker run -itd -p 38080:38080 -p 7010:7010 -p 7011:7011 -p 7199:7199 -p 49142:49142 -p 8182:8182 \
--name folib-server \
--restart=always --privileged=true \
-e FOLIB_PORT=38080 \
-e FOLIB_JVM_XMX=8192m \
-e FOLIB_JVM_XMS=8192m \
-e FOLIB_JVM_XSS=512k \
-e FOLIB_MYSQL_HOST=127.0.0.1 \
-e FOLIB_MYSQL_PORT=3306 \

The third observation is the privilege flag. The container is started privileged, which grants far more than a repository server needs, and nothing in the readme explains what for. A repository that stores uploads and serves them to build agents is worth running with less authority than that, and if the flag is only there to make some particular upload path work, that is worth asking about before it becomes the default in your infrastructure.

The tarball path, a start script, and a documented double start

The virtual machine instructions are for people who would rather not run a container, and they assume a Java runtime prepared in advance. You unpack a tarball or a zip from the target directory of the build module, copy the application directory and the data directory to a path under the opt directory, and then write a start script. The script exports the configuration as environment variables, which is a good pattern in principle since every setting is visible in one place, and then starts the application in the foreground console mode with output redirected to a log file, backgrounded. Two things in that sequence deserve a second look. The first is the stack size, set to 512 kilobytes, which is half the usual default for a 64-bit JVM and leaves very little room for deep recursion; combined with an eight gigabyte heap in the same script, it is a strange pairing, and if the server throws a stack overflow under a large upload or a deep graph traversal, this is the setting to look at. The second is that the instructions then tell you to stop the service and start it again, after you have already started it and tailed the log. The sequence is: start, check the log, stop, start again, check the log. That is what a developer does to prove a clean restart works, and it is in the deployment documentation, which suggests the section was written from a session rather than designed as a procedure. There is also a mismatch of mechanism worth noting, since the script backgrounds the process with nohup while the stop command comes from the application's own wrapper, so the service is launched outside the wrapper it is stopped with. That works, and it means there is no supervision of the process other than whatever the init system provides.

export FOLIB_PORT=38080
export FOLIB_JVM_XMX=8192m
export FOLIB_JVM_XSS=512k
export FOLIB_MYSQL_HOST=127.0.0.1
export FOLIB_MYSQL_DB=folib
nohup /opt/folib/folib-3.0-SNAPSHOT/bin/folib console > folib-server.log 2>&1 &
/opt/folib/folib-3.0-SNAPSHOT/bin/folib stop
sh folib-server-start.sh

Four install paths and three different version numbers

There are more ways in than the two documented above. A Helm chart is published on a public chart registry, which is the natural choice on Kubernetes, and for a network with no outbound access the project points at an offline installation package on its own site, which is a tarball you cannot inspect before installing and therefore the path where your supply chain controls matter most. A demo environment and a customer page are also linked, which is useful for evaluating the interface before you install anything. The version question is the confusing part, and there are three answers in the repository. The releases list shows a single release, 3.1.0, published on 2025-09-23. The badge in the readme says version 3.0.0. And every path in both deployment guides, the image name for the container, the tarball to unpack, the application directory and the binary, refers to 3.0-SNAPSHOT, which is a development version string that would not appear in a released artefact. So a reader has to work out for themselves whether the documentation describes the current release or a development build, and the container image being tagged as the latest tag makes it worse rather than better, because the tag carries no version at all. There is a changelog file at the top level, and that is where the answer should be, but neither deployment section refers to it. For an evaluation this is not a cosmetic problem, because the whole product proposition is trust in your supply chain, and a repository manager whose own version numbering cannot be read off its documentation is asking for something it should be providing.

The default account is in the readme, and artefact upload restrictions are a variable

The last thing the deployment sections do is tell you the credentials, and they do it twice, in both the container path and the virtual machine path, giving the same account name and the same password. The example database password in the environment variables is that same string, so a deployment that follows the documentation literally has one published password on the application and one on the database. Neither is a criticism of the maintainers, who have to give you something to log in with on the first start, and neither is a surprise to anyone who has installed software from a Chinese enterprise project. It is a checklist item, and it belongs at the top of one. The environment variables themselves are worth reading as a configuration surface, because they are the documented way to configure the server. There is the application port, the four JVM sizing variables, five database variables, and one that stands out. Artefact upload restrictions are set to true in both examples, which reads as a sensible default for a system that proxies other people's packages, since unrestricted upload would let anyone with access publish into your repository namespace. That variable is the one to understand before you turn it off, and it is the kind of setting a security review will ask about, so knowing what it does before the review is cheaper than finding out during it. The application also exposes a text file editor and a web interface for deployments, both of which are conveniences on a system that holds the artefacts your builds consume.

GPL-3.0, a licence compliance document, and a Chinese first documentation set

The licence is GPL-3.0, and for a server product that is the version with reach, since it attaches when a modified version is offered to users over a network. A repository manager is usually deployed once, inside one organisation, and modified rarely, so the practical effect is smaller than it would be for a distributed tool, but if your process expects to modify the code and keep the changes internal, that is a question for your counsel rather than for this article. What is more immediately interesting is that the project ships a licence header template and a document explaining licence compliance, because for a repository that proxies npm, Maven, PyPI and the model hubs, the licences of the things it stores are its problem as well as its users'. A repository manager that can answer what licence an artefact you depend on came under is doing something a cache cannot, and that connects directly back to the graph service, since a compliance question is a graph query over artefacts and their licences. On maintenance, the picture is a single release from 2025-09-23 and a last push on 2026-07-30, with a changelog at the top of the tree, so the work is continuing in the repository rather than in tagged builds. Support is organised through a forum and technical chat groups rather than an issue tracker, which suits a project with a Chinese-speaking user base and makes searching for prior answers harder for anyone outside it. The English readme exists, so the project is not Chinese only, but the deployment documentation, the environment variable comments and the configuration walkthroughs are all written in the other language, and that is the practical constraint on evaluating it from outside that market.

Editorial conclusion

FOLib earns an evaluation if your dependency problem has outgrown a single ecosystem, since the same server fronting npm, Maven, PyPI, Docker and Conda is the whole argument, and the model hub proxying is the part no general purpose repository manager offers. The graph service and the MCP endpoint are the features to test first, because they are the reason the project positions itself for AI development rather than for build caching, and an agent querying your artefact metadata is a capability with access-control implications that a CI cache does not have. Two things to settle before deploying. Which version you are actually running, since the newest release is 3.1.0 while the badge on the readme says 3.0.0 and the deployment paths say 3.0-SNAPSHOT, and a container image tagged as latest is none of those. And the database host, because the documented command points the container at 127.0.0.1 for MySQL, which inside a container is the container itself, so that address has to change before the first start will work. Then change the published admin password, and decide whether the offline installation package is acceptable in an environment where you would otherwise not be able to inspect what you install.

Frequently asked questions

Official sources

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