Backend Hosting: What a Backend Actually Needs From a Host, and Why Static Hosting Is Not Enough

Backend hosting is different from website hosting because a backend is a running process, not a folder of files. It needs a runtime that stays up, environment variables for its secrets, a database it can reach privately, logs you can read when a request fails, a way to roll back a bad deploy, and a public route with a certificate. Static hosts give you none of that, free tiers give you some of it until the process falls asleep, and the choice between a platform, a VPS and a container cluster comes down to how much of the list you want to own yourself.

The pages that rank for this term are either vendor landing pages or a forum thread asking where to host a backend for free. Both skip the useful part. The vendor page assumes you already know what you need; the thread assumes free is the goal and lists whatever survived last month. This post is the list of what a backend needs, the four shapes hosting comes in, and the numbers that tell you which shape you are in.

Table of contents

• Why backend hosting is a different question from website hosting
• The seven things a backend needs from its host
• The four shapes backend hosting takes
• How to size a backend
• What a small backend costs
• Mistakes that show up in the first month
• How this fits the rest of the stack
• FAQ

Why backend hosting is a different question from website hosting

A website is a set of files. Put them on a CDN and the job is done: no process, no memory, no state, nothing to crash at 3am. That is why static hosting is cheap, and why it is the wrong place to look for a backend.

A backend is a process. It starts, binds a port, holds connections open to a database, keeps things in memory, and stays running until something stops it. Every one of those verbs is something the host has to support. A host that only serves files cannot run a process, and a host that runs a process but puts it to sleep after fifteen idle minutes has technically solved the problem while practically creating a new one.

The AI-generated frontend made this a common question. The interface looks finished after an afternoon. Then the form needs somewhere to send its submissions, the login needs a session store, and the prototype discovers it has rent due. That moment is what backend hosting is for.

The seven things a backend needs from its host

Write these down and score every candidate against them. Most backends use all seven whether or not anyone decided to.

1. A runtime that stays up. The process runs continuously, restarts when it crashes, and is not put to sleep for being quiet. Sleeping runtimes turn every first request after a lull into a ten-second cold start, which users read as broken.
2. A build from the repository. Push a commit and the host installs dependencies, builds, and starts the new version. Without this the deploy is a manual SSH session, and manual deploys stop happening at the exact moment the project gets busy.
3. Environment variables. Database URLs, API keys and the secret that signs sessions belong in the environment, not in the repository. The host needs a place to set them per service and per environment.
4. A database it can reach privately. The backend and its database should talk over a private network, not the public internet. A database with a public IP and a password is a database waiting for a credential leak.
5. Logs from the build and the runtime. When a request fails, you need the stack trace. When a deploy fails, you need the build output. A host that shows you neither has turned every bug into archaeology.
6. Rollback. The deploy that broke production at 5pm needs to be gone by 5:02pm. Keeping previous builds and switching back in one click is a basic feature, not a premium one.
7. A route with a certificate. A public URL, HTTPS handled, and a custom domain when you are ready. The API that runs on a raw IP over HTTP is not shippable.

Autoscaling, cron jobs, persistent disk and a worker process are the next tier. They matter, but a host that skips two of the seven above cannot be rescued by having them.

The four shapes backend hosting takes

Every option is one of four shapes. The shape decides the maintenance load and the bill far more than the vendor does.

Serverless functions. The backend is split into functions that run on request and vanish after. Excellent for a handful of endpoints with bursty traffic, awkward for anything that holds a connection open, runs a long job, or needs a warm database pool. Cold starts and per-invocation billing are the shape’s two permanent trade-offs.

A platform (PaaS). You push a repository; the platform builds it, runs it as a managed process, and gives you the seven items above from a dashboard. This is the shape most small backends should be in. The cost is a fixed monthly plan per service, and the trade-off is that you configure within the platform’s model rather than at the OS level.

A VPS. A Linux machine with a public IP. Everything on the list is yours to build: the process manager, the reverse proxy, the certificate renewal, the log rotation, the backups, the security patches. It is the cheapest shape on paper and the most expensive in hours, and the hours arrive at inconvenient times.

A container cluster. Kubernetes or an equivalent. The right shape for a team running many services with a platform engineer to look after it, and a costly mistake for a two-person startup running one API. If you do not already know you need it, you do not.

How to size a backend

Sizing is the step people skip, then over-pay for by a factor of three. Three numbers decide it.

• Memory at idle plus headroom. A Node or Go API sits at 60-150MB idle. A Python service with a heavy framework sits at 150-300MB. A JVM wants 512MB before it has done anything. Add the peak you saw under load and choose the plan one notch above.
• CPU as a fraction. Most backends are I/O bound: they wait on the database and the network. A half vCPU serves thousands of requests a minute for a typical CRUD API. Give a full core to anything that renders, transforms images, or does work in the request path.
• Database connections. Each backend instance opens a pool. Two instances with a pool of twenty is forty connections, and a small managed Postgres may cap at a hundred. Size the pool before you size the instance count.

Measure, do not guess. Run the backend locally under a modest load test and read the memory and CPU it actually used. The number is usually smaller than the plan people buy.

What a small backend costs

Using RunxBuild’s general ladder, since those are the numbers I can vouch for: a Dev plan at 0.3 vCPU and 624MB is $4 a month, Basic at 0.5 vCPU is $6, BasicMini at 1 vCPU and 1GB is $13, and BasicPlus at 1 vCPU and 2GB is $20. A managed Postgres beside it uses the same ladder. There is a free plan with fifteen free days a month, which is enough to find out whether the project is real.

So a typical first backend is a Basic service and a Basic database at $12 a month, with a build log, a live route, environment variables, private networking between the two, runtime logs and rollback included. That is the whole list from the section above, with no VPS to patch. Scale up when the metrics say so, not before.

The comparison to a VPS is not the sticker price; a small VPS costs about the same. The comparison is the Saturday you spend on it.

Mistakes that show up in the first month

Having watched a lot of first backends go live, the failures cluster.

• Binding to localhost. The process listens on 127.0.0.1 and the host’s router cannot reach it. Bind to 0.0.0.0 and read the port from the environment.
• Hardcoded database host. The connection string points at localhost because that is where Postgres lived on the laptop. It belongs in an environment variable, and the value is the private hostname the host gives you.
• No health endpoint. The host cannot tell whether the process is alive. Add a route that returns 200 and checks the database connection.
• Logging to a file. The file lives on an ephemeral disk and vanishes at the next deploy. Log to stdout and let the host collect it.
• One giant instance. Sizing for the peak you imagine rather than the peak you measured. Start small and let autoscaling or a one-click plan change handle the day the traffic actually arrives.

A prototype without logs is a mystery with a URL. Most of the list above is about making the backend observable before it is popular.

How this fits the rest of the stack

A backend is the part of the project that turns a demo into a product, and it is also the part that carries the recurring bill. Before choosing a shape, model the service, the database, the storage and the bandwidth together in the RunxBuild hosting calculator, because the backend rarely arrives alone. Then push the repository, read the build log, and keep the runtime logs close for the first week. See services on RunxBuild for what the deploy path looks like, and open the dashboard when the first version is ready to ship.

Useful related references:

• App Hosting: What It Is, How It Differs From Web Hosting, and What You Actually Pay For
• Application Hosting vs Web Hosting: The Decision Tree, The Cost Difference, and The Traps
• Backend as a Service Providers: The Four Real Options, the Lock-in Story, the Cost, and the One That Fits a 5-Person Team
• Services on RunxBuild

FAQ

Can I host a backend on static hosting?

No. Static hosting serves files and cannot run a process. Some static hosts bundle serverless functions, which can cover a few endpoints, but a backend that holds database connections, runs jobs, or keeps state needs a runtime that stays up.

Is free backend hosting worth using?

For finding out whether a project is real, yes. For anything users depend on, the free tiers that sleep after idle turn every first request into a cold start. RunxBuild’s free plan gives fifteen free days a month with the same features as paid plans, which is a cleaner way to test than a permanently sleeping tier.

Should the database be on the same host as the backend?

On the same private network, not the same machine. A managed database on the same platform gives you private networking, backups and connection limits without sharing the backend’s memory and disk.

How much RAM does a small backend need?

Measure it. A Node or Go API usually idles at 60-150MB, a Python service at 150-300MB, and a JVM wants 512MB before it starts. Pick the plan one notch above your measured peak; the 624MB Dev and Basic plans cover most first backends.

What is the difference between backend hosting and a VPS?

A VPS is a shape of backend hosting where you build the runtime, proxy, certificates, logs and backups yourself. A platform gives you those as features. Both run the same code; the difference is who maintains the layer under it.