Publishing software should stay practical.
VonCMS is built around a simple idea: most publishing sites should be easy to host, easy to inspect, and easy to extend without turning every owner into a plugin manager or DevOps operator.
The Problem
Many publishing stacks drift toward one of two extremes. Legacy CMS installs can become plugin-heavy and fragile. Modern headless stacks can add hosting assumptions, build pipelines, paid platform surfaces, and operational overhead that ordinary content sites do not need.
VonCMS is not trying to win by having the longest feature list. It tries to make the common publishing path calmer: install the runtime, own the database, publish content, and customize from source when the project actually needs it.
Less dependency surface is a product decision, not just an engineering preference.
Ownership
A site owner should be able to move hosts, inspect the source, back up the database, replace files manually, and keep publishing without asking a platform for permission. That is why VonCMS uses standard PHP and MySQL for runtime hosting.
Files you can replace
The Deploy ZIP path keeps runtime deployment understandable for shared hosting and VPS users.
Data you can back up
Content and settings live in a database the site owner controls.
Source you can study
Developers can fork the repository, change themes, build plugins, edit APIs, and create releases.
Daily Workflow
A CMS choice is not only a technical architecture choice. It is a daily workflow choice. If the system constantly pushes the owner into plugin maintenance, broken updates, or tooling chores, the software is taking time away from publishing.
For site owners
Install from Deploy ZIP, finish the browser installer, sign in, choose a theme, publish, and maintain the site through admin tools.
For developers
Use the source repository when custom code is needed. Keep changes focused, run the relevant checks, and package deliberately.
Ordinary Runtime
The production runtime should not require Node.js, npm, Vite, or a separate frontend server. VonCMS uses those tools for source development, then ships built assets for runtime hosting.
Open Source
Open source should mean more than a public download. The repository needs to be understandable enough for someone to inspect architecture, build a theme, change a plugin, review security-sensitive code, and reproduce release checks.
- Docs should point developers toward the right files.
- Release packages should avoid private workspace artifacts.
- Checks should be explicit enough to rerun later.
- Marketing copy should not claim more than the source proves.
SEO Ownership
Publishing software should own its public output. VonCMS keeps crawler-facing behavior in the runtime path: metadata, social cards, sitemaps, feeds, canonical URLs, robots output, llms.txt, and JSON-LD belong to the site, not to an afterthought plugin.
Security Posture
Security should be handled with evidence and scope, not slogans. VonCMS favors focused boundaries: role checks, CSRF coverage, safe importer behavior, routing rules, sensitive-file protections, and release checks that can be re-run.
Do not call a claim secure because it sounds secure. Prove the specific boundary.
Product Beliefs
Hostability matters
A CMS that cannot run on ordinary hosting excludes too many real publishing use cases.
Source should be useful
Public code should help developers modify and verify the product, not just satisfy a license checkbox.
Core should carry the basics
Publishing, SEO, themes, extensions, media, users, comments, and repair tools should not require a shopping list.
Claims need restraint
A professional product page should say what changed and what exists, without pretending every feature is revolutionary.