Where to host an API: Projects or a VPS for your backend

If your app needs to store data, sign users in or run custom logic, it probably needs an API reachable from the internet. Hosting does not depend on whether the frontend uses Flutter, React Native, React or an AI coding tool. It depends on what process the backend runs and who you want to operate it.

Hostbrid has two common options for an API: Projects, which builds from a repository and runs a compatible service, and a VPS, where you administer the system and software stack. This guide helps you rule out the wrong fit before buying. For mobile apps, also see API hosting for iOS and Android.

Choose Projects when your API fits the service

Projects can be the more direct route if you have a Git repository, the backend starts as a compatible Node.js service or container, and you prefer managed build and deployment. Connect GitHub, GitLab or Bitbucket, then review deployment status and logs. Services that need to stay online require the appropriate paid plan and resources; check current terms on the Projects page.

Before choosing it, identify the start command, the port the process must listen on, environment variables and external services. Confirm where persistent data lives and whether the process needs scheduled jobs, system access or volumes outside the plan. Keep secrets out of the repository.

Choose a VPS when you need to administer the system

A VPS gives you root access to install runtimes, Docker Compose, a proxy, workers or system tools. It fits deployments that depend on configuration you need to control or several processes you want to connect yourself.

That control comes with work: updates, firewall, users and permissions, certificates, monitoring, off-server backups and restore tests. A VPS does not operate the API for you or make an insecure setup safe by default. If you do not want that operational work, consider Projects for a compatible backend or ask for help before ordering.

Match your application to the hosting model

What you need to run	First option to check	Confirm before paying
Static frontend with no server process	Projects	Build command, output directory, routes and external service calls
Node API connected to Git	Projects	Runtime, start command, port, variables, persistence and plan resources
Backend with a Dockerfile	Projects or VPS	Container compatibility and storage; VPS if you need host-level control
Docker Compose with multiple services	VPS or Projects, depending on project support	Networking, persistent data, resource use, backups and plan limits
Python, PHP or another runtime with system dependencies	VPS unless the Projects offer confirms that runtime	Version, system libraries, startup process and maintenance
Production database	Compatible managed service or one you operate	Backups, restore, private access, storage and update policy

This table is guidance, not a universal compatibility guarantee. Check current product documentation and terms for your exact runtime and plan. If an app needs a database, do not assume publishing its API also provisions, migrates or backs up the data.

Inventory the project before choosing

Open the repository and write down:

How it starts: check package.json, Dockerfile, compose.yaml, pyproject.toml or other runtime files. Find the production command, not just the development server.
What it listens on: the API must accept the port assigned by its environment and respond on a public HTTPS URL. localhost on a phone points to the phone, not the server.
What it stores: separate database, user files, cache, queues and logs. Decide who backs them up and how to restore a sample.
Which credentials it uses: keep private keys in server-side variables. A value included in an iOS or Android bundle can be extracted and is not a secret.
Which permissions it enforces: every endpoint must validate identity, authorization and input on the server. Hiding a button in the app does not protect the operation.
How much capacity it needs: measure memory, CPU, disk and concurrent requests with a representative test before selecting resources.

Test the API before connecting the app

A 200 status page does not prove the user flow works. From an external network, test at least one public route, one authenticated route and expected responses for an expired session, invalid input and rate limits. Check HTTPS, DNS, logs and that a database outage does not expose sensitive information.

In the mobile app, replace the development address with the production domain and test a release build on iOS and Android. Do not ship private keys; keep database, payment and external-service credentials on the server. If a web frontend also calls the API, configure CORS for the required origins: CORS does not authenticate the API or protect native app requests.

For a self-managed FastAPI backend, follow Uvicorn and Nginx on a VPS. For a Node API, see how to host a Node.js app. If you do not know whether your code is static or needs a server, start with debugging an API that works locally but fails in production.

What to do next

If the backend is compatible and you want Git-based deployment, review Projects. If you need root access or control of Docker and the operating system, compare VPS options and operate your own updates and backups. If you are unsure which runtime your project uses, share its start command and required services with support before buying. Do not send tokens, passwords or customer data.