Why Salieno Core Uses a Plugin Architecture Instead of Monolith

The architecture you choose shapes the business you can build#

When we set out to build Salieno Core — a self-hosted platform that bundles a hosting control panel, billing, and license management — we faced an early fork in the road. Should we build a monolithic application where every feature lives in one codebase, or should we design a lightweight core that delegates functionality to plugins?

We chose plugins. Not because it's trendy, but because the hosting industry punishes monoliths over time. Here's why, and what that decision looks like in practice.

What "plugin-first" actually means in Salieno Core#

Salieno Core's kernel handles the essentials: user authentication, role-based access control, a unified API layer, event dispatching, and a database abstraction. Everything else — provisioning cPanel accounts, generating WHMCS-compatible invoices, integrating with payment gateways, syncing DNS zones — ships as a plugin or can be replaced by one.

This isn't an afterthought bolted onto a monolith. The kernel exposes stable hooks at well-defined lifecycle points: before a service is provisioned, after an invoice is paid, when a domain's nameservers change, when a license key is validated. Plugins subscribe to these hooks and execute their logic independently.

The result: you can swap out the default provisioning module for one that talks to DirectAdmin or CyberPanel without touching billing code. You can replace the built-in license validator with one that checks against your own key server. The pieces are decoupled.

Why monoliths break down for hosting platforms#

Hosting is a fragmented industry by nature. Resellers use different control panels (cPanel, Plesk, DirectAdmin, custom), different billing systems (WHMCS, Blesta, custom-built), different DNS providers, and different server stacks (LiteSpeed, OpenLiteSpeed, Nginx, Apache). No single combination covers even half the market.

A monolithic platform has to either pick winners — hardcoding integrations with cPanel and WHMCS and hoping that's enough — or accumulate an unmaintainable sprawl of conditional logic: if panel == 'cpanel' then... else if panel == 'directadmin' then...

We've seen this pattern in other hosting tools. The codebase grows brittle. Every new integration risks breaking existing ones. Testing becomes combinatorial. Release cycles slow to a crawl because a DNS module change might affect billing.

A plugin architecture sidesteps this. Each integration lives in its own package with its own tests and its own release cycle. The core team ships kernel improvements without worrying about breaking the DirectAdmin plugin that only 12% of users have installed.

The trade-offs we accepted#

This isn't free. Plugin architectures carry real costs:

• Discoverability. New users have to install plugins before they can do anything useful. We mitigate this with a curated default bundle — Salieno Core ships with the most common plugins pre-installed so it works out of the box.

• Version compatibility. Plugins can fall behind the kernel's API. We address this with semantic versioning on our hook interfaces and a compatibility manifest that warns you before you upgrade.

• Performance overhead. Hook dispatching adds microseconds per call. For a hosting control panel that handles dozens of requests per second (not thousands), this is negligible. We benchmarked it: the plugin dispatch layer adds under 0.3ms per request on modest hardware.

• Fragmentation risk. If every reseller runs a different set of plugins, support becomes harder. We publish a "recommended stack" and maintain integration tests against the most common plugin combinations.

We think these trade-offs are worth it, but we won't pretend they don't exist.

How this affects day-to-day operations#

For a hosting reseller or indie host, the practical implications are tangible:

• You're not locked into our roadmap. Need a plugin that integrates with a regional payment gateway we've never heard of? Build it. The plugin API is documented and the hook system is straightforward.

• Upgrades are safer. When we release a kernel update, your billing plugin doesn't break because it only talks to the kernel through stable interfaces. You can upgrade the kernel and defer plugin updates independently.

• You can run lean. If you don't use license management, don't install that plugin. Fewer moving parts means a smaller attack surface and less memory usage — relevant for hosts running Salieno Core on a VPS alongside their reseller accounts.

What's next#

We're expanding the plugin ecosystem with community contributions in mind. A plugin marketplace is on the roadmap, along with a sandboxed execution mode for third-party plugins that limits what kernel resources they can access.

The goal isn't to build every feature ourselves. It's to build a kernel solid enough that others can extend it confidently — and that you can run a professional hosting business on infrastructure you fully control.

The architecture you choose on day one determines what's possible on day one thousand. We chose plugins because the hosting industry moves in too many directions for any single team to keep up with monolithically.