DevDeer TechLoading
Engineering
Kaies Mahmud Nehal1 min read
Every few months a client asks the same question. Why not put everything on serverless and forget about infrastructure? It is a fair question. The pitch is clean: no servers to manage, pay only for what you use, scale to infinity.
The reality is more mixed, and after shipping twenty plus products we have a clear position on it.
Where serverless genuinely wins: Spiky, unpredictable traffic. A form that gets hit twice a day. A webhook that fires on nobody's schedule. For those, paying per invocation is honest and cheap, and we use it.
Where it quietly hurts: Long-running jobs, websocket connections, background workers, and anything that needs a warm database connection pool. Cold starts turn a 50ms response into a 2 second one. The per-request pricing that looked cheap at low volume becomes a surprise at scale. And the moment you need to debug something, you are reading distributed logs across a dozen functions instead of one process.
For our own platform we run a self-managed VPS with Docker, Redis, PostgreSQL, and a job queue. It costs a fixed, predictable amount. We control the whole stack. When something breaks we open a shell and look at it directly.
The honest tradeoff: We take on maintenance. Patching, monitoring, backups, the occasional late-night reboot. That is real work. But for a product with steady traffic and background processing, owning the box is cheaper and calmer than renting a hundred tiny ones.
Our rule of thumb: serverless for the edges, owned infrastructure for the core. If your workload is steady and stateful, a VPS you understand beats a serverless setup you do not.
No. For spiky or rarely used workloads, pay-per-invocation is usually cheaper. The cost flips when traffic is steady, because per-request pricing scales with volume while a VPS stays fixed.
Long-running jobs, websocket connections, background workers, and anything that needs a warm database connection pool. These fight the stateless, short-lived model.
A cold start is the delay when a function spins up after sitting idle. It can turn a 50ms response into a 2 second one, which users notice on anything interactive.
Patching, monitoring, backups, and the occasional late-night reboot. It is real ongoing work, and you need someone on the team who is comfortable owning it.
Yes, and we often do. Our rule is serverless for the edges (webhooks, forms, spiky endpoints) and owned infrastructure for the core (steady, stateful workloads).
Yes. We design, deploy, and maintain self-managed infrastructure on VPS: Docker, Nginx, PostgreSQL, Redis, job queues, monitoring, and backups. We also handle migrations from serverless or managed platforms, with a plan that keeps downtime minimal. If you are unsure which setup fits your workload, get in touch and we will review it with you.
Ask three questions. Is traffic steady or spiky? Do you need background jobs, websockets, or persistent connections? Do you have someone to maintain servers? Steady and stateful with a maintainer points to a VPS. Spiky and stateless points to serverless.