Download the PHP package kumwe/app without Composer

Kumwe App

Kumwe is a modern CMS, built with disciplined engineering and AI acceleration. It is two platforms behind one set of rules: a content-management system — managed pages, media, nested menus, and governed publishing workflows in a graphical administrator — and a business application platform — a typed business definition and record runtime with policies, approvals, reports, and an isolated client portal. Both halves run through the same application services, so what the browser allows, the REST API, CLI, MCP tools, workers, and scheduler allow, and what one refuses, the others refuse too.

• Content, media, and navigation are managed records with revisions, workflow states, and audit trails.
• Business definitions declare typed entities, relationships, views, actions, and safe formulas; the runtime generates the administrator and portal surfaces, the REST contract, and the CLI/MCP tools.
• The interface is presented in the language a request resolves to, and an operator changes the wording their people read — relabelling "Client" as "Patient" or "Learner" — from a screen, per message and without a deployment.
• Extensions install through a signed pipeline into a compiled, verified runtime — plugins, components, templates, languages, and message catalogues, without rebuilding the application image.
• Automation is durable: database-backed queues, leases, bounded retries, and recurring schedules.

Entry points: AGENTS.md is the operator checklist for changing this repository, the demo profiles, documentation index.

Quick start: the full demonstration

Docker Engine with Compose v2 is the shortest path. The copied environment selects the documentation site and the Vast Development Method (VDM) business dataset by default, and database:migrate installs both.

The app container runs as user ${KUMWE_UID:-1000}:${KUMWE_GID:-1000} over the mounted checkout. If your host user is not UID 1000, export matching identifiers before the first compose command so the checkout stays writable from inside the container:

Create the owner account, then complete the demonstration — sign-ins and example extensions — with one command. Passwords never travel as arguments; they arrive in files only you can read. Paths passed to the container must be container-visible, which is why the flags below use the /app prefix (the checkout is mounted there):

demo:install provisions the VDM demonstration cast — five staff accounts and six portal client organizations with nine members — and installs the shipped example extensions (announcements, asset-inspection, and the horizon-theme site theme, which installs as selectable and is never activated for you). Each new account receives a generated password written exactly twice: to the command output and to the owner-only credentials file, which lands on the host at storage/private/demo-access-credentials.json.

Re-running the command is safe: existing accounts and installed examples are confirmed, no password is re-issued, and the credentials file is only created on a run that actually generated a new password — otherwise the command reports that existing sign-ins remain valid and touches nothing.

Sign in at http://localhost:8080/administrator with the owner or a staff account, and at http://localhost:8080/portal with a portal member. The site content and business records were already installed by database:migrate; the getting-started guide continues from here.

Without Docker

The same flow runs on host PHP 8.5 with MariaDB (or MySQL/PostgreSQL) and Redis reachable from the process. Point DB_HOST and REDIS_HOST in .env at your services (for example 127.0.0.1), then:

Run the same user:create-admin and demo:install commands with host-absolute paths — for example --admin-password-file="$PWD/.admin-password" and --credentials-file="$PWD/storage/private/demo-access-credentials.json". The password and credentials file rules are identical: absolute paths, regular files, no group or other permission bits. Composer-project and release-ZIP installations follow the production install guide instead; bin/kumwe-install walks the same steps interactively.

Starting clean

For an empty installation, choose the blank datasets in .env before the first migration:

Then run the same database:migrate and create the first administrator with user:create-admin as above. Each dataset's choice is frozen independently when its first reconciliation begins; later migration runs refuse a different value rather than switching profiles, so decide before the first migrate. With none selected, demo:install skips the demonstration cast cleanly and can still install the example extensions if you want them. See demo profiles for the selector contract.

Running it

The development Compose stack runs three services: app (the PHP built-in server behind a dedicated asset router, plus a watcher that keeps the extension runtime verified), database (MariaDB by default; MySQL and PostgreSQL are supported), and redis. docker compose up -d --wait returns only once /health/ready answers. KUMWE_HTTP_PORT in .env moves the published port.

Background work is real infrastructure, not an afterthought. Queued report exports are completed by a worker on the exports queue — without one they stay queued forever:

Production Compose runs the web, PHP-FPM, one-shot migrate, database, and Redis services, and starts the same worker and scheduler commands as dedicated services:

Workers and scheduler covers queues, schedules, and operating rules; operations covers deployment, backup, and upgrades.

Studio content authoring

Studio is the target contextual page builder and editor for Kumwe content: creating or editing content should open the same Studio workspace for layout, blocks, typed fields, and values, inline or expanded, without first visiting a separate Studio or Blueprint catalogue. Extensions can contribute governed Studio blocks and fields to authorized targets through the same host integration.

That unified journey is not yet complete in App. The current integration opens a Blueprint-only composition route from an already-created Content-type version; Content model and entry writes still use separate forms. The single App-side statement of the target, exact current gap, PHP host boundary, and small-goal implementation sequence is Studio authoring in Kumwe App.

Studio's browser code is compiled before deployment. Kumwe's server authority is PHP, and an installed production App never requires Node.js, npm, a JavaScript development server, or a server-side JavaScript process to start, author, preview, publish, or render content.

Testing

That is the local gate every change runs before it is pushed; CI runs the same member set. The authoritative member list is docs/quality/contract.json, reproduced in AGENTS.md section 6 — this file deliberately does not carry a third copy. A fresh sandbox is provisioned by bash tools/agent-setup.sh (AGENTS.md section 0).

Contributors who change browser sources use Node.js and npm to build and test the committed browser assets. These are source-development commands, not production installation or server-operation steps:

Every supported engine — MariaDB, MySQL 8.4, PostgreSQL 17 — runs the same services and migrations; select one per installation with DB_DRIVER and KUMWE_DATABASE_IMAGE and re-run the same suites. Development and testing documents the local and CI contracts; AGENTS.md describe the workflow.

Contributing and extending

• Read coding standard is normative for every contributor, human or automated.
• Scaffold an extension with php bin/kumwe extension:scaffold and build against templates; everything installs through the signed pipeline.
• Demonstration data is packaged as versioned demo profiles. Build a site, then turn it into a shareable, installable profile with php bin/kumwe demo:export-profile — forks ship their own demonstrations by dropping a profile beside the released ones.
• Report problems and propose changes on GitHub issues and discussions.

Supported runtime

The machine-readable API contract is api/openapi/kumwe-v1.json. Run php bin/kumwe list from an installed release for the CLI command index.

License

Copyright 2022-2026 Vast Development Method Trading Pty Ltd

Kumwe is free and open source software, licensed under the Apache License 2.0; see also the NOTICE file.

In plain terms: you are free to use, modify, and distribute Kumwe, in open or closed form — commercial products and proprietary extensions are welcome. If you build on it, we would love to hear from you, and patches are always appreciated; the license requires neither. The software is provided as-is, without warranty or liability, and the Kumwe name and logos are not part of the code license.