An API backend needs less from a host than the market implies: a process that stays up, a database, secrets storage, a deploy path, and TLS. Most managed platforms can do all five.
A Node.js API backend is a long-running process that answers HTTP requests and returns JSON. It does not need a dedicated server, a container orchestrator, or a platform priced per instance. It needs somewhere that keeps the process alive, gives it a database and a domain, and redeploys it when the code changes. Node.js server hosting on a managed shared plan covers that, provided you know where the ceiling is.
Key takeaways:
- Five things decide whether a host can run an API backend: a supervised process, a database, environment variables, a deploy path, and TLS on your own domain.
- “API hosting” is used for three different products. Only one of them, application hosting, actually runs your code.
- The question that matters more than framework choice is how much your API needs you to operate it after it goes live.
- SiteGround runs Node.js projects on GrowBig (up to 5 projects), GoGeek (up to 10), and Cloud (unlimited). The StartUp plan does not support Node.js.
- Node.js versions 18, 20, 22, 24, and 26 are selectable per project, with npm, yarn, and pnpm all supported.
- A request-response API fits a shared plan. Anything holding an open socket per client does not, on any shared host at any price.
What an API backend actually needs from a host
Strip away the marketing and an API backend has a short requirements list. Check your own service against it before you compare providers, because most of the differences between hosting products sit above this line, not below it.
- A process that stays up. Your API starts once and answers every request from memory. Something has to restart it when it exits.
- A database it can reach. Usually relational, usually on the same network, ideally not a separate subscription.
- Somewhere to put secrets. API keys and connection strings belong in the host’s environment settings, never committed alongside your code.
- A deploy path you will actually use. If shipping a change is tedious, you will ship fewer of them.
- TLS on a domain you control. Mobile clients will not talk to an untrusted certificate, and most will not talk to plain HTTP at all.
- Logs when a deploy fails. Build output you can read is the difference between a five-minute fix and an afternoon.
Notice what is missing. Horizontal autoscaling, container control, and a private network are real requirements for some services. However, for many early-stage mobile apps, those capabilities are headroom rather than baseline requirements, so paying for them before the workload demands them can add unnecessary cost and operational complexity.
What “API hosting” actually means
The phrase covers three different products, and search results mix them freely. Knowing which one you are being sold saves a lot of wasted evaluation time.
API hosting compared with API gateways and API management
API hosting is application hosting. The provider runs your code as a live process and routes traffic to it. This is what you need if you have written an Express, Fastify, NestJS, or Koa service and it has to exist somewhere.
An API gateway sits in front of an API that already exists. It handles routing, rate limiting, authentication, and request transformation. A gateway does not run your code, and buying one when you needed hosting leaves you with a very capable front door and nothing behind it.
API management is the commercial layer on top: developer portals, usage plans, billing, and analytics for APIs you expose to third parties. It matters when your API is the product. It is irrelevant when your API exists to serve your own front end.
For most teams shipping a mobile app or an internal tool, the answer is the first one, and the other two are problems for a later year.
Where an API backend can live
Four models can run a Node.js API. They differ less in capability than in how much of the operational work they hand back to you.
Application platforms
Platforms built specifically to run application code give you the most headroom: horizontal scaling, WebSocket support, container-level control, and regional deployment. They are the correct answer for a service with real concurrency demands or persistent connections. The trade is that pricing is metered, the database is usually a separate product, and a domain, mailboxes, and backups are yours to arrange.
Managed shared hosting
A managed shared plan runs your Node.js application as a supervised process alongside the rest of your hosting account. You get a fixed monthly price, a database, a domain, and email in the same place. The control panel covers the deployment, and the familiar hosting tools sit underneath it: a file manager, scheduled jobs, and SSH access to your own account. What you do not get is a server to administer. For a request-response API that is mostly upside, because there is less to configure and less to leave misconfigured.
A VPS
A virtual private server gives you root, and with it every decision: the operating system, the process manager, the reverse proxy, the certificates, and the patching schedule. Choose it when you genuinely need that control. Choosing it by default means you have taken on a systems administration job in order to host a JSON endpoint.
Serverless functions
Functions suit spiky, short-lived work: webhook handlers, scheduled jobs, image processing. They suit a conventional REST API less well, because a persistent database connection, an ORM, and a per-invocation execution model fight each other. Many teams that start an API on functions migrate it to a long-running process within a year.
| Model | You operate | Best fit for an API backend |
| Application platform | The app, and the services you attach to it | High concurrency, WebSockets, regional scaling |
| Managed shared hosting | The app only | Request-response APIs alongside other sites |
| VPS | The app, the server, and the stack | Custom system requirements, full control |
| Serverless functions | Individual functions | Event-driven and scheduled work |
What it actually costs to host an API backend
The advertised price of an application platform is rarely the amount you pay. Work out the total before comparing, because the shape of the bill differs more than the headline figure.
What free tiers cost you in cold starts and sleep
Free and entry tiers on most application platforms suspend an idle process. The next request has to wait for it to start again, and that wait is measured in seconds rather than milliseconds. On a web page it reads as slow. On a mobile client with a timeout it reads as a failure, and your user sees an error rather than a spinner. This is the cost that never appears on a pricing page, and it is worth measuring on any host you are considering: deploy something, leave it alone for an hour, then time the first request yourself.
What you pay for on a metered platform once the database is added
Metered platforms bill the running instance, then bill separately for the parts an API needs anyway. A managed database is typically its own line item. A custom domain has to be bought elsewhere. Mailboxes on that domain are usually not offered at all. Egress and build minutes may be metered on top. None of this is hidden, but it is easy to compare an instance price against a hosting plan price and conclude the platform is cheaper.
What a fixed-price plan covers
A shared hosting plan bundles the pieces. The database, the domain, email on that domain, TLS, daily backups, and a WAF come with the plan rather than alongside it, and the price does not move with traffic. For an API that serves a mobile app with a few thousand users, predictable beats elastic. The ceiling is real, but you reach it later than most people expect, and you reach it knowing exactly what the next tier costs.
When a shared plan is the wrong home for your API
This is the section most hosting comparisons skip. A managed shared plan is a poor choice for several kinds of API, and finding that out after migrating is expensive.
- Your API holds open connections. WebSockets are not supported on any SiteGround plan, because opening a custom port for incoming connections is not permitted. This applies across shared hosting, and we cover what shared plans can and cannot run in more detail separately. Long polling over HTTP and HTTPS is the documented alternative and is adequate for infrequent updates, not for a live feed.
- You need to operate the live process. You get a build log for every deploy and an HTTP error log for traffic that reaches the app. What you do not get is a managed application log: your own console output is not surfaced in the panel. You can write it to a file and read that over SSH, but if you expect to tail a live process or attach a debugger, a VPS will suit you better.
- Your data store is not relational. MySQL and PostgreSQL are both available. A document store such as MongoDB means connecting to an external managed service and accepting the latency that adds.
- Your traffic is genuinely large or genuinely spiky. A shared plan is a fixed slice of a shared machine. An API under heavy sustained load wants dedicated resources, not a bigger shared allocation.
Running a Node.js API backend on SiteGround
Which plan your API needs
The StartUp plan does not support Node.js, so availability begins on GrowBig. GrowBig runs up to 5 Node.js projects, GoGeek up to 10, and Cloud is unlimited. Count your projects before you pick a tier, and remember that a staging copy of your API counts as a project of its own. A team running one production API and one staging environment per client reaches the GrowBig limit at two or three clients, which is usually what moves an agency up rather than disk space.
Getting your API deployed
Connect a GitHub repository and every push to the linked branch rebuilds and redeploys the service, which is the path worth using for anything under active development. Uploading an archive works too but has no auto-deploy. The mechanics are the same for any Node.js application and are covered in our guide to Node.js support on shared hosting.
The part specific to an API is the environment settings. Database connection strings, third-party API keys, and signing secrets are configured against the project rather than committed to your repository, which also means a staging deployment can point at a different database without a code change.
The database, and pointing a client at it
MySQL and PostgreSQL are both created and managed from Site Tools. PostgreSQL is the one worth noting, because it is uncommon on shared plans and it means an API written against Postgres with Prisma, TypeORM, or Sequelize deploys without a rewrite or a separate database subscription. MongoDB is not available, so a document-store API connects to an external managed service.
Every project starts on a temporary domain, which is more useful for an API than it sounds. Your mobile or front-end client can point at that endpoint and exercise the real service while DNS for your own domain is still pointing somewhere else. Attach your domain when the client is ready, and the API keeps answering on a certificate you control.
Choose the hosting model your API actually needs
If your API answers HTTP requests, you can live without WebSockets, and you would rather not be responsible for the server underneath it, SiteGround Web Hosting covers Node.js server hosting from GrowBig upward, with the database, domain, email on that domain, daily backups, and a WAF included rather than bought separately.
The right hosting choice is the simplest one that meets your API’s actual requirements without making you operate infrastructure you do not need.
Frequently asked questions
You can host a Node.js server on a managed shared plan, an application platform, a VPS, or serverless functions. For a request-response API, a managed shared plan is the simplest option that still gives you a database and a domain in the same account. Choose an application platform if you need WebSockets or horizontal scaling, and a VPS if you need root access to the machine.
The cheapest option that stays viable is usually a fixed-price shared plan that already includes a database and a domain, because those are the costs that accumulate elsewhere. Compare total monthly cost rather than instance price: a low platform tier plus a managed database plus a domain frequently exceeds a hosting plan that bundles all three.
Free tiers are well suited to prototypes, demos, and learning projects. They are a poor fit for an API that another application depends on, because free plans generally limit resources, and the database is usually the first thing you outgrow. Move to a paid plan before real users depend on the endpoint, not after.
For development and staging, the best service is the one that matches your production environment most closely, so that a deploy does not reveal differences. If your production API runs on a managed platform with a selectable Node.js version and a relational database, use the same combination in development. Matching the Node.js major version matters more than most teams assume.
Yes. A GraphQL server is a request-response HTTP service like any REST API, and it runs as a standard Node.js application. The exception is GraphQL subscriptions, which rely on persistent connections and will not work where WebSockets are unavailable.
Yes. Once the API has TLS on a domain you control, a mobile client can call it directly. Point the app at your own domain rather than the temporary one issued at project creation, so the endpoint does not change when you attach your domain.