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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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 . '<p>Hello!</p>'
);
$this->get(
'/hello',
fn() => 'Hello from my app!'
);
$this->registerWidget('stats', [
'title' => 'Site Stats',
'render' => fn() => '<p>Hello 👋</p>',
]);
}
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.
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.
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 logic into templates.
It is also useful for AI-assisted development.
You can ask an AI coding assistant to modify the theme without requiring it to understand every application feature.
Or build an app without changing the site's visual layer.
For modern JavaScript applications, build systems are completely normal.
For a CMS intended to run on ordinary hosting, they can also become unnecessary friction.
Basehim deliberately avoids requiring a frontend compilation process.
You can upload the CMS.
You can upload an app.
You can upload a theme.
You can activate it.
This makes the deployment model closer to the traditional PHP hosting ecosystem.
That matters more than it sounds.
A developer might have Docker, GitHub Actions and a VPS for one project.
The next client might have nothing except a cPanel account.
A CMS shouldn't assume that every website is deployed like a SaaS application.
The Basehim philosophy is intentionally pragmatic.
The target environment isn't only modern cloud infrastructure.
It includes:
The current requirements are relatively modest:
PHP 8.1+
MySQL 5.7+ or MariaDB 10.3+
Apache with mod_rewrite
pdo_mysql
mbstring
fileinfo
gd
zip
The repository also estimates around 30 MB of disk space for the core installation, excluding uploaded content.
That makes Basehim interesting for a particular category of developer:
the developer who wants modern architecture without abandoning ordinary hosting.
Basehim isn't built on top of a giant framework stack.
The repository contains its own relatively small application architecture.
The structure includes components such as:
app/
├── Core/
├── Http/
├── Repositories/
└── Services/
There are controllers, middleware, repositories, services, configuration, routes, database migrations, apps and themes.
The repository also includes:
docs/
CHANGELOG.md
CONTRIBUTING.md
SECURITY.md
LICENSE
That matters for an open-source project.
If the goal is to attract contributors, the code shouldn't feel like a black box.
Developers should be able to clone the project and actually understand where things live.
Basehim is released under the MIT license.
That is important because the goal isn't simply to provide a hosted website builder.
The project is intended to be used, inspected, modified, extended and contributed to.
You can look at the source.
You can create an app.
You can create a theme.
You can fork the project.
You can report an issue.
You can contribute improvements.
You aren't required to treat the CMS as a black box.
For developers, that freedom matters.
This is an obvious question.
WordPress is enormous.
It has an ecosystem that Basehim cannot realistically compete with today.
It has thousands of themes, plugins, tutorials, hosting providers, agencies and developers.
So Basehim isn't trying to win by pretending WordPress doesn't exist.
The opportunity is different.
Basehim is designed around a different set of priorities:
API-first instead of dashboard-first.
AI-ready instead of AI-integrated as an afterthought.
Apps instead of core modifications.
Scoped agent permissions instead of giving AI administrator credentials.
Simple PHP deployment instead of mandatory build infrastructure.
A smaller, more understandable core instead of an enormous ecosystem.
If you need the world's largest CMS ecosystem, there are obvious choices.
If you're building something new and want a CMS designed around APIs, modularity and AI agents from the beginning, that's where Basehim becomes interesting.
There is an important distinction here.
"Easy to install" doesn't mean "magically easy to build anything."
AI doesn't eliminate software engineering.
And a CMS doesn't eliminate architectural decisions.
Basehim tries to make the boundaries clearer.
The core handles the platform.
Apps handle additional functionality.
Themes handle presentation.
The API handles programmatic access.
MCP handles AI-agent interaction.
Permissions control what integrations can access.
That gives developers a set of boundaries to work within.
And good boundaries are one of the most useful things you can give an AI coding assistant.
Let's take a practical example.
Suppose you're building a company website.
Instead of manually performing every administrative operation, you could eventually have an AI agent connected to Basehim through MCP.
You could ask it to:
Find all published articles about our product.
The agent searches the CMS.
Then:
Create a draft article explaining our new feature.
The agent creates a draft.
Then:
Add the "Product Updates" taxonomy.
The agent performs the operation if it has the required permission.
Then:
Show me the last five posts.
The agent retrieves them.
The CMS remains the system of record.
The AI becomes another interface.
That's fundamentally different from simply putting a chatbot on top of a website.
The more interesting future is websites that AI can operate.
There is a difference.
An AI-generated website is simply a website produced with AI.
An AI-accessible website is one where software agents can understand and interact with structured capabilities exposed by the website.
That opens the door to much more interesting automation.
Imagine a CMS where agents can:
All without giving the agent unrestricted administrator access.
That is closer to the direction Basehim is exploring.
Basehim is developer-oriented.
But that doesn't mean every Basehim user needs to be an expert programmer.
The underlying idea is that developers create the foundation and extensions, while administrators use the resulting system.
An agency could build a Basehim installation for a client.
A developer could create custom apps.
A designer could create themes.
A business owner could manage content.
An AI assistant could automate repetitive operations.
The same platform can serve all of them.
Basehim also includes a marketplace architecture for apps and themes.
That creates a potential ecosystem around the CMS.
Imagine eventually having:
Basehim
│
├── Apps
│ ├── SEO
│ ├── Analytics
│ ├── Forms
│ ├── Ecommerce
│ ├── CRM
│ └── AI tools
│
└── Themes
├── Business
├── Blog
├── Portfolio
├── Documentation
└── Ecommerce
The important part is that the ecosystem doesn't need to be limited to the original Basehim developers.
Third-party developers can build applications.
Designers can build themes.
Agencies can create private extensions for clients.
That is where an open-source CMS can become much more valuable than its core code alone.
It is important not to oversell a young open-source project.
Basehim is not WordPress.
It doesn't have WordPress's ecosystem.
It doesn't have millions of installations.
It doesn't have thousands of third-party plugins.
It doesn't have decades of compatibility baggage.
And that's precisely why now is an interesting time to experiment with it.
The current project already provides a functioning foundation:
But there is still a lot to build.
And that's the point of open source.
The interesting question isn't only what Basehim currently does.
It's what developers can build on top of it.
An AI-native CMS could eventually become the foundation for:
Agent-managed websites
AI agents that maintain content, monitor changes and perform routine operations.
AI-assisted publishing
A workflow where humans approve AI-generated content rather than manually creating everything.
Autonomous content operations
Agents that monitor analytics, identify outdated content and prepare updates.
Composable websites
Apps and themes assembled according to the needs of each project.
AI-generated Basehim apps
Describe a feature to an AI coding agent and have it generate a structured Basehim app rather than modifying the core.
Headless applications
Use Basehim purely as a backend while another application consumes its REST API.
Custom business systems
Build CRM, directories, portals, internal tools and other applications using the CMS as the foundation.
The CMS stops being merely a place to write blog posts.
It becomes a programmable website platform.
The web has spent decades moving toward abstraction.
First, we wrote HTML manually.
Then came CMSs.
Then plugins and themes.
Then APIs.
Then headless CMSs.
Now AI agents are becoming another layer of interaction.
The next generation of CMSs may not simply be systems that humans operate.
They may be systems that humans and software agents operate.
That requires different architectural assumptions.
An API is no longer optional.
Permissions matter more.
Structured resources matter.
Machine-readable capabilities matter.
Authentication designed for agents matters.
Modularity matters.
And the ability to deploy without a massive infrastructure stack still matters.
Basehim is an attempt to bring those ideas together in one open-source PHP CMS.
The most interesting part of an open-source project isn't the repository on launch day.
It's what happens after developers start using it.
You can inspect the code.
Try the installer.
Build an app.
Create a theme.
Connect the API.
Experiment with MCP.
Test AI-agent workflows.
Find security issues.
Improve documentation.
Open issues.
Submit pull requests.
Or simply build something with it and tell the project what broke.
That's how an ecosystem starts.
Not with a perfect CMS.
With developers willing to experiment with an imperfect one.
Basehim is open source and available on GitHub.
If you're a PHP developer, AI-assisted developer, agency, hobbyist, or someone interested in what an AI-ready CMS could look like, try installing it.
The project is intentionally designed to work on ordinary PHP hosting while providing APIs and agent capabilities that normally belong to more infrastructure-heavy platforms.
Build a website.
Build an app.
Connect an AI agent.
Break something.
Fix it.
Send a pull request.
That's the point.
Basehim isn't trying to predict exactly what the future of websites will look like.
It's trying to build a foundation that can adapt to it.
An open-source, modular CMS for developers and AI-assisted/vibe-coded websites.
Website: https://basehim.com
GitHub: https://github.com/basehim/basehim
Documentation: https://basehim.com/docs/
API Reference: https://basehim.com/docs/api-reference
If you're interested in AI agents, MCP, open-source CMS development, PHP, or building the next generation of websites, Basehim is an experiment worth watching — and better yet, worth contributing to.