Complement Vercel's serverless architecture

Vercel is excellent at shipping frontends and we've used it at Suga for several of our apps. The deploy loop is fast (push to GitHub, get a preview URL, merge to deploy), the build pipeline picks up the framework without configuration, and the platform handles HTTPS, DDoS mitigation, global distribution, scaling, and rollback as defaults.

The architectural choices that make Vercel simple also narrow the platform's ability to support use cases outside of the serverless model.

Function timeouts

Vercel function timeouts now sit at 5 minutes by default and 13 minutes on Pro with Fluid Compute, up from the original 10-second Hobby and 60-second Pro caps. Some common patterns still break this ceiling:

• LLM agents running through tool calls and reasoning steps
• Batch email jobs grinding through lists with retries and rate-limit backoff
• Workflow engines like Hatchet or Temporal whose workers pull jobs from a queue and stream progress back
• Python backends running agent frameworks that hold a process alive across many turns

Keeping them on Vercel means chunking the work into smaller tasks. Vercel Queues and Workflows handle the queue and orchestration plumbing for you, but each consumer invocation still hits the function timeout.

Long-lived connections

Anything that needs a persistent client connection (WebSockets, SSE, long polling, pub-sub) has to run somewhere other than Vercel. Functions only run while handling a request, so when the response goes out there's nowhere to hold the connection open. Vercel's own docs tell developers to use a third-party realtime service for these patterns.

Vercel has streaming responses (chunks sent during the request) and `waitUntil` (background work after the response), but neither holds a connection open. Both terminate when the function times out, and Vercel charges for the full duration even if the function was idle.

The standard workaround is to use a managed connection service (Pusher, Ably, PartyKit, Liveblocks, etc.) and pay per connection or per message on top of the Vercel invoice.

Limited runtime support

Vercel's runtime optimizations target frameworks like Next.js and SvelteKit specifically, bundling their routes into fewer functions to keep cold starts down. Other Node frameworks (Hono, Express, Fastify) map each route to its own function and see more cold starts. Go and Ruby run on the older serverless model that predates Fluid Compute, and .NET and Java sit outside the supported runtime list.

Vercel up front, Suga in back

Each of the examples above hits a different Vercel limit (timeouts, runtimes, or connections). On Suga, all of these scenarios run as a single long-running container, holding state in memory and connections open across the lifetime of the work, rather than being chunked across function invocations or workflow steps.

Pair Suga with Vercel and you keep Vercel's strengths while adding what the serverless model can't do. Vercel keeps your frontend tier, where its preview URLs, edge cache, and security defaults earn their keep, and Suga handles the long-running backend services, using whichever framework you choose.

Pricing

Pricing is predictable because Suga charges for your container's resource use (CPU and memory time) rather than per request or invocation. A backend running steadily can have a fixed cost, or you can enable auto-scaling to pay less when the work volume is low.

Where to start

The good news is that you don't need to migrate everything, start with the service causing you the most friction. Feel free to reach out to our engineering team about your application, we're happy to chat.