An open-source, modular CMS for developers and AI-assisted/vibe-coded websites.

For years, the CMS ecosystem has largely followed the same formula. Install a CMS. Choose a theme. Install plugins. Customize some templates. Add an API when you need one. Then, eventually, try to connect everything to AI. But the way we build software has changed. Developers increasingly work alongside AI coding assistants. People are building websites by describing what they want instead of manually implementing every component. AI agents can now interact with external tools and services. APIs are becoming the foundation rather than an optional feature. Yet many traditional CMS architectures were designed for a world where a human administrator was the primary interface. That is the problem Basehim is trying to solve. Basehim is an open-source, modular, API-first PHP CMS built for developers, AI-assisted development, and the emerging world of AI agents. The goal isn't to replace every CMS. The goal is to provide a simpler foundation for people who want to build, customize, automate, and extend websites without being forced into a complicated infrastructure stack. The idea behind Basehim Basehim started with a fairly simple observation: The web is still full of ordinary PHP hosting. Millions of websites run on environments such as cPanel, Plesk, Apache, MySQL, and shared hosting. Yet many modern development tools increasingly assume that you have SSH access, Composer, Node.js, a build pipeline, background workers, containers, or a cloud deployment environment. Those tools are excellent when you need them. But they aren't always necessary for a CMS. Basehim takes a different approach. If your server can run modern PHP and MySQL or MariaDB, Basehim is designed to run there. You can upload the files, open the installer, configure the database, create the administrator account, and start building. There is no required Composer installation. There is no frontend build process. There is no daemon that has to remain running. There is no requirement for a public/ directory structure. For developers, that means fewer deployment assumptions. For beginners and small businesses, it means the CMS can work with the hosting they already have. But Basehim isn't just another PHP CMS The PHP requirement isn't the interesting part. The more important decision is architectural. Basehim is designed around three ideas: API-first. Modular. AI-ready. These three ideas are connected. A website should not be trapped inside its admin dashboard. A feature should not require modifying the core. And an AI agent should not have unrestricted access to an entire website simply because it has an API token. Basehim attempts to address all three. 1. API-first from the beginning The REST API is not an afterthought. Basehim exposes a REST API for core website resources including posts, pages, media, taxonomies, menus, comments, users, settings, apps, caching and scheduling. The API uses a predictable base path: /api/v1 Published content can be read without authentication, while operations involving writes or private content require authentication. There are multiple authentication approaches depending on the caller. For example, server-to-server integrations can use API keys. Applications acting on behalf of users can use JWT authentication. AI agents can use OAuth 2.1 through the MCP integration. That distinction matters. A script, a web application, and an AI agent don't necessarily have the same security requirements. They shouldn't be forced through exactly the same authentication model. 2. Basehim has a built-in MCP server This is probably the feature that most clearly separates Basehim from the traditional CMS model. Basehim includes a built-in Model Context Protocol (MCP) server. MCP provides a standardized way for AI applications and agents to interact with external systems. Instead of building a custom integration for every AI client, Basehim exposes an MCP endpoint at: /mcp An AI client can discover the endpoint, authenticate, and interact with resources exposed by the website. For example, Basehim exposes resources using a basehim:// URI scheme. A resource might represent information about the site itself or an individual post. This creates an interesting possibility. Imagine telling an AI assistant: "Find my three most recent published articles." The assistant doesn't need to scrape the website. It can interact with the CMS through its structured interface. Or: "Draft an article about PHP security based on the existing content." The agent can retrieve relevant content, prepare a draft, and potentially write it back through authorized operations. The important word here is authorized. AI integration without permissions is dangerous. Basehim therefore treats agent access as a security problem rather than simply a convenience feature. 3. AI agents don't get unlimited access Basehim uses OAuth 2.1 and scoped permissions for agent access. An access token can have specific capabilities such as: posts:read posts:write taxonomies:read taxonomies:write media:read comments:read comments:write settings:read users:read This creates a much better security model than simply giving an AI agent an administrator password. Consider an AI agent that only needs to generate blog drafts. Why should that agent be able to read users? It shouldn't. Why should it be able to modify site settings? It shouldn't. Why should it have access to everything simply because it is an AI integration? It shouldn't. The principle is simple: Give the agent the minimum permissions required to perform its job. Permissions can also be revoked. That becomes particularly important as websites begin connecting multiple AI systems and autonomous agents. 4. The CMS becomes an AI-accessible system This changes how we should think about a CMS. Traditionally, the CMS looks something like this: Human ↓ Admin Dashboard ↓ CMS ↓ Database An AI-native CMS can look more like: Human ───────────────┐ ↓ AI Assistant → API → CMS → Database ↑ AI Agent → MCP ──────┘ The dashboard still exists. Humans still need it. But it isn't the only interface anymore. The CMS becomes a system that can be operated through multiple interfaces. A browser. An application. An API. An automation. An AI assistant. An autonomous agent. That is one of the ideas behind Basehim. 5. What does "vibe-coded websites" actually mean? The term "vibe coding" has become popular because AI has changed how people build software. Instead of starting with: "I need to understand this framework before I can build this feature." Developers can increasingly start with: "I want this feature. Help me build it." AI coding tools can generate PHP, JavaScript, SQL, HTML, CSS and configuration. But there is a problem. AI can generate code very quickly. That doesn't mean the surrounding architecture becomes simple. Someone still needs to decide: - Where does the feature live? - How does it interact with the CMS? - What permissions does it need? - How does it store data? - How does it expose functionality? - How does the administrator enable or disable it? - How does it coexist with other features? - How can it be removed without damaging the core? This is where Basehim's modular architecture becomes interesting. Instead of asking an AI coding assistant to modify the CMS core every time you want a feature, you can build that functionality as an app. 6. Apps are the extension mechanism Basehim uses an app-based architecture. An app lives inside: content/apps/ An app can have an app.json manifest, source code, views, and assets. A simplified structure looks like: my-app/ ├── app.json ├── src/ │ └── App.php ├── views/ └── assets/ The app can then interact with the CMS through a consistent API. For example, an app can: - register actions - register filters - add routes - add admin menu items - register widgets - manage settings - interact with the database - use caching - expose functionality - request explicit permissions This is important for AI-assisted development. Instead of asking an AI coding assistant to understand and rewrite the entire CMS, you can give it a much smaller problem: "Build a Basehim app that adds X." That is a much more constrained engineering task. 7. A Basehim app can be surprisingly small One of the design goals is to avoid making extension development unnecessarily complicated. A basic app can extend the Basehim app class and implement its boot() method. Inside that method, an app can register hooks, routes, widgets, and admin menu entries. Conceptually, you could build an app that does something like: public function boot(): void { $this->addAction('post.created', [$this, 'handlePost']); $this->addFilter( 'post.content', fn($content) => $content . ' Hello! ' ); $this->get( '/hello', fn() => 'Hello from my app!' ); $this->registerWidget('stats', [ 'title' => 'Site Stats', 'render' => fn() => ' Hello 👋 ', ]); } The point isn't that every app should be this simple. The point is that the extension surface is deliberately understandable. You don't have to build a framework before building your feature. 8. Apps have permissions too Modularity without security becomes a mess. That's why Basehim allows apps to declare their required permissions. An administrator can see what an app is requesting before activating it. Apps with administrative functionality can also receive their own access capability, allowing access to be controlled by role or user. This creates a permission boundary between: Core CMS ↓ Installed App ↓ App permissions ↓ User / Role That is a much healthier model than blindly installing PHP files that can do anything. 9. Themes are separate from functionality Basehim also separates presentation from functionality. Themes live under: content/themes/ A theme can provide templates and assets without requiring a complicated frontend build pipeline. The idea is straightforward: Apps add behavior. Themes control presentation. That separation is useful for developers because it reduces the temptation to mix business logi