Serverless Functions on Traditional Hosting: What Works and What Doesn’t

Serverless sounds futuristic and complicated. It is neither. AWS Lambda, Cloudflare Workers, Vercel Functions – they are all just little bits of code that run when a request comes in, and disappear when it ends. No server to manage. No scaling to configure. Pay only when code actually runs.

The catch: most of those run on someone else’s platform. If you already pay for traditional hosting – a VPS, shared hosting, a dedicated box – can you run serverless on top of it? Should you?

The answer is yes, with caveats. Let us walk through what works, what does not, and when mixing the two is the right move.

What Serverless Actually Is

Three properties define a serverless function:

1. It runs only when triggered. No process sitting idle waiting. Pay per execution, not per uptime.

2. It scales to zero and back up automatically. Zero traffic means zero cost. A million requests means a thousand parallel invocations.

3. The platform manages everything else. Patching, scaling, high availability, security. You write the code, they run it.

That is it. If your hosting does all three of those things, it is serverless. If it does not, you have a regular long-running process.

Traditional hosting – VPS, shared, dedicated – does none of those things. Your PHP process runs whether anyone visits or not. It scales when you add more boxes. You patch it yourself.

So the question becomes: can you add serverless to a traditional hosting setup, and when does that make sense?

What You Can Run on a VPS Today

You can absolutely run serverless-style workloads on a VPS. Several approaches exist.

Option 1: Open source serverless platforms. OpenFaaS, Apache OpenWhisk, Knative, and Fission all run on Kubernetes or even plain Docker. Install one on your VPS, point it at your existing code, and you have a self-hosted serverless platform.

Option 2: Function-as-a-Service via container runtimes. Coolify, CasaOS, and similar tools give you a “deploy a function” button that wraps your code in a container, starts it on demand, and tears it down when idle. Lightweight, no Kubernetes required.

Option 3: WebAssembly runtimes. Spin up a Wasm runtime like Wasmtime or Wasmer, accept HTTP requests, run the function, return the response. Cold start is measured in milliseconds. This is what Cloudflare Workers does internally.

Option 4: PHP and Node cold-start tricks. Use PHP-FPM with on-demand workers, or Node with smart process management. Not truly serverless, but approximates the cost model for low-traffic scenarios.

All of these work. None of them are as polished as AWS Lambda or Cloudflare Workers. You give up some developer experience for control and cost savings.

What Works Well

Bursty APIs. If you have an API endpoint that gets hit 50 times one hour and zero the next, a serverless-style setup saves real money. A $5 VPS running OpenFaaS handles that fine. A $20 VPS running a long-lived Node process handles it too, but the serverless version charges you only when traffic comes.

Webhooks. Incoming webhooks from GitHub, Stripe, Shopify – they fire sporadically. Running a serverless function that listens for them is a perfect use case.

Image and PDF processing. Upload comes in, function resizes the image or renders the PDF, returns the result. CPU is used only when needed.

Scheduled jobs. Cron-like tasks that run at specific times. A serverless function that runs every 5 minutes costs almost nothing. A VPS running cron costs the same all month.

Spiky business logic. Form submissions, payment processing, email triggers. All spiky. All good fits.

These are exactly the cases where serverless shines. Running them on traditional hosting saves the per-execution fees.

What Does Not Work Well

Long-running processes. Anything that takes more than a few minutes. Most serverless platforms have execution time limits. AWS Lambda tops out at 15 minutes. Cloudflare Workers at 30 seconds for most plans.

State-heavy workloads. Serverless functions are stateless. If you need persistent connections to a database, websocket support, or in-memory state across invocations, traditional long-running processes are simpler.

Low-latency applications. Serverless has cold start latency. Even on Cloudflare Workers, the first request after idle has measurable delay. For interactive apps where every millisecond counts, a warm VPS is better.

Anything needing custom system calls. Sandboxed serverless platforms restrict what your code can do. If you need to shell out to a binary, access specific files, or use custom libraries, traditional hosting is easier.

Predictable steady traffic. If your endpoint gets constant requests 24/7, the per-execution pricing model loses to a flat monthly VPS bill. Serverless economics break when utilization is high.

The general rule: if your workload is spiky and stateless, serverless wins. If it is steady and stateful, traditional hosting wins. Most apps are a mix of both, which is why hybrid is so common.

Real Cost Comparison

Let us put numbers on it.

A simple API endpoint serving a JSON response, running on:

• VPS, 2 GB, traditional setup: $5 to $10/month, fixed
• VPS running OpenFaaS: $5 to $10/month, fixed (same VPS, same cost)
• AWS Lambda: $0.20 per million requests + $0.0000166667 per GB-second
• Cloudflare Workers: $0.30 per million requests + CPU time
• Vercel Functions: similar to Cloudflare, slightly different pricing

For 10 million requests per month at 200 ms average execution:

• VPS: $10 flat
• Lambda: $2 in requests + $3.33 in compute = $5.33
• Cloudflare: $3 + ~$1 compute = $4
• Vercel: $4 + ~$1 compute = $5

At 1 million requests per month at the same execution time:

• VPS: $10 flat (still)
• Lambda: $0.20 + $0.33 = $0.53
• Cloudflare: $0.30 + $0.10 = $0.40
• Vercel: $0.40 + $0.10 = $0.50

The crossover point depends on your traffic. Under 1 million requests per month, the managed serverless platforms are dramatically cheaper. Over 50 million, a VPS might be cheaper. In between, it depends on cold-start frequency and how much idle time the VPS has.

When Mixing Both Makes Sense

This is where most production systems end up.

Steady traffic on traditional hosting. Your main website, your primary API, your always-on services. Run on a VPS where you control everything, costs are predictable, and there is no cold start.

Bursty logic on serverless. Webhooks, scheduled jobs, image processing, the parts of your app that are spiky. Run on Lambda or Workers where you pay per use.

Why this works. The steady parts of your app benefit from predictable cost and low latency. The spiky parts benefit from zero-cost-when-idle. You get the best of both.

In practice this looks like:

• WordPress site on a VPS or shared hosting (steady)
• Image resize + thumbnail generation on Lambda (bursty)
• Stripe webhook handling on Cloudflare Workers (spiky)
• Nightly report generation on a scheduled Lambda (scheduled)
• Database on a dedicated server (always-on)

The architecture is hybrid. Each tier uses what makes sense for its workload.

How to Set Up Serverless on a VPS

If you want to try it.

Step 1: Pick your platform. OpenFaaS for Kubernetes-based, Fission for simpler setups, or Coolify for the easiest button-clicking experience.

Step 2: Install on a fresh VPS. 2 GB minimum, 4 GB recommended. Ubuntu 22.04 or Debian 12.

Step 3: Deploy a test function. Most platforms have a “hello world” template.

Step 4: Point a webhook at it. GitHub webhook, Stripe webhook, anything that fires HTTP requests.

Step 5: Monitor and tune. Watch cold-start latency, memory usage, and request counts. Most platforms expose metrics out of the box.

For a small workload, this whole setup takes an afternoon. For a production-grade deployment with multiple functions, monitoring, and CI/CD, expect a week.

What You Can Do Today

You do not need to commit to a full migration. Start here.

Step 1: Identify your spikiest workload. Look at your traffic logs. Find something that gets 10x traffic variation.

Step 2: Run a single function on a managed platform. AWS Lambda free tier, Cloudflare Workers free tier, Vercel free tier – pick one. Deploy something trivial.

Step 3: Compare cost. Estimate your monthly bill on the managed platform vs your current hosting. The free tiers will give you real numbers for the first million requests.

Step 4: Decide based on data. If the managed platform is dramatically cheaper for that workload, move it. If not, leave it where it is.

Step 5: Try a self-hosted option if you want control. OpenFaaS on a $10 VPS. See how it feels. You will learn whether the trade-offs are worth it for you.

If you host your main site with InterServer, you can run serverless functions on the same VPS using OpenFaaS or Fission, then keep your always-on services (database, main app) running on InterServer infrastructure. No need to move everything at once.

Conclusion

Serverless and traditional hosting are not enemies. They are different tools for different jobs. Trying to replace one with the other is how you end up overpaying.

The real question is not “serverless or traditional” but “what should run where?” Most production systems answer that with hybrid: traditional for steady-state, serverless for spiky and scheduled workloads.

The economics favor serverless when traffic is unpredictable or low. They favor traditional when traffic is steady and high. They favor hybrid when you have both kinds of work.

You do not have to choose one and stick with it forever. Move workloads as traffic patterns change. Use what fits. Pay for what you actually use. That is the whole game.