Stronger, leaner, easier to run, and it covers more of your traffic
MTE Relay V5 keeps everything that works in V4 and rebuilds the parts customers asked us to improve. The whole story fits in four cards.
Every message is checked before it is used
V4 verifies a stream when it ends. V5 verifies every message the moment it arrives, and it locks the request type and the response status inside the encryption so nobody in the middle can change them.
Less overhead on every request
A compact binary format replaces text encoding and custom headers. Typical requests carry an estimated 35 to 47 percent less protection overhead and one fewer cryptographic operation.
One console for the whole fleet
Change settings live, see every relay's status, roll back a bad change in one click, and automate safely with scoped tokens. Customers who have previewed it call it the standout feature.
Web APIs, live WebSocket traffic, and TCP applications
The same protocol now powers SocketX V2 for real time apps and TCPQ for SSH, file transfer, mail, and databases, without changing those applications.
One console for the whole fleet
V4 relays are configured with environment variables and restarted to change anything. V5 adds a control plane with a web console and an API that manage every relay you run, on any platform. This is the feature customers who have previewed V5 ask about first, and the one they say they want in production tomorrow.
See the fleet at a glance
The dashboard shows workers online, how many are in sync, the current configuration version, and how many domains are mapped. The Fleet page lists every relay with its version, uptime, last check in, and a status badge: in sync, behind, stale, or rejected.
Change settings without downtime
Domain routing, log level, body limits, and header forwarding apply across the fleet within seconds, with no restart. Other settings save immediately, carry a restart badge, and apply on the next restart. The console shows the restart command for Kubernetes, OpenShift, Swarm, Compose, ECS, or a plain server.
Undo in one click
Every save is a new version that records who changed what. The History page keeps the last 50 versions and rolls back to any of them as a new version, so nothing is ever lost.
Know what each relay is running
Expand any relay to see every setting's live value and where it came from: the console, the environment, or the default. Secrets never leave the relay. The console shows fingerprints so you can confirm two relays match without seeing the value.
Automate safely
Named, scoped service tokens with an expiry date let CI pipelines, GitOps jobs, support scripts, and AI agents read or change configuration through the same API the console uses. Every automated change shows in the audit log under its token name.
Safe by design
Edits are validated with a dry run before they save. Two admins cannot overwrite each other. A relay that cannot reach the console keeps serving its last good configuration. Light and dark themes, and a login page that loads instantly.
Stronger protection of every message
The encryption engine (MTE and MKE) and the Kyber key exchange are the same technology V4 customers already trust. V5 changes how each message is packaged and checked, and closes gaps that existed between the encryption and the transport.
Checked message by message
V4 streams data through and confirms integrity when the stream ends, so a tampered chunk could reach an application before the check fails. V5 verifies every message before releasing any of it. Long downloads, live event feeds, and tunnels all get the same guarantee.
The request type and result cannot be altered in transit
In V4 the HTTP method and the response status travel outside the encryption. V5 locks both inside it. A GET cannot be turned into a DELETE at an intermediate hop, and an error cannot be dressed up as success.
All headers protected in both directions
V4 encrypts request headers but sends most response headers in the clear. V5 encrypts every header both ways, including cookies and authorization data, and keeps repeated headers intact.
Fake responses are blocked
If anything other than a genuine relay message comes back, such as a proxy error page, a firewall block page, or injected content, V5 clients refuse it. Applications never mistake it for a real answer.
Stronger key exchange
Kyber 1024 by default, the highest strength level, up from Kyber 512 in V4. The strength is configurable and advertised to clients, so a mismatch is caught at connection time with a clear message.
Abuse resistance
Rate limits on session setup, replay detection, size limits, and validation before any cryptographic work runs. V4 has none of these.
Leaner on the wire, lighter on your servers
V4 wraps encrypted data in text encoding and custom headers. V5 sends compact binary frames. The result is fewer bytes and fewer cryptographic operations on every request, and bounded memory on large transfers.
Estimated protection overhead per request and response, derived from the two wire formats with identical application data. Measured V4 against V5 figures will follow before any percentage is published externally.
No text encoding
Base64 expands data by a third. V4 uses it for the encrypted path and headers. V5 removes it from the data path entirely.
Fewer operations
One encryption operation covers the path, method, and headers together. V4 uses two. Every request saves an operation on the client and another on the relay.
Bounded memory
Large uploads and downloads move in fixed size frames instead of being held in memory whole. Against the earlier prototype, a 1 GB upload ran faster while using about 4 percent of the memory.
Faster first byte
Response headers are sent the moment your backend answers, before the body, so live feeds and long polls open immediately.
Tunable streaming
Operators tune frame size and a short coalescing window per domain, trading a few milliseconds for far fewer bytes on high rate event streams.
Cheaper startup
The browser SDK opens one key pair instead of five and fills the rest in the background, so the first request leaves sooner and a phone uploads far less at page load.
Fewer surprises in production
Most V4 escalations are not cryptography problems. They are infrastructure misreading relay errors, sessions expiring while an app was idle, and configuration that could only be checked by reading logs. V5 addresses each.
Errors that play nicely with cloud infrastructure
V4 reports relay problems with unusual server error codes (559 to 569). Service meshes treat those as backend failures and eject relays, and CDNs replace the message with their own error page. V5 uses a dedicated block of client side codes with a plain reason attached, so meshes, CDNs, and proxies leave them alone and your dashboards read them correctly.
Self healing sessions
When one encrypted session goes bad, V5 repairs just that one instead of rebuilding everything. Idle apps keep sessions alive with a lightweight keepalive, so a mobile app returning from the background does not pay a full setup again.
Clients adapt to the server
At connection time the relay tells the SDK its limits, timeouts, and features. Mismatched versions or library builds are caught immediately with a message that names the fix.
Traceability
Every response, including errors and streams, carries a request id that matches the relay's logs, so support can go from a user report to the exact log line.
Timeouts that fit the workload
Request, response, idle, and heartbeat timeouts are set per domain, and slow uploads no longer die at a fixed wall clock limit.
Capacity that follows demand
Relay capacity grows with traffic instead of stopping at a fixed pool, and outbound sessions are kept warm and refilled in the background so bursts and long streams keep moving.
Beyond web APIs: live traffic and TCP applications
V5's protocol was designed from the start to carry more than HTTP. Two products ride on it. Each is built, versioned, and released separately, and availability for each is announced on its own.
Live WebSocket traffic
For chat, live dashboards, collaboration, trading screens, and any app that keeps a connection open. Each connection gets its own key pair, every message is verified individually, and long sessions rotate keys on a budget. The connection headers, cookies, and tokens travel inside the encryption. SocketX V1 customers get a new protocol generation: V1 and V2 do not interoperate, so client and server move together.
Existing TCP applications, unmodified
A small agent runs next to the application. The application connects to it locally and the agent tunnels the bytes to a relay that only connects to destinations you have approved. Fits SSH, SFTP, SMTP, IMAP, PostgreSQL, MySQL, SQL Server, MQTT, RDP to a host, and anything inside its own TLS. Each client holds an issued key that can be revoked, and revocation cuts live sessions within minutes.
The same places you run it today, plus an open specification
Same deployment shapes
On premises images, AWS and Azure images, Docker Compose, Kubernetes, and an AKS extension. Images stay minimal with no shell inside.
One published specification
The protocol is a frozen, normative specification with a registry of reserved values and byte exact test vectors. Partner and third party SDKs build from the spec, not from our source, and every platform agrees byte for byte.
Version safety for years
Servers keep accepting the previous protocol version for 18 months after a new one ships, deprecations are announced a year ahead, and an old SDK always receives a precise message naming the minimum version.
SDKs
Browser SDK and public browser client (beta today), Go client, SocketX TypeScript client, C# in progress, and mobile SDKs to follow from the spec.
Test origin for your team
A published test origin image answers both HTTP and WebSocket so your developers can validate an integration before touching production.
Diagnostics on demand
Structured events, opt in profiling, and per stage timing are available when you need them and cost nothing when you do not.
What the upgrade involves
V5 is a new protocol generation, so it is a coordinated upgrade rather than an image swap. The work is well defined and each step is short.
- Upgrade servers and SDKs together. V4 SDKs cannot talk to a V5 relay; they receive a clear message naming the minimum version. Plan a short cutover window per application.
- Update monitoring. Alerts keyed on the old 559 to 569 codes move to the new 470 to 490 block, which also comes with a readable reason.
- Expect sessions to re establish. Existing encrypted sessions are not migrated. Clients pair again automatically on first use.
- Review configuration. The single upstream setting is retired in favor of the domain map, and a few settings are renamed. The console shows the full schema with descriptions and defaults.
- Decide on the console. It is optional. Relays run from environment variables alone if you prefer, and the console can be added later without touching traffic.
- Pilot the new transports separately. SocketX V2 and TCPQ have their own release schedules and their own acceptance tests.
What we are not claiming yet
- No "V5 is X times faster than V4" figure. The overhead reductions above are derived from the two formats. Measured V4 against V5 numbers will be published once the benchmark runs on identical hardware.
- Sticky "owner mode" with in memory state, and encrypted session state at rest, are designed and reviewed but not in this release. Multi replica deployments still use Redis.
- TCP tunnels do not yet rotate keys mid session and do not survive a relay upgrade.
- The HTTP relay upgrade does not include WebSocket or TCP support by itself. SocketX V2 and TCPQ are separate products with separate release dates.
- Kyber key exchange, streaming, multi tenant routing, and marketplace images are not new. V5 strengthens and extends them.