Six demands that a normal website never makes. Read them before you compare plans, because they are what separates an AI project that stays up from one that gets rate limited by its own hosting.
AI libraries break on minor releases. A tokenizer bump or a client SDK upgrade can change your output overnight. You need to choose the interpreter version and freeze the dependency set, not inherit whatever the server was rebuilt with last week.
Embedding a document set, re-indexing after an upload, retrying a failed generation: none of it fits inside a browser request. It belongs in a worker that keeps running after the visitor has closed the tab, which is a very different hosting requirement.
Retrieval needs an index. That can be pgvector in Postgres, a SQLite file, or a dedicated engine such as Qdrant, Weaviate or Milvus. Each one wants memory and steady random reads, and the honest answer about which will fit depends on how many documents you are chunking.
A model API answering in eight seconds is normal, not broken. Your web server, your PHP or Node timeout, your proxy and your browser all disagree about that. Getting the timeouts, retries and keep-alive settings to agree is most of the work in shipping an AI feature.
Token by token streaming means one visitor holds a connection for the length of the answer. Ten people chatting at once is ten concurrent connections doing almost nothing, which is exactly the pattern that shared hosting concurrency caps are designed to stop.
A model API key in front end JavaScript is a bill somebody else can run up. Keys belong in a file outside the web root or in an environment file that the server refuses to serve, with every call proxied through your own back end so you can rate limit and log it.
No hosting company can put every column below on a starter plan. Sorting your components into these three buckets first will save you a migration later.
| Runs well on shared cPanel hosting | Needs a cloud VPS with root | Needs a GPU or a model API |
|---|---|---|
|
|
|
The three engineering problems behind almost every support ticket we see from teams doing hosting for AI apps.
A retrieval setup has four moving pieces: an ingestion job that chunks your source documents, an embedding call that turns each chunk into a vector, a store that holds those vectors, and a query path that fetches the nearest matches and passes them to the model. Three of those four are cheap. Ingestion is the one that hurts, because it is bursty, it can run for hours, and it hammers storage while it works. Build it as a job you can start, stop and resume from a shell rather than something a web request triggers, and the rest of the stack becomes ordinary web hosting. Teams building the same pattern with visual tooling usually pair this page with our managed n8n automation plans, where the workflow engine itself is the long running process.
A generation that takes twelve seconds will be cut off by at least one thing between your code and the visitor unless you go and change it. PHP has a script execution limit. LiteSpeed has its own connection timeout. Cloudflare, which sits in front of every ElySpace site, closes a request that produces no bytes for too long. The fix is not a bigger timeout everywhere: it is to stream the first bytes early, or to accept the request, hand it to a worker, and let the browser poll or subscribe for the result. Decide which of those two patterns you are using before you pick a plan, because streaming holds a connection and polling does not.
ElySpace publishes its shared hosting ceilings rather than hiding them, and for AI work the numbers matter more than the marketing. Entry plans are capped by CloudLinux at the figures below, and the rules that follow are policy, not preference. If your design collides with any of them, you are looking at a cloud VPS, and it is cheaper to learn that now than after a suspension.
The full text, including the clauses on real time chat applications and web crawlers, is in our shared hosting resource limits. Read the chat and spider clauses in particular if you are planning a support bot or an ingestion crawler, because both are named there and both are expected to live in a dedicated environment.
Four steps, in the order that avoids rework. Step one is the one people skip, and it is the one that decides everything else.
Write every component of your app into one of the three columns above. The heaviest column decides the plan.
A front end only build fits shared hosting. Anything resident, containerised or streaming starts on a cloud VPS.
Push over Git, pin your dependency versions, put keys in a file the server will not serve, and schedule the jobs.
cPanel shows your live CPU, memory and entry process usage. Move up before the graph flattens against the ceiling.
A GPU is only required where the model weights sit on your own machine. If you are calling a hosted model over an API, every heavy tensor operation is happening in somebody else's datacentre and your server is doing string handling, JSON parsing and database writes. That is CPU work, and a few virtual cores go a very long way. Where teams genuinely get stuck is not compute, it is permission: they need to run a daemon, open a port, install a system package or keep a process alive, and no shared account anywhere will let them. That is why the realistic upgrade path for an AI project is a scalable cloud server or a root level VPS plan rather than exotic hardware. If your project really does need GPU accelerated configurations, they are not a published ElySpace plan, so talk to our team about what you are trying to run and we will tell you honestly whether we can help.
Send us the shape of your stack: the framework, the model API you are calling, whether anything needs to stay resident, and roughly how many documents you are indexing. We will tell you which ElySpace plan fits and, just as usefully, when it does not. Live chat and tickets are open 24/7, and free migration applies if you are moving a working AI app from another host. Every plan is covered by the 99.9% uptime commitment set out in our service level agreement, and runs on LiteSpeed Enterprise, CloudLinux, cPanel, Imunify360, JetBackup and NVMe SSD storage. If you would rather start with the fundamentals, our cPanel hosting overview covers the shared platform, while plans with dedicated cores suit a front end that is already busy.
That's probably enough from us, we'll let our customers do the talking and with over 2000 reviews on Trustpilot and Facebook, see for yourself why you can trust us to power your website.