The ByJG Ecosystem
The ByJG projects form one path. You build an application, test it on your machine, deploy it and run it in production, and the container you tested is the container that runs. Every project follows the same standard, and its documentation is written for people and served to AI assistants.
Independent projects, brought together by automation
Each project has its own repository, tests and release cycle, and works on its own. You can use EasyHAProxy without any PHP component, or MicroOrm without any ByJG Docker image.
What makes them one ecosystem is automation. When a project is merged or
tagged, shared workflows publish its documentation, its Helm chart and its
apt and dnf packages to this site. The
Homebrew tap works the other way: it
checks every day for new release tags and updates its formulas by itself.
Nothing is copied by hand and no project depends on another to release.
1. Build the application
Gluo creates a REST API project you own, with authentication, migrations, ORM, OpenAPI and a test harness already wired. It is assembled from independent components that you can also use one by one:
| Need | Component |
|---|---|
| HTTP routing and OpenAPI | RestServer |
| Persistence | MicroOrm, AnyDataset DB, Migration |
| Serialization | Serializer |
| Configuration and feature flags | Config, Feature Flag |
| Caching | Cache Engine |
| Authentication | AuthUser, JWT Wrapper |
| Queues and workflows | Message Queue Client, State Machine |
| Browser | Yaj, Yaj SSE |
The full list and the dependency graph are on the PHP components page.
2. Test it locally
The project comes with a docker-compose.yml, so docker compose up -d
starts the API, the database and the frontend on your machine. The containers
are built from the ByJG PHP images, which
exist in CLI, FPM, Nginx and Apache variants for each PHP version. Nothing has
to be installed on the host besides Docker.
API tests check the responses against the OpenAPI contract with Swagger Test.
3. Deploy it
The same pipeline that runs the tests builds the application image. k8s-ci is the CI image with the tools to build and deploy, and Helm charts are published for the projects that run on Kubernetes.
DockNimbus provides the place to deploy to. It turns bare metal machines and VMs into a platform with compute, networking, storage, Docker Swarm and K3s clusters, declared in a single manifest.
4. Run it in production
Production runs the image that was tested locally and in CI, so there is no difference between environments to debug.
EasyHAProxy is the load balancer in front. It discovers the services from Docker labels, Swarm services or Kubernetes Ingress, issues the TLS certificates and reloads HAProxy without dropping connections. DockNimbus uses it for load balancing. Static HTTP Server serves frontends and static sites.
5. One standard for every project
All projects are tested, released and documented the same way. The Development Guidelines define it:
- Nothing is published before the tests pass.
- Releases are tags, with semantic versions.
- CI is written once as reusable workflows and called from each project.
- Documentation lives in the project repository, next to the code.
Publishing is automated too. A project does not build its own release machinery; it calls a shared workflow or pushes a tag:
| What is published | How | How you get it |
|---|---|---|
| Documentation | add-doc.yaml reusable workflow | This site, and the Docs MCP index |
| Helm charts | add-helm.yaml reusable workflow | helm repo add byjg https://opensource.byjg.com/helm |
| DEB packages | add-pkg.yaml reusable workflow, signed | apt install from the APT repository |
| RPM packages | add-pkg.yaml reusable workflow, signed | dnf install from the RPM repository |
| Homebrew formulas | A daily workflow in the tap picks up new release tags, then builds, tests and audits the formula | brew install byjg/tap/<formula> |
| Docker images | The project's build.yml | docker pull byjg/<image> |
| PHP components | A git tag | composer require byjg/<component> |
The reasons are in the KISS principle and in Simple Principles to Avoid Overcomplicating the Complex.
6. Documentation for humans and AI assistants
When a project is merged, a reusable workflow copies its documentation to this site. The ByJG Docs MCP server indexes the site with semantic and keyword search, and any assistant that speaks MCP can query it and cite the page.
An agent asked to add persistence to a ByJG application then finds
MicroOrm and how it is meant to be used, instead
of inventing a data layer. Parolsh is the shell to
work with that agent: natural language by default, Bash one ! away, and any
ACP agent behind it.
The method
The path above is the result of a method that can be repeated in any set of projects, with or without the ByJG tools:
- Automate what is repetitive. Tests, builds, releases, Helm charts, Linux packages and documentation publishing run in CI.
- Centralize what is shared. One set of workflows, one documentation site, one set of base images.
- Isolate what is independent. Each component has its own repository, tests and release cycle. Automation, and only automation, is what joins them.
- Use the same container everywhere. Development, CI and production run the same image.
- Write the documentation once, for two readers. A person reads it on the site; an AI assistant reads it through MCP.
How I Manage 30+ Open Source Projects tells how this method came to be.