REST API hosting is running the server process behind your API endpoints somewhere public, with a stable HTTPS address, a database it can reach, and a way to deploy new versions without dropping requests.
The API works on your laptop. curl localhost:3000/orders returns JSON, the tests pass, and the mobile app or front end that calls it is ready to ship. What is missing is a machine that answers that request from the internet, all day, with the database next to it and the secrets kept out of the repo.
The choice of where it runs decides more than the price. It decides whether a request can take ten minutes, whether the first call after a quiet hour waits for a cold start, how the API holds connections to Postgres, and how much of the operating system becomes the team’s job to patch.
What Is REST API Hosting?
REST API hosting is infrastructure that keeps an HTTP server running, routes public requests to it over TLS, and gives it the network, storage and database access it needs to answer them. The API itself is ordinary application code: an Express, FastAPI, Rails, Django or Go net/http server listening on a port. Hosting is everything around that process.
A working setup covers four jobs. Something builds the code into a runnable artifact, usually a container image. Something runs that artifact and restarts it when it crashes. Something terminates TLS on a domain and forwards requests to the process. And something stores the data, which for most REST APIs means a relational database such as Postgres.
Hosting options differ in which of those jobs they take over, and in whether they keep one process alive or start a function per request. That split is the decision.
Where Should You Host a REST API?
Host a REST API on a platform that runs it as a long-lived server process with managed Postgres beside it, which is how Fly.io runs one: fly launch builds and deploys the existing code, and the database is a command away. That shape fits how REST frameworks are written and keeps database connections open between requests.
The options people name fall into three groups:
| Hosting model | Examples | How the API runs | Limits to know |
|---|---|---|---|
| Function platforms | AWS Lambda, Cloudflare Workers, Vercel Functions | One invocation per request, started on demand | Lambda stops an invocation at 15 minutes; Workers caps CPU time at 10 ms per request on the $0 plan and 5 minutes on paid; Vercel Hobby functions stop at 300 seconds |
| Container and app platforms | Fly.io, Render, Railway, Google Cloud Run | A server process from your code or a container image | Varies by platform and plan; lowest tiers may sleep when idle |
| Virtual private server | Any VPS provider | A process you install, supervise and patch yourself | The team owns the OS, TLS renewal, backups and restarts |
Sources: [1] [2] [3]. Checked 2026-11-02.
A VPS gives full control and makes the team responsible for everything under the code. Function platforms remove the server, at the cost of the limits in the table. Container platforms keep the API a normal server and take over the build, the restarts and the TLS.
Should an API Run as a Server or as Functions?
Run a REST API as a server unless its traffic is rare and every request is short. A server process starts once, keeps its state in memory, and answers each request from code that is already loaded. A function starts per invocation, which suits a webhook that fires a few times an hour and fits less well an API that serves steady traffic.
Request duration
A function platform enforces a maximum duration on each invocation. AWS Lambda allows up to 15 minutes in a single invocation.[1] Vercel sets a 300-second maximum for functions on its Hobby plan and 800 seconds on Pro.[3] An endpoint that generates a large export, proxies a long model response or holds a WebSocket open runs into those limits. A server process has no per-invocation limit of this kind; a request is bounded only by the timeouts of the proxy in front of it.
Cold starts
When nothing is running, the first request waits for something to start. On a function platform, an invocation after an idle period can wait for a new instance to start. On a server platform, that wait happens only if the server is set to stop when idle; keep one instance running and there is no cold start.
Database connections
REST APIs talk to a database on nearly every request. A server opens a connection pool at startup and reuses it. Functions that scale out to many concurrent invocations can each open their own connections, which is why function-based APIs usually need a connection pooler in front of Postgres. With a long-lived process, the framework’s own pool does that job.
How Do You Host an API With Its Database?
Put the API and its Postgres database in the same region, connect them over a private network, and pass the connection string to the API as a secret. Every query pays the round trip between the two, so a database in another region slows every request.
What managed Postgres takes over
Running Postgres yourself means owning backups, failover when the primary dies, version upgrades and disk growth. A managed service takes over that work. For an API, the features that matter are automatic backups, a standby that takes over on failure, and point-in-time recovery, which restores the database to the moment before a bad migration or an accidental DELETE rather than to last night’s snapshot.
Connection limits
Postgres caps concurrent connections with its max_connections setting, typically 100 by default, and sizes shared memory from that value.[4] An API running several instances, each holding its own pool, reaches that limit sooner than its traffic suggests. A connection pooler between the API and the database shares a smaller set of real connections among many clients. The Postgres hosting guide compares how managed providers handle this.
How Much Does It Cost to Host a REST API?
A small production REST API with a managed Postgres database costs around $42 a month on Fly.io’s published rates, and $38 of that is the database. The API process itself runs on one of the smallest Machine sizes.
Why API hosting bills grow
Three things move the number. The database plan sets a floor, because managed Postgres runs around the clock. Outbound data transfer grows with traffic. And on function platforms every invocation is metered, so a busy API’s bill tracks its traffic in a way that is harder to predict than a server price.
A worked example
On Fly.io’s published pricing, a REST API with Managed Postgres in Ashburn comes to $42.17 a month: one shared-cpu-1x Machine with 512 MB running continuously ($3.69), the Managed Postgres Basic plan ($38.00), 1 GB of database storage ($0.28) and 10 GB of outbound data ($0.20). Traffic between the API and the database in the same region is not billed. An API that stops its Machine when idle pays only for its root file system, at $0.15 per GB per month, during those hours.
Can You Host an API Without Paying Anything?
Yes, for a prototype, on several platforms’ $0 tiers, but their limits matter for an API other software depends on.
The common limits are sleeping and quotas. Render spins down a web service on its $0 tier after 15 minutes without inbound traffic, and spins it back up on the next request.[5] Cloudflare’s $0 Workers plan allows 100,000 requests a day and 10 ms of CPU time per request.[2]
Tiers also disappear. Heroku ended its $0 dyno and Postgres plans in November 2022, citing the effort spent fighting fraud and abuse on them.[6] An API that a mobile app or a customer integration calls belongs on a plan with a published price, so it does not change when a provider revises its tiers.
REST API Hosting on Fly.io
Fly.io runs a REST API as a server process on a Fly Machine, deploys it from the existing code, and attaches Managed Postgres with one command.
No Dockerfile to write. fly launch scans the project, detects the framework, generates a Dockerfile and a fly.toml, and deploys. For an Express API the run looks like this, abridged:
$ fly launch
Creating app in /home/dev/orders-api
Scanning source code
We're about to launch your NodeJS app on Fly.io. Here's what you're getting:
...
Wrote config file fly.toml
...
Visit your newly deployed app at https://orders-api.fly.dev/
The same command detects Python, Go, Ruby, PHP and Elixir projects, and uses an existing Dockerfile if the repository has one; the Node.js hosting guide walks through the Node.js case. Deploying without a Dockerfile covers what the generator writes.
Managed Postgres with point-in-time recovery. Managed Postgres is created with fly mpg create and connected with fly mpg attach, which sets DATABASE_URL as a secret the API reads at runtime. Every plan includes high availability with automatic failover, backups and connection pooling, and a cluster can be restored to a point in time within its recovery window, into a new cluster, leaving the original untouched. The database runs in the same region as the API and talks to it over Fly.io’s private network.
A price you can work out first. The $42.17 example above uses Fly.io’s published per-second rates, and any configuration can be priced at fly.io/calculator before deploying. Managed Postgres is a separate plan, starting at $38 a month for Basic, and it is most of a small API’s bill.
Idle APIs stop, busy ones stay up. Fly Proxy can stop Machines when idle and start them on the next request, so a staging API costs only its root file system overnight. A production API that cannot wait for a cold start sets min_machines_running = 1 and keeps one Machine always running.
Workers in the same app. A queue consumer runs as a second process group in the same fly.toml, sharing the API’s code and secrets; the background workers guide covers the pattern.
Frequently Asked Questions
Do I need a Dockerfile to deploy an API on Fly.io?
No. Running fly launch in an API project detects the language and framework, generates a Dockerfile and a fly.toml, and deploys the app. If the repository already has a Dockerfile, Fly.io builds from it instead.
What’s an API gateway, and do I need one to host an API?
An API gateway is a proxy in front of one or more APIs that handles concerns such as authentication, rate limiting and routing between services. A single REST API does not need one to go live: on Fly.io, Fly Proxy terminates TLS and routes requests to the API’s Machines, and the framework handles authentication and rate limiting in code.
Is a VPS a good place to host a REST API?
Yes, if the team wants to run the server itself. A VPS gives root access and a flat price, and it also makes the team responsible for OS updates, the reverse proxy, certificate renewal, process supervision and database backups. Fly.io runs the API on a Fly Machine and handles the build, restarts and TLS, so the team keeps the code and drops the server work.
How do I add a Postgres database to an API on Fly.io?
Create a Managed Postgres cluster with fly mpg create, then connect it to the app with fly mpg attach, which sets DATABASE_URL as a secret. The API reads that variable at runtime, and the database talks to the API over Fly.io’s private network in the same region.
Does an API on Fly.io go to sleep when nobody calls it?
Yes, by default. fly launch writes a fly.toml that lets Fly Proxy stop Machines when there is no traffic and start them on the next request, which keeps an idle staging API cheap. Setting minmachinesrunning to 1 keeps one Machine always running, so a production API does not wait for a cold start after a quiet period.
Can I host a Python, Go or Node.js API the same way?
Yes. fly launch detects Python, Go, Node.js, Ruby, PHP and Elixir projects and generates the build for each, so an API in any of them deploys to Fly.io with the same command and runs as a server process on a Fly Machine.
How do I put a custom domain and HTTPS on my API on Fly.io?
Run fly certs add with the domain, then set the A and AAAA records, or a CNAME, that the command prints at the DNS provider. Fly.io issues and renews the TLS certificate for that hostname, and every app also gets an HTTPS address on fly.dev from the first deploy.
Can the same app run a background worker next to the API?
Yes. A worker runs as a second process group in the API’s fly.toml on Fly.io, on its own Machines, from the same code and with the same secrets. A fly deploy updates both, and each group scales separately.
Sources
- ^ Amazon Web Services, “Lambda quotas”. docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html. Checked 2026-11-02.
- ^ Cloudflare, “Workers limits”. developers.cloudflare.com/workers/platform/limits. Checked 2026-11-02.
- ^ Vercel, “Configuring Maximum Duration for Vercel Functions”. vercel.com/docs/functions/configuring-functions/duration. Checked 2026-11-02.
- ^ PostgreSQL Global Development Group, “Connections and Authentication”. postgresql.org/docs/current/runtime-config-connection.html. Checked 2026-11-02.
- ^ Render, “Deploy for Free”. render.com/docs/free. Checked 2026-11-02.
- ^ Heroku, “Heroku’s Next Chapter”. blog.heroku.com/next-chapter. Checked 2026-11-02.