The Swiss Army knife for Nextcloud app development: one generic Makefile for building, packaging, deploying, versioning and App Store management of a Nextcloud app.
Everything is derived from the app itself, so a standard app needs no build config at all — drop it in, run make, done. Composer and npm run in throwaway containers, so the host needs neither PHP nor Node.
Tip
📖 The full documentation lives in the ncmake wiki. This page is just the quick start — every guide, reference and background piece is a wiki page, kept current there.
Commit the bootstrap stub as your app's Makefile, once:
curl -fLO https://raw.githubusercontent.com/ernolf/ncmake/main/bootstrap/Makefile
git add MakefileThat single dozen-line file is all your repository carries: it fetches the real Makefile into a per-machine cache and includes it from there, so every clone of your app runs the current ncmake from one shared cache — nothing else lands in your checkout. Then:
make # colorized, annotated help with your app id, version and cert status
make build # composer + npm, each in a throwaway container
make dist # stage the runtime file set and pack the release tarballNew here? Start with Getting started and the step-by-step walkthrough.
- No host toolchain — composer and npm run in throwaway containers on the PHP and Node versions the app declares; you need only podman or docker.
- Nothing to configure — app id, version, build steps and the shipped file set are read from
info.xml,composer.json,package.jsonand.gitignore. - Keep-model packaging — a release ships an allowlist of runtime paths, so a stray dev file can never leak in, and the same staged set feeds
dist,rsyncandcp. - One shared, self-updating Makefile — a dozen-line stub per app; update ncmake once and every app on the machine follows.
- The full release lifecycle — a validated version bump, a changelog from your conventional commits, a signed tag, and App Store signing and publishing.
- Managed CI workflows — installed from upstream templates, tracked against local edits, and kept current by an auto-updater that opens pull requests.
Wondering how it compares to krankerl, or why it is built this way? → Why ncmake
Everything is in the wiki; its sidebar has the full set. Good entry points:
- New to ncmake → Getting started · Step by step
- Building & releasing → How ncmake understands your app · Building and packaging · Releasing · Per-app tuning · Target reference
- CI workflows → Workflows · Workflow updater · GitHub App · GitHub PAT · Deleting merged branches
- App Store → App Store
- Installing an ncmake app (for your app's users) → Installation
GNU make, git, curl, openssl, rsync, python3; optionally xmllint (ncmake falls back to grep without it). For containerized builds: podman or docker — otherwise RUNTIME=bare with composer and npm on the PATH.
If ncmake is useful to you, add the badge to your app's README (see Getting started):
[](https://github.com/ernolf/ncmake)