Serverless Compute & Sandboxing
Deploy backend APIs and dynamic Server-Side Rendered (SSR) web applications without managing servers, provisioning virtual machines, or configuring reverse proxies. Exovon Compute scales from zero to hundreds of concurrent micro-containers automatically within our Mumbai (asia-south1) cloud cluster.
Sub-250ms Scale-to-Zero Wake-Up
Optimized standalone microkernel containers scale to zero when idle and resume in under 250ms when incoming traffic arrives.
gVisor Microkernel
Every user container executes inside a dedicated user-space microkernel, completely isolating system calls from host hardware.
Streaming & SSE
Native support for chunked HTTP responses, Server-Sent Events, WebSockets, and real-time AI token streaming.
1. Serverless Execution Lifecycle
Exovon Compute eliminates idle infrastructure costs by decoupling execution from persistent uptime:
Dormant State (Scale to Zero)
Cost: ₹0.00When an application receives zero requests for 15 minutes, its containers hibernate. Compute, CPU, and RAM allocation drop to zero.
Ingress Wake-Up & Execution
The Edge Router intercepts an incoming HTTP request, spins up an isolated microkernel container instance inside our Mumbai cluster, and proxies the request to port 8080. You are never billed for container spin-up time; compute measurement begins strictly when the application receives the HTTP request.
Horizontal Burst Autoscaling
Cap: 80 Concurrency / NodeEach container instance can process up to 80 concurrent HTTP requests. If traffic spikes beyond capacity, the orchestrator automatically provisions additional parallel container replicas in < 500ms.
Instance Concurrency vs. Autoscaling Economics
80 Concurrency / NodeUnderstanding the distinction between in-container concurrency and horizontal replica autoscaling is essential for estimating serverless compute consumption:
If 80 users connect simultaneously to your application for 15 minutes, all 80 connections are multiplexed inside a single microcontainer.
💡 Unlike single-invocation serverless (where 80 connections × 15m = 20 hours of compute), container concurrency burns only 15 minutes total.
When connection #81 arrives, Container 1 is saturated (80/80). The orchestrator spins up Container 2 in <500ms. Connections 1–80 run on Container 1; connection 81 runs on Container 2.
💡 Container 2 now has headroom for connections 82 through 160. 160 connections still cost only 30 minutes of compute across both instances.
2. Compute Specifications & Quotas
| Tier | vCPU per Container | Memory (RAM) | Max Execution Timeout | Max Concurrent Replicas |
|---|---|---|---|---|
| Hobby (Free) | 0.5 vCPU (shared) | 512 MB | 10 seconds | 1 instance (scales to 0) |
| Cloud Starter (₹349/mo) | 1 vCPU (shared) | 1024 MB (1 GB) | 30s (HTTP) • 15m (Streams) | Up to 4 instances (scales to 0) |
| Pro (₹1,499/mo) | 1 vCPU (shared) | 1024 MB (1 GB) | 60s (HTTP) • 30m (Streams/WS) | Up to 4 instances (scales to 0) |
| Heavy (₹3,999/mo) | Dedicated up to 8 vCPUs | Custom / 4 GB+ | 120s (HTTP) • 60m (Streams/WS) | Dedicated Fleet (10+ instances) |
3. Real-Time Streaming, WebSockets & Connection Lifecycles
Exovon Compute is built with native support for streaming protocols, including HTTP chunked transfer encoding, Server-Sent Events (SSE), and full bidirectional WebSockets (ws:// and wss://). Because applications run as real standalone microcontainers on port 8080, incoming connections can upgrade to raw TCP duplex sockets without third-party proxy intermediaries.
| Connection Type | Timeout Limit (Pro) | Behavior & Termination Rule |
|---|---|---|
| Standard HTTP / REST / SSR | 60 seconds | Safety cutoff for synchronous request-response cycles. Returns HTTP 504 Gateway Timeout if unhandled promises or slow SQL queries fail to complete, preventing hung connections. |
| Idle Inactivity Window (WS & Streams) | 60 seconds silence | If an open WebSocket or SSE stream experiences zero data exchange (no payload frames or ping/pong heartbeats) for 60 consecutive seconds, the edge proxy terminates the silent socket to release container memory. Standard heartbeat pings (ws.ping()) continuously reset this timer. |
| Max Continuous Stream Session | Up to 30 minutes | Single continuous socket sessions are capped at 30 minutes per connection. Front-end clients should implement standard exponential reconnection logic (reconnect: true) to recycle sessions seamlessly without disrupting users. |
Recommended Workloads on Exovon Pro
Exovon Pro is engineered around an event-driven, scale-to-zero serverless architecture. Native WebSockets are provided for developer convenience and are best suited for:
- • Interactive User Dashboards: Live analytics feeds and telemetry widgets open during active browser sessions.
- • Collaborative Canvas & Docs: Multiplayer cursor presence, form sync, and document editing (e.g. Yjs, Liveblocks).
- • In-App Support Chat: Ephemeral customer chats where sessions close when the user navigates away.
- • AI Completion Streaming: Chunked SSE streaming tokens from language models without proxy buffering.
In these interactive patterns, connections close when users leave the page, allowing containers to hibernate to ₹0.00 compute.
Workloads Better Suited for Dedicated VPS
Because an active WebSocket treats the container as in-flight and prevents scale-to-zero hibernation, the following workloads are not recommended for Exovon Pro:
- • 24/7 Discord / Telegram Bot Daemons: Continuous background socket listeners that never disconnect.
- • Perpetual IoT Telemetry Collectors: Remote sensor devices holding uninterrupted connections 24 hours a day.
- • High-Frequency Market Tickers: Non-stop algorithmic crypto or financial exchange feeds.
Server-Sent Events (SSE) Route Implementation
// app/api/chat/route.ts
export const runtime = "nodejs";
export async function POST(req: Request) {
const encoder = new TextEncoder();
const stream = new ReadableStream({
async start(controller) {
controller.enqueue(encoder.encode("Streaming tokens from Mumbai (asia-south1)...\n"));
// Stream tokens to client with zero proxy buffering lag
controller.close();
},
});
return new Response(stream, {
headers: {
"Content-Type": "text/event-stream",
"Cache-Control": "no-cache",
"Connection": "keep-alive",
},
});
}4. Ephemeral Storage (/tmp) & Execution Lifecycle
Understanding local container storage and process isolation boundaries prevents unexpected runtime failures:
512 MB Scratch Disk (/tmp)
Every container includes a high-speed in-memory /tmp directory for temporary file processing (e.g. video transcoding, PDF generation, image manipulation). This storage is ephemeral — files written to /tmp are discarded when the container hibernates or scales down. For persistent uploads, use Exovon Object Storage.
Post-Response CPU Throttling
In serverless architectures, container CPU is allocated while serving active HTTP requests. Once your code sends the final response to the client, the instance enters a low-power standby state. Unawaited promises or setTimeout() callbacks running in the background may be throttled until the next request arrives.
Frequently Asked Questions
Do you bill for container startup time when scaling from zero?
No. You are never billed for wake-up boot time (<250ms). Container image decompression, microkernel initialization, and TCP port 8080 health checks are platform orchestration overhead absorbed entirely by Exovon. Your billable compute runtime begins strictly when your application receives the incoming HTTP request.
Do you bill for network latency?
No. Network latency (the physical fiber transit time in milliseconds between the visitor and Mumbai compute) is completely free. You only pay for the volume of data egressed (bytes transferred from origin). Furthermore, edge response buffering ensures a slow client on a weak mobile connection will never artificially extend your container's execution time.
Why do you recommend @neondatabase/serverless for databases in serverless functions?
Because serverless containers scale up and down dynamically, traditional persistent TCP socket pools quickly exhaust PostgreSQL's maximum connection limit. The HTTP driver executes queries statelessly in single round-trips over HTTPS port 443.
Can I run background cron jobs inside serverless containers?
Serverless containers are ephemeral and terminate when the HTTP response completes. For scheduled tasks or background workers, use Exovon Scheduled Webhooks or trigger external worker routines.