AI Hosting for Inference, RAG and Automation Stacks

  • cPanel on CloudLinux
  • NVMe SSD Storage
  • Full Root on Cloud VPS

Work out what your AI app really needs before you pay for it.

Most products described as AI apps are ordinary web applications with one slow, expensive HTTP call in the middle. The model runs somewhere else. What you are actually hosting is a front end, a queue, a store of embeddings and a pile of API keys. That mix behaves nothing like a brochure site, and it is the reason so many AI side projects get throttled or suspended in their first month. This page sets out, plainly, which parts of an AI stack run happily on ElySpace shared hosting, which parts need a cloud VPS with root, and which parts nobody can run without a GPU.

What an AI workload asks of a host

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.

Pinned runtime versions icon

A runtime you can pin

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.

Background worker process icon

Work that outlives the request

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.

Vector database storage icon

Somewhere to keep the vectors

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.

Slow outbound API request icon

Outbound calls that are slow on purpose

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.

Streaming connection icon

A connection that stays open

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.

Secret API key protection icon

Keys that never reach the browser

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.

Where each part of an AI stack belongs

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
  • Your product site, docs and pricing pages
  • A front end that calls a model API per request
  • Sign up, auth and billing screens
  • Prompt and response logs in MySQL
  • Batch jobs on a cron, no faster than every 15 minutes
  • Queue workers and schedulers that stay resident
  • A self hosted vector database with its own daemon
  • Websocket and server sent event endpoints
  • Docker, systemd and a Python version you chose
  • Crawlers and ingestion jobs that build the index
  • Training or fine tuning a model of your own
  • Serving a large open weight model at chat latency
  • Real time speech, image or video generation
  • Embedding millions of documents in one pass
  • Anything whose install guide starts with CUDA

Vector stores, timeouts and
the jobs that never end

The three engineering problems behind almost every support ticket we see from teams doing hosting for AI apps.

Anatomy of a RAG stack,
and the part that hurts

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.

Diagram of an ingestion job feeding an embedding store and a query path

Why AI requests break
everybody's default timeouts

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.

Fast server response illustration for streamed AI answers

The shared hosting limits,
in numbers, before you build

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.

  • 100% of one CPU core and 1024 MB memory on entry plans
  • 10 entry processes, which is your real concurrency ceiling
  • 10 MB/s IO and 1024 IOPS, shared with your database
  • Cron no more often than once every 15 minutes
  • Web processes may not fork or spawn subprocesses
Server control panel showing resource limits and root access

How to get an AI app live
on ElySpace

Four steps, in the order that avoids rework. Step one is the one people skip, and it is the one that decides everything else.

01

Sort the pieces

Write every component of your app into one of the three columns above. The heaviest column decides the plan.

02

Pick the plan

A front end only build fits shared hosting. Anything resident, containerised or streaming starts on a cloud VPS.

03

Deploy and pin

Push over Git, pin your dependency versions, put keys in a file the server will not serve, and schedule the jobs.

04

Watch the meters

cPanel shows your live CPU, memory and entry process usage. Move up before the graph flattens against the ceiling.

GPU or CPU: the question most AI projects get wrong

You probably do not need a GPU. You almost certainly do need root.

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.

Virtual server with dedicated cores and memory for AI application workloads
Tell us what you are building

Not sure which column your project lands in?

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.

Talk to an Engineer Open a Ticket
ElySpace support engineer reviewing an application stack

Read our customer reviews

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.

AI Hosting FAQ's

AI hosting is ordinary web hosting sized for three unusual habits. An AI application makes slow outbound calls that can run for many seconds, it often needs a process that keeps working after the visitor has gone, and it stores embeddings that are read constantly. A brochure site does none of that. The infrastructure underneath is the same LiteSpeed, CloudLinux, cPanel and NVMe platform we run for every customer. What changes is the plan you need and how you architect the app on top of it.

It depends entirely on what the app does, not on the language. A request and response script that calls a model API and writes to MySQL is a good fit. A Python service that expects to bind its own port, run under systemd or spawn worker processes is not, because shared accounts have no root and web processes are not permitted to fork or spawn subprocesses. Open a ticket with your requirements before you buy and we will confirm which interpreters and selectors are enabled on the plan you are looking at.

GPU accelerated configurations are not a published ElySpace plan. Our shared, cloud and VPS ranges are CPU based, which is the right shape for applications that call a hosted model over an API rather than running weights locally. If your project genuinely needs local inference or fine tuning, contact our team, describe the model and the latency you need, and we will tell you plainly whether we can put something suitable together or whether you are better served elsewhere. We would rather say no than sell you a server that cannot do the job.

Yes, on a cloud VPS, where you have root and can install the engine as a service. Qdrant, Weaviate, Milvus and Postgres with pgvector all run as their own daemons and need a persistent process, so they belong on a VPS rather than a shared account. If your corpus is small, a file backed index such as SQLite or a flat vector file living inside your application directory will work on shared hosting, subject to the same IO and inode limits as any other file. Size the memory around your index, not your page views.

No. Plan for scheduled runs instead of a resident daemon. Shared accounts have no root, no systemd and no supervisor, so nothing keeps a long lived worker alive or restarts it after a reboot. What you do get is cPanel cron, which cannot fire more often than once every 15 minutes. That is enough for nightly re-indexing or a batch that drains a queue on a schedule. It is not enough for near real time processing. If your product promises a result in seconds, the worker needs a VPS.

Treat any persistent connection as a VPS feature. On a root server you control the web server, the proxy configuration and the ports, so websockets and server sent events are yours to configure. On shared hosting each open connection counts against a small entry process allowance, so a handful of simultaneous chats can exhaust the plan while using almost no CPU. If streaming is central to your interface, start on a cloud VPS. If it is a nice to have, fall back to polling for the result and shared hosting will cope.

Prompt and completion traffic is text, so the volume is usually trivial. A long conversation is measured in kilobytes, and thousands of them will not trouble a hosting plan. The exception is media: uploading audio for transcription, or pushing images through a vision model, moves real bytes in both directions and should be estimated properly. Anything that needs an unusual outbound port rather than standard HTTPS should be raised with support first, since shared platforms restrict outbound ports by default.

Read the chat clause in our resource usage policies before you build it. Interactive real time chat applications are named there as prohibited on shared hosting, alongside web spiders and indexers, and the policy states that workloads of that kind belong in a dedicated environment. That covers a self hosted support bot and it covers the crawler you might write to feed it. Put both on a cloud VPS. A widget that simply posts a form and shows an answer is a different thing, and that is fine on shared.

Never in front end JavaScript, and never inside the document root without a deny rule. Keep keys in a dotfile or a directory above public_html, and make sure your .htaccess denies requests for filenames beginning with a dot so an environment file can never be served. Proxy every model call through your own back end so you can rate limit it, log it and rotate the key without redeploying a client. Imunify360 and the platform firewall protect the server; only your application design protects the key.

You will hit the entry process ceiling long before you hit the CPU ceiling. AI requests spend most of their life waiting on somebody else's API, so the graph in cPanel shows connections stacking up while the processor sits idle. Watch the entry process meter, not the CPU meter. When it starts flattening, move the application to a cloud VPS with dedicated cores and keep the static front end where it is. Free migration is included, and our team can move files, databases and cron entries for you.