Cortlet iconCortlet
Cortlet serverless WebSocket gateway

Keep the socket alive.

Let your functions disappear.

Cortlet maintains persistent WebSocket connections and translates realtime activity into ordinary HTTP requests your serverless backend already understands.

SOCKET

Persistent

Cortlet keeps it alive

BACKEND

HTTP

No socket server required

COMPUTE

Stateless

Functions stay short-lived

The mismatch

WebSockets stay.
Functions don't.

WebSockets depend on long-lived connection state. Serverless compute is designed to run briefly and disappear.

WEBSOCKET

Long-lived

SERVERLESS FUNCTION

Short-lived

The architecture

One persistent layer.
Everything else stays HTTP.

CLIENT

WebSocket

wss://connect.cortlet.com

CORTLET

Persistent gateway

Connection stays alive

YOUR BACKEND

HTTP endpoint

POST /events

Translation

Socket event in.
HTTP request out.

CLIENT{"type":"message","data":"hello"}WebSocket frame
CORTLETPOST /eventsHTTP translation
BACKEND200 OKServerless response

What tends to happen today

Realtime adds a second architecture.

01

Connection databases

Your application starts storing connection IDs simply because the compute handling events cannot retain them.

02

Callback APIs

Returning a response may not send anything back over the socket, so the backend needs another path just to reply.

03

Provider-specific plumbing

Gateway APIs, cloud SDKs, IAM permissions, route keys, and connection lifecycle logic leak into application code.

04

Disconnect cleanup

Dropped connections, stale mappings, reconnects, and failed disconnect events become your responsibility.

Cortlet's thesis

Transport state
should stay out of
your application.

Your application should care about users, messages, jobs, and business logic — not which gateway connection ID happens to belong to a browser tab.

Focused v1

Just the layer
serverless is missing.

01

Persistent connections

Cortlet maintains long-lived WebSocket connections independently from your compute.

02

Webhook events

Connect, message, and disconnect activity is translated into ordinary HTTP requests.

03

Connection context

Your backend receives enough information to understand the event without implementing the transport layer itself.

04

Simple response flow

We are exploring mapping normal HTTP responses back to the originating connection for basic request-response flows.

Intentionally narrow

Not another giant realtime platform.

×No application database
×No multiplayer engine
×No collaborative state engine
×No requirement to replace your backend
×No framework-specific application model

Good fits

Realtime without
realtime-everything.

01

Notifications

Push application events to connected clients without maintaining your own always-on WebSocket server.

02

Background job progress

Keep users updated while serverless jobs run independently from the persistent connection.

03

Direct messaging

Handle simple point-to-point realtime interactions while your backend stays HTTP-native.

04

AI application events

Move realtime interaction events between a connected client and stateless backend handlers.

Backend neutral

If it accepts HTTP,
Cortlet can talk to it.

AWS Lambda
Vercel
Cloud Functions
Next.js
FastAPI
ASP.NET
Ktor
Express
Hono
Anything HTTP

Current status

We're validating
before we build.

Cortlet's production WebSocket gateway is not available yet. We're validating the architecture with developers before committing to the full build.

If this solves a real infrastructure problem for your project, joining the waitlist is the strongest signal you can give us.

Cortlet

Keep sockets alive.
Not servers.

wss://connect.cortlet.comWebSocket → Cortlet → HTTP