WordPress or a custom app? Start with the runtime.
A plan that can serve a familiar CMS may still be the wrong place for a worker, a custom build, or a long-running application.
Document research and editorial guidance. No hands-on hosting tests were performed for this guide.
Compatibility comes before capacity
Before comparing storage or promotional prices, list what your application needs to execute. Include the runtime and version, database engine, required extensions, scheduled tasks, writable directories and external connections. A site builder, a WordPress installation and a custom application can have very different requirements even when their pages look similar.
WordPress publishes recommended server requirements. At the source review for this guide, these include PHP 8.3 or later, MariaDB 10.11 or later or MySQL 8.0 or later, and HTTPS support. The official requirements page also points to extension recommendations. Verify these against the current WordPress release and the actual plan you are considering.
WordPress needs an update process
Passing minimum requirements is only the start. Decide how core, themes and plugins will be updated, who investigates incompatibilities and how you will roll back a failed change. Ask whether staging is isolated and whether a restore includes both files and the database. A promise of “WordPress optimized” does not answer those operational questions.
For a relatively simple publication, a supported PHP environment with a workable backup and update process may be more useful than unused specialist features. For a store, membership site or heavily customized installation, check the limits and support scope for those particular workloads. We have not benchmarked any plan for this guide.
Custom applications need a deployment model
A custom PHP application may fit conventional hosting, but verify the PHP version, dependencies, document-root control and scheduled-job support. A JavaScript front end might be static files, or it might need a server-side Node.js process; those are different hosting needs. Background queues and long-running workers require explicit support.
Write out a deployment from source to running service. Where do dependencies install? Where do secrets live? Can you run migrations? How do you switch versions and recover from failure? If a step depends on a command or permission unavailable on the account, resolve it before purchase rather than relying on a broad “developer friendly” label.
Match support to the work
Application support and infrastructure support are different scopes. A provider may ensure the server runs while leaving your code and data migrations to you. Ask who investigates a slow database query, a plugin conflict or an application crash. Do not assume a managed plan includes debugging custom business logic.
Our editorial recommendation is to compare a small set of suitable plans using a written requirements list. A plan with fewer headline features can be a better fit when its supported deployment path is clear. If the documentation does not establish an important requirement, mark it unverified and ask a specific question. Public specification research cannot substitute for a documented test of your own application.
Sources
Related reading
- SSD or NVMe? Look beyond the storage label.
- A backup is only useful if you can restore it.
- Shared, managed, or VPS: who does the work?
- The real cost of hosting starts at renewal.
Reader discussion
No published contributions yet. Thoughtful questions and useful answers are welcome.