Can I run a long-running Node process, WebSockets or a queue worker on Vercel?
Not in the way you would on a server. Vercel’s runtime is a function: it is invoked per request, it has a maximum duration, and it does not exist between calls. That rules out a WebSocket server holding connections, a warm database connection pool shared across requests, a queue consumer that sits on a queue, an in-process scheduler, and any job that runs longer than the function limit. Naijacloud runs an ordinary long-lived container — the same process model as a VM or a Docker host — so all of those work as written, with the database beside it on a private address. What you give up is what functions are good at: scaling from zero to very large without thinking about it, and paying nothing when nothing is happening.
The clearest tell that you have outgrown a function runtime is the workarounds. A cron endpoint that a scheduler pings, because there is no process to hold a timer. A third-party WebSocket service in front of an app that is otherwise self-contained. A queue provider chosen because nothing in your deployment can consume one. A report that had to be split into pages so each page finishes inside the timeout. Each is reasonable on its own; together they are a runtime mismatch.
Connection pooling is the one that bites quietly. Every function invocation is a potential new database connection, and Postgres does not enjoy that, so serverless stacks add a pooler in the middle — another hop, another vendor, another failure mode. A long-lived container opens a pool once and keeps it, which is why the same app often needs a smaller database here than it did there.
Cold starts are the other. A function that has not run recently pays initialisation before it serves, and Vercel has worked hard to make that small, but it is never zero. A container that is already running is already warm.
Now the other direction, honestly. Functions scale to zero and scale out without a capacity decision, and for a spiky, mostly-idle workload that is both cheaper and less work than reserving an instance. Vercel’s build pipeline and preview experience for Next.js are excellent, its CDN is excellent, and if what you are deploying is a frontend, a function runtime is the right shape for it. We are not the better place to put a marketing site.
The common resolution is not either-or: frontend where it already is, and the long-lived parts — the WebSocket server, the workers, the scheduled jobs, the database — on a platform that can hold a process.
Platform comparison
Scored out of five on what actually changes your day.
WebSockets and long-lived connections
Naijacloud
5/5A normal server process. Hold as many connections as the instance has memory for.
Vercel
1/5Not possible in a function. You add a third-party realtime service in front.
Warm database connection pools
Naijacloud
5/5The pool opens once at boot and lives as long as the container.
Vercel
2/5Each invocation is a potential new connection, so a pooler in the middle is effectively mandatory.
Background jobs and queue consumers
Naijacloud
5/5A worker service that stays running and consumes a queue, plus cron as its own container with its own logs and run history.
Vercel
2/5Cron triggers a function and inherits the function timeout. A consumer that sits on a queue has nowhere to sit.
Long-running requests
Naijacloud
5/5Bounded by your own code. Exports, report generation and model calls run as long as they need.
Vercel
2/5A hard maximum duration per invocation, which is the constraint most teams hit first.
Cold starts
Naijacloud
5/5None. The process is already running.
Vercel
3/5Small and well optimised, and not zero. The first request after a quiet period pays initialisation.
Scaling to zero and back out
Naijacloud
2/5You pick an instance size and it runs. No autoscaling, and an idle service still costs money.
Vercel
5/5Zero to very large with no capacity decision, and nothing billed while idle. This is what the runtime is for.
Next.js build and preview experience
Naijacloud
3/5A builder that detects the framework and ships it, with a URL per pull request. Competent, and not built around one framework.
Vercel
5/5The framework’s own platform. Nothing else runs Next.js as well, and nobody should claim otherwise.
Serving static and cached content
Naijacloud
4/5Static sites and cached assets fronted by a CDN.
Vercel
5/5126 points of presence with TCP terminated at the nearest one.
Frequently asked
Usually less than expected. Next.js runs as a Node server perfectly well, and our builder detects it and ships it. What changes is that ISR and edge middleware behave differently outside Vercel’s network, image optimisation runs in your container rather than on their CDN, and you lose the deep integration that makes Vercel the best host for Next.js. If your app is mostly a frontend, that trade is not obviously worth it.
Yes. It is an ordinary long-lived process — Socket.IO, ws, Phoenix channels, whatever you are using — with no gateway in front and no per-connection add-on. This is the single most common reason people arrive here from a function platform.
As their own service from the same repo with a different start command, running continuously and consuming whatever queue you use — including a Redis or Valkey instance on the same private network. Scheduled work is a cron service: its own container, its own logs, its own run history, capped at an hour.
Yes, and it is a real loss for spiky workloads. A service here runs until you stop it and is metered hourly, so an app that gets ten requests a day costs the same as one that gets ten thousand. If nothing about your workload needs a process to stay alive, a function platform is cheaper and we would rather you kept it.
Related questions
Vercel · Nigeria latency and regions
Does Vercel have a region in Nigeria?
Railway · What a workload costs per month
What does a production app actually cost per month on Railway vs Naijacloud?
Vercel · Custom domains, SSL and apex
How do custom domains, apex records and SSL compare on Vercel and Naijacloud?
Or read the full Naijacloud vs Vercel comparison, which covers pricing, databases, email and the rows we lose.
Try it against your own workload
Deploy one service from a Git repo in Port Harcourt and compare the numbers yourself. Free tier, no card, no FX.