Installing MODX Revolution: where typical hosting breaks
Shared hosting almost always breaks a MODX Revolution installation right at the start: the set of extensions is fixed and cannot be expanded, permissions are limited to the home directory, and the web server and handler configuration is unavailable.
The owner gets a site that seems to run on demo data, but stops being manageable as soon as a custom module, a modified route, or non-standard request handling is needed.
Setting up the environment for a site on such a platform comes down to adapting the project to someone else's limits: the interpreter branch cannot be changed, memory for cache and imports is limited, and timeouts cut off long operations.
A separate pain is the lack of a scheduler: recurring tasks (cache rebuild, indexing, exports, queue maintenance) can only be set up with workarounds via external triggers, and they fail silently.
Then the question arises of why the site goes down under load. On shared hosting, requests go through a shared pool of processes and shared disk storage next to dozens of neighbors, so response times drift with no relation to your code.
The same permission restriction gets in the way of understanding the cause: logs and load graphs are unavailable, counters cannot be read, and therefore there is no data for a solution.
Added to this is the lack of state monitoring: no one watches that services are alive, that certificates are renewed, that the cache has not grown too large, and that the backup is actually taken and restored. We explain how this is closed when the site is deployed on a dedicated server under our management.
Measurable effect: response, stability, class of failures
After migration to a configured environment, response changes first: heavy query results start being served from the application cache, compression works, and the server side of MODX Revolution stops rebuilding the page on every request.
Response time goes from seconds to tenths of a second — noticeable both in measurements and in visitor behavior in the first seconds.
Stability under load is determined by settings, not hardware power. A limited pool of handlers, memory limits and timeouts, separate database connections, a queue for heavy tasks — with this separation, peak hours stop being a stress test.
At the moment of a traffic surge, the site degrades predictably: some requests wait instead of getting an error.
A class of failures that used to recur regularly is closed separately: disk overflow from logs, crashes due to the memory limit, lost file permissions, services that did not come up after a reboot.
Each such case is either eliminated by configuration or becomes observable — a metric with an alert, so the problem is known before the call.
Recovery time after a failure is measured in minutes, not hours: backups are taken on schedule and verified by restoration, configuration is stored in a repository, and rollback to the previous release is performed with one command.
Together this gives a manageable response, even behavior during peak hours, and a known set of failures instead of random ones.
Hosting options: cloud, VPS, dedicated server
When installing MODX Revolution, the environment is chosen not out of habit, but by which limits will be hit first.
On shared hosting, you cannot set your own memory limits, number of handlers, and connect a separate cache — the site lives as long as traffic and the catalog are small.
As soon as catalog search, preview generation, and scheduled background tasks appear, the bottleneck becomes not the engine, but the neighbors on the node.
How the options differ in practice
| Option | When it fits | Limitations |
|---|---|---|
| Shared hosting | Business card site, landing page, catalog with a few hundred visits per day | No access to web server and cache settings, shared limits on processes and files, PHP version set by the provider |
| Virtual server | A working site with cache, search, forms, and background tasks | Physical node resources are shared with others: disk slowdowns cause unstable response time |
| Dedicated server | Steady high load, heavy media processing, isolation requirements | Overkill if the bottleneck is in code or database queries, and requires administration |
| Cloud environment | Predictable response and growth without migration are needed | Some kernel and file system settings are closed, and there is provider lock-in |
A virtual server and a dedicated server are compared not by power, but by predictability: on rented hardware, neighbors' slowdowns are not visible in your monitoring, but they are visible to users.
That is why we select the configuration for the load profile — first we take measurements on the current hosting, then choose the option.
Implementation stages: from audit to handover to support
The work proceeds sequentially: first we record the current state, then we assemble and verify the environment, and only after that do we switch traffic. This order removes the main migration risk — site unavailability at the moment of switching.
- Audit of the current environment — inventory of add-ons, templates, and extensions, database structure, media volume, cache settings, and directory permissions. We separately record what must not be lost during migration and what is already unstable.
- Deployment work plan — VPS scheme: distribution of roles between web server, handler, database, and cache, backup procedure, maintenance window. We agree on the plan before configuration begins.
- Configuration and protection — we deploy an isolated perimeter: internal services closed from the outside, HTTPS with auto-renewal, logging, permission restrictions, control panel protection.
- Data migration and verification — files and database, reconciliation of record counts, links, and media; run-through of key scenarios: panel login, publishing, forms, search, data exchange with external services.
- Test site switchover — a copy on a test address, comparison of behavior with the current site, then lowering DNS TTL and switching traffic under observation.
- Post-switch monitoring — we watch logs, response, and task queues, and address issues based on real traffic, not test runs.
- Handover of the project to support — accesses and configurations, instructions for standard operations, procedures for updates, backups, and incident response, an assigned responsible engineer.
Configurations, backups, and maintenance procedures
After the staging environment is handed over, the client has not only a working site, but also a set of artifacts by which the system can be maintained and handed over to another engineer. Below is the minimum that we record before considering the work closed.
- Server documentation — environment diagram: list of running services, connections between them, where logs are stored and in what order to read errors if the site responds with a failure.
- Working configurations — web server, PHP, and MODX settings with an explanation of why each non-obvious parameter is set: memory limits, script execution time, caching rules.
- Panel access policies — separate accounts for administrator, content editor, and contractor, differentiation of rights, password change procedure and access revocation when an employee leaves.
- Backup schedule — what is backed up (files and database), how often, where copies are stored, how many generations are retained, and how restoration is verified.
- Content editor instructions — step-by-step scenarios for editorial tasks: create a page, upload an image, publish material, roll back an erroneous edit.
- Update procedure — procedure for installing core and add-on updates: first a run on a verification copy, then the production site, with a mandatory rollback point.
The set describes the system so that maintenance does not depend on one person: a new engineer enters the project in hours, not weeks.
Case study: how recovery time after a failure was reduced
What it was before the work
The project is a catalog with a personal account and order placement on MODX Revolution, hosted on shared hosting with server neighbors.
Backups were made manually about once a week, the copy was stored on the same disk as the production database, and no one had ever run the recovery scenario in full.
During peak sales, the site hit the allocated resource limit and went down: downtime of 4-6 hours, recovery from a copy — up to 8 hours, and some orders were lost during that time.
The environment was reassembled from memory each time, so two identical failures proceeded differently.
What was changed and what was achieved
The project was migrated to a separate server and deployed using a versioned configuration: web server, isolated database, separate processing processes, its own cache layer.
Backups became daily and automatic, one of them goes to independent storage, and once a month we restore a staging environment from it — a check that the copy actually works.
Availability and log monitoring were enabled before switching the production domain, so we learn about degradation from a system notification, not from a client call.
The recovery procedure is described and tested on a training failure — the engineer brings the site up step by step, without improvisation.
Restoring the site from a copy takes 25-30 minutes instead of eight hours, and rollback to the previous release takes a few minutes.
There have been no failures due to resource shortages during the observation period, the share of server errors fell from 2-4% to a fraction of a percent, and scheduled maintenance fits within the agreed window.
How does installing MODX Revolution differ from migrating a site?
A clean installation is deployment from scratch, when the project does not exist yet or the structure is being rebuilt for new tasks.
The engineer brings up the environment on the server, sets file permissions, configures cache and the task scheduler, connects the database, and deploys MODX Revolution.
The configuration is written immediately for the specific project: templates, chunks, plugins, access policies — without the legacy of previous solutions that later has to be untangled.
Migrating a finished site is the opposite task: reproduce a working project on a new server without losing content or settings. Files and the database are transferred, values of system parameters, domain bindings, certificates, and redirect rules are verified. Here the state is dictated by the source project, not our preferences.
Most often migration breaks on environment discrepancies: a different set of interpreter extensions, different paths to directories, an outdated cache, serialized values in settings that refer to the old address.
That is why migration of content and settings is done with before-and-after verification — first on a test perimeter, then domain switching with rollback capability preserved.
The choice is simple. A new project or a deep rebuild — a clean installation gives a predictable configuration and full control over every layer. A live site with traffic and accumulated content — we migrate it with minimal intervention in the working logic.
In both cases, the output is a staging environment that can be redeployed from documentation and a clear list of what has already been verified.
Technical concerns of clients before project start
Migrating a MODX Revolution site to a new server raises the same engineering questions — and these are the right questions: they are about risk, not distrust. We have collected the most frequently asked ones with direct answers. If your case is not on the list, we will address it separately.
Will edits in templates and add-ons be preserved?
Yes. Template files, chunks, snippets, and add-on settings are migrated as they work now, including edits made directly in the code. Before switching, we verify the composition and content on the test perimeter and show any discrepancies, if there are any.
How long will the site be unavailable during the work?
Preparation takes place on a separate perimeter, so visitors do not notice the bulk of the work. Only the final database synchronization and traffic switchover fall into the downtime window — that is minutes, and we agree on the time in advance for your minimum traffic.
Who is responsible for updates after handover?
We hand over the server together with the update procedure: what to update and in what order, how to check add-on compatibility, where the rollback point is. We go through the first update together with your team; after that you handle it yourself or give it to us for support.
What happens during a sharp traffic spike?
We configure caching and limits in advance so that the peak does not bring down the database, and we test behavior under load before switching. If growth is expected regularly, we build in a resource reserve and a clear scaling scheme.
Let's discuss the task: what is important to know before starting work
To make the conversation end with a work plan and estimate, rather than general words, our engineers need the initial project data. Some of it is usually already available from you or the current contractor — we will clarify the rest during the discussion.
- Domain and DNS: where it is registered, where it points... — skip that. I'll rewrite.
Final version: To make the conversation end with a work plan and estimate, rather than general words, the engineers need the initial project data. Some of it is usually already available from you or the previous contractor — we will clarify the rest during the discussion.
- Domain and zone: where it is registered, where the records point, who manages access.
- Infrastructure: VPS parameters, control panel, backup scheme, whether there is a separate test perimeter.
- Current state: clean server or working site, MODX Revolution branch, installed add-ons and core edits.
- Project nature: catalog, personal account, payment, data exchange with the accounting system — deployment preparation depends on this.
- Load and content: peak visits, number of pages and media, publishing frequency, behavior during updates.
- Reliability requirements: acceptable downtime, backup retention depth, who accepts releases.
- Room for the future: new sections, languages, catalog growth — so that the configuration does not require a rebuild in six months.
Describe the site task in free form — we will discuss it, ask clarifying questions, and come back with an estimate and work plan.
If some data is missing, it does not block the start: an engineer's consultation at this stage is exactly what is needed to separate the critical from the secondary and avoid overprovisioning.
