Field log · Backend

Firebase Functions vs a cheap VPS for a small app backend

Most of my Android apps need a tiny bit of server: a proxy that holds an API key, a webhook, a scheduled job. For years I reached for Firebase Functions by reflex. Then a couple of cases pushed me to a small VPS instead, and the honest answer turned out to be "it depends" — but on things you can actually reason about.

First, the question before the question: does your app even need a server? A surprising number don't. If your app only talks to Firebase (Auth, Firestore, Analytics) and a couple of well-behaved public APIs, you can often ship with no backend of your own at all. You start needing one the moment you have a secret the client shouldn't hold — a paid API key — or logic that has to run away from the device: a webhook receiver, a nightly job, server-side validation. That's the trigger. Until then, adding a server is over-engineering.

Once you do cross that line, the two options I actually use are Firebase Cloud Functions (serverless) and a small VPS (a plain Linux box). Here's how I choose.

Where Firebase Functions wins

For the apps I ship, serverless is the default for good reasons:

Zero servers to run. No OS to patch, no process to keep alive, no firewall to configure. You deploy a function and it exists.
It's already in the stack. My apps use Firebase Auth and Firestore anyway, so a Function that checks context.auth and reads Firestore is a few lines with no extra plumbing.
Scale-to-zero pricing. A proxy that gets called a few thousand times a month costs approximately nothing. You pay per invocation, and low traffic means a low bill.
Fast to ship. One onCall handler, one deploy, done. Perfect for the "hide an API key behind a proxy" job that most of my backends actually are.

If your need is "a small, bursty, event-driven endpoint tied to Firebase," Functions is almost always the right call and I don't overthink it.

Where a small VPS wins

But serverless has edges that a VPS doesn't, and a few of them pushed me over:

Long-running or always-on work. Functions are built for short, stateless bursts. If you need a persistent connection, a long-running process, a queue worker, or anything that shouldn't cold-start, a VPS running a normal server process is simpler and cheaper than fighting timeouts.
Predictable flat cost. Serverless is cheap at low volume but its bill moves with usage. A VPS is a flat monthly number no matter how many requests hit it — which, past a certain steady traffic, is both cheaper and easier to reason about.
Full control of the environment. Any language, any binary, any system dependency, your own cron. No runtime restrictions, no vendor-shaped constraints. If your job needs a specific tool installed, a VPS just runs it.
No cold starts. An always-on process responds immediately. For latency-sensitive endpoints that don't get enough traffic to stay warm on serverless, this matters.
Portability. A plain Linux box with your app on it isn't tied to one vendor's function format. Moving it later is copying files, not rewriting handlers.

My rule of thumb: reach for Firebase Functions when the work is short, event-driven, and Firebase-adjacent. Reach for a VPS when the work is always-on, steady-traffic, or needs full control of the machine. The API-key proxy? Functions. A persistent worker or a service that has to stay warm and predictable? VPS.

The honest cost picture

	Firebase Functions	Small VPS
Cost model	Per invocation (near-zero at low traffic)	Flat monthly (a few dollars)
Ops burden	None	You patch and monitor it
Best for	Bursty, short, Firebase-tied	Always-on, steady, full control
Cold starts	Yes	No
Lock-in	Higher	Lower

The trap people fall into is picking the VPS "to save money" while running a workload that serverless would host for pennies — and then paying in ops time to babysit a box they didn't need. The reverse trap is forcing an always-on workload into functions and fighting timeouts and cold starts forever. Match the shape of the work, not the sticker price.

If you land on a VPS

For a small app backend, you don't need much: a basic Linux instance with a couple of shared CPUs and a bit of RAM handles a proxy or a small API comfortably, and the entry tiers are only a few dollars a month. I've been running small services on DigitalOcean's Droplets because the pricing is flat and legible and the setup is unfussy — you can read more in my hosting guide, or start a Droplet directly through my referral link below.

When you use the services featured on this page, we earn a referral fee at no additional cost to you.

Start a DigitalOcean Droplet →

Whichever way you go, the decision is smaller than it feels. Don't add a backend until you have a secret or off-device logic that demands one. When you do, let the shape of the work choose: short and bursty leans serverless, always-on and steady leans VPS. Both are cheap for a small app; the expensive mistake is running the wrong shape on the wrong platform.

Pricing tiers, free quotas, and platform features change over time; confirm current specs and costs on the providers' own pages before committing.