Self-Hosting a CMS: Who Controls the Data, Backups, and Dependencies?
Choosing where a content management system runs can give a website owner more say over infrastructure. It does not automatically mean that every piece of the project is stored on one server or that the owner can recover
Choosing where a content management system runs can give a website owner more say over infrastructure. It does not automatically mean that every piece of the project is stored on one server or that the owner can recover it without help.
A working site can depend on a domain registrar, DNS provider, application files, a database, object storage, email, backups, analytics, and third-party integrations. Useful control begins with knowing which of those components exist, who administers them, and how the project can be restored or transferred.
Morlix CMS is in development. Its closed beta has not started; applications from web studios are being collected, with access subject to approval. The public release is currently targeted for March 11, 2027, and the date may change. This article discusses an approach to evaluating self-hosting, not a promise that every deployment feature is available in a particular build.
What self-hosting can mean
For this discussion, self-hosting means the site owner or an appointed contractor chooses the hosting environment and is responsible for the application's deployment and operation. The degree of control differs. A shared hosting account leaves some system administration to the provider. A virtual or dedicated server can offer more control while adding responsibilities for updates, monitoring, access, and recovery.
The Morlix homepage describes deployment on PHP hosting, a VPS, or a dedicated server, and lists environment requirements including PHP 8.3+, MySQL or MariaDB, a web server, SSL, and cron. Treat that as the project's public description; verify the documentation and access terms for the actual version before deployment. A product page is not evidence that the closed beta is open to everyone.
Ownership is a practical question. Who controls the domain account? Who can reach the backups? Which person can revoke an integration? Can the site be restored if the primary developer is unavailable? Answer those before relying on the word โself-hosted.โ
Map the whole project, not just the application
Create an inventory that names the owner, provider, access method, and recovery procedure for each component:
| Component | Questions to ask |
|---|---|
| Domain and DNS | Who owns the accounts, pays for renewal, and can change records? |
| Application and theme | Which versions and packages are installed, and what do they depend on? |
| Database | Where is it hosted, who can access it, and how is it backed up? |
| Media files | Are they on the application server or in separate object storage? |
| External services | Which accounts receive data, and how can their permissions be revoked? |
The current morlix.ru site offers a concrete example: a checked blog image is served from S3 storage. That observation applies to this site's configuration; it does not mean every Morlix installation uses S3, nor that a database backup automatically contains external media.
Add email delivery, analytics, payment processing, or a CDN only if the project actually uses them. For each service, check retention, export, account ownership, and what happens if access is lost.
Agree on responsibilities
Consider a hypothetical company website. The owner pays for the domain and hosting, an agency develops the theme, and a server administrator handles infrastructure. An editor needs to publish articles but does not necessarily need server administration.
Before launch, agree who performs updates, monitors failures, makes copies, tests recovery, and communicates with the provider. Document the access inventory without placing passwords in an openly shared document. Use an agreed secure method for secrets and review permissions when a contractor leaves.
The connected Morlix management interface distinguishes read access from changes; direct management requires CMS administrator enablement and an appropriate OAuth grant. That is a boundary of the connected interface, not a guarantee of the same role settings in every future installation.
Least-necessary access is a useful operating principle, but it does not replace a support agreement or a tested handover process.
A backup is useful only if it can be restored
A database dump alone may not be a complete website. A recovery plan may also need application files, user uploads, configuration, version information, and copies of externally stored media. Determine who owns each backup and whether the retained copy can be read when the primary environment is unavailable.
Agree acceptable data loss and a target recovery time for the project. Store copies with suitable access controls and, where practical, separately from the primary environment. Test a restore in an isolated environment and check the actual pages, forms, media, and integrations afterward.
The current connected Morlix management interface lists some backup operations, but automatic backup restoration through that MCP interface is not confirmed in its capability list. This is a limit of that interface; it does not establish that other restoration methods are absent from the CMS or the hosting provider. Verify the complete procedure for the version and infrastructure you intend to use.
Plan updates as a compatibility exercise
Keep an inventory of the application, theme, and extensions, including their sources and versions. Before a significant update, check the relevant requirements and dependencies, make usable copies, and test the change in a non-production environment when possible.
A practical review includes:
- Record the current versions and important configuration.
- Check the requirements of the proposed version and its extensions.
- Confirm that database and file backups are accessible and restorable.
- Test pages, forms, media, and integrations on a copy.
- Assign an owner and a time for the production change, then check critical workflows.
These are general operational steps, not an installation guide or a claim that a one-click rollback exists. The active theme and blog module on morlix.ru show one configuration working together; they do not prove compatibility for every third-party extension.
Hosting choice does not erase dependencies
A website can run on a server chosen by its owner while relying on outside DNS, object storage, a mail provider, a CDN, or a payment service. Data may move between them. Contracts, account permissions, retention rules, and export options can differ by provider.
Map those flows before claiming that all data stays in one place. For each connection, ask what is sent, who administers the account, and how the site behaves if it is disabled. Review applicable data-handling requirements with the appropriate project specialist.
Also check licensing and migration terms for the exact application, theme, and extensions. Choosing a server does not by itself remove licensing or technical dependencies. Before promising a customer a one-click export, test what data can actually be retrieved and how a new environment would be rebuilt.
Compare self-managed and managed hosting fairly
Self-managed hosting may suit a team that wants to select infrastructure and has the skills or support to operate it. Managed hosting may reduce routine administration, but the customer should still understand access to data and backups, support boundaries, and the exit process.
Compare both options using the same list: total operational cost, responsibility for updates, control of the domain, backup location, recovery testing, support, and transfer procedures. Neither model guarantees security simply by its name.
For a pilot, start with the smallest realistic workflow: a public page, an article, media, a contact path, and a tested recovery plan. Keep assumptions separate from what you have verified on the available build.
Web studios interested in the future closed beta can apply at https://morlix.ru/; submitting an application does not guarantee access. Follow project updates at https://t.me/morlix_cms. The public release is targeted for March 11, 2027, subject to change.
Original Russian article: https://morlix.ru/blog/morlix-cms-kontrol-dannykh-samostoyatelnyy-khosting
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ full credit and traffic to the original publisher.