New​

• X-Forwarded-Host is now set on every proxied request with the hostname the client originally requested. The relay always overwrites any client supplied value, so it is safe to trust.
• FORWARD_HOST_HEADER env var controls this. Defaults to true; set false for pre-4.7.0 behavior.
• Azure Container Apps template deploys Redis automatically when more than one replica is configured.

Improved​

• X-Forwarded-Proto now carries http or https instead of the protocol version, and preserves a value set by an upstream load balancer.
• X-Forwarded-For appends the client IP to an existing chain instead of dropping it.
• On-prem images no longer emit marketplace billing log entries.
• All images built with Go 1.26.5.

Fixed​

• Health check regression: /api/mte-echo returned 400 when the Host header had no DOMAIN_MAP match, breaking load balancers that probe by IP. It now always returns 200.

Upgrading​

• Redeploy with image tag 4.7.0. No client updates needed.
• If an upstream misbehaves after upgrade, it may be reacting to the new X-Forwarded-Host header; set FORWARD_HOST_HEADER=false to revert.
• Docs: Forwarding Headers and Version Compatibility.

Brief Introduction​

Envoy is a high-performance L4/L7 proxy designed for service-to-service communication, load balancing, observability, and traffic management. It powers many modern service meshes, such as Istio and Consul.

MTE API Relay is a lightweight, containerized proxy that provides end-to-end encryption using Eclypses’ MicroToken Exchange (MTE) technology. It protects every byte of data that moves between trusted server components, ensuring that no untrusted network or intermediary can access or alter sensitive information. MTE encryption is designed with Quantum Resistant Enforcement (QRE) in mind — protection not only for current threats but also for attacks possible in the quantum era.

Why Quantum Resistant Enforcement Matters Now​

Quantum computing is advancing rapidly. Traditional cryptographic protocols (like RSA or ECC) are vulnerable to being broken by quantum algorithms that could emerge in the coming years. Relying solely on TLS or basic encryption today exposes long-lived or high-value data to harvest-now, decrypt-later risks.

Implementing MTE-based protection through MTE API Relay brings QRE to server APIs now, by wrapping each communication in dynamic cryptographic tokens that can’t be reversed or reused, even by quantum-capable adversaries.

Building a Secure System with Envoy and MTE API Relay​

A deployment combining the two systems looks like this:

1. Envoy acts as your gateway or sidecar proxy, managing traffic routing, load balancing, retries, and observability across microservices.
2. MTE API Relay sits at critical boundaries — such as between different trust domains, external integrations, or multi-cloud communication paths — encrypting data end-to-end between services or clusters.

Example layout​

• Internal Network (Service Mesh):

  • Envoy sidecars handle routing and observability between services.
  • Internal communication remains efficient and load-balanced.

• Secure Edge / Cross-Domain Boundary:

  • Deploy an Outbound MTE API Relay alongside your Envoy gateway.
  • Pair it with an Inbound MTE API Relay in the remote environment.
  • Envoy routes outgoing traffic (for certain domains or routes) to the local MTE Outbound Relay.
  • The relay encrypts the entire payload using MTE, sends it across the open network to the Inbound Relay.
  • The Inbound Relay decrypts and forwards the clean payload to the internal API.

This architecture allows Envoy to focus on network efficiency and traffic intelligence, while MTE API Relay provides quantum-resistant payload security with minimal overhead and zero application code changes.

Key Advantages of Combining Envoy and MTE API Relay​

• Layered Security: MTE API Relay encrypts at the data level; Envoy secures and manages the transport level.
• Minimal Friction: Applications continue to use plain HTTP locally; Relay handles secure encapsulation transparently.
• Future-Proofing: Quantum Resistance built into core communication.
• Operational Efficiency: Envoy handles dynamic routing, while MTE API Relay enforces end-to-end confidentiality.
• Regulatory Readiness: Meets or exceeds compliance needs for data-in-motion protection now — before post-quantum standards finalize.

A Unified Vision for Secure, Intelligent Networks​

Used together, Envoy and MTE API Relay form a complementary solution:

• Envoy orchestrates traffic efficiently, ensuring scalability and control.
• MTE API Relay guarantees that every piece of data is shielded by quantum-resistant encryption — even when crossing untrusted networks.

This blend of infrastructure intelligence and robust data protection defines the next generation of secure service communication.

Learn more:
Eclypses MTE API Relay Documentation
Envoy Proxy Overview

New​

• Azure AKS marketplace extension. MRS and MAR are now deployable directly from the Azure Marketplace as AKS extensions, with an Azure portal create experience. Redis is no longer required.
• Dedicated image variants. Purpose-built images for on-prem and for each AWS Marketplace listing, for both MRS and MAR.
• Docker Scout reports. Documented commands to generate a SARIF vulnerability report and an SPDX SBOM for the relay images.

Changed​

• Higher outbound pairing concurrency. Default encoder/decoder pairs per outbound target increased from 2 to 24, improving throughput.
• Updated Go toolchain to Go 1.26.x.
• Tuned Docker Compose defaults with more realistic resource limits and DOMAIN_MAP examples.

Fixed​

• Outbound response headers are now forwarded correctly when the relay operates in outbound mode.

The rewrite delivers lower memory use, faster request handling, and a smaller, hardened container image, while keeping the MTE/MKE encryption and Kyber pairing protocol intact so existing clients keep working. It also introduces a new multi-tenant configuration model that becomes the preferred way to run the relay.

New​

• Rewritten in Go. The relay is now a single statically compiled Go binary instead of a Node.js application. This reduces memory footprint and startup time, removes the Node runtime from the deployment, and ships in a minimal, hardened distroless/cc-debian12 container image with no shell or package manager.

• Multi-tenant domain mapping (DOMAIN_MAP). A single relay instance can now front multiple hostnames, each routed to its own upstream with its own CORS origins and client-ID secret. DOMAIN_MAP is a JSON object keyed by inbound host:

  DOMAIN_MAP='{
    "api.tenant1.com": {
      "upstream": "https://backend1.internal",
      "cors_origins": ["https://app.tenant1.com"],
      "client_id_secret": "secret1"
    }
  }'
  

  It is mutually exclusive with the single UPSTREAM setting, and per-domain pass-through routes and outbound tokens are supported.

• Real-time response streaming and Server-Sent Events. Responses are streamed to the client as they arrive rather than buffered. Server-Sent Events (SSE) stream in real time, large MKE payloads are sent as encrypted chunks, and pass-through responses use efficient streaming copies.

• Cloud marketplace billing. Initial AWS Marketplace usage tracking is built into the server, laying the groundwork for the configurable billing strategies expanded in v4.6.

Changed​

• DOMAIN_MAP is now the preferred configuration. The single UPSTREAM setting still works but is considered legacy and is slated for removal in v5. New deployments should use DOMAIN_MAP.
• Logging reimplemented on zerolog. Logs are structured JSON in production and pretty, human-readable output in development. Every request carries a correlation ID for end-to-end tracing, and entries include request duration, upstream response time, encryption/decryption timing, and content sizes. Verbosity is controlled by LOG_LEVEL (trace, debug, info, warning, error, panic, off) and logs stream to stdout. The MTE library and relay versions are logged, and effective settings are logged at startup.
• Larger default encoder/decoder pool. The default POOL_SIZE is now 600 (max 1000), improving throughput under concurrency out of the box.

Fixed​

• 4.5.1 — Updated the Go toolchain to 1.25.6 and removed the unused /public static-file route and its directory from the container images.
• 4.5.2 — Hardened client-ID retrieval and parsing with clearer error logging that includes the offending client ID.

This release is aimed at making production behavior easier to tune and diagnose without changing application traffic flow.

New​

• Configurable log level. A new logLevel setting lets you choose how much the server logs: fatal, error, warn, info, debug, trace, or silent. The default is info. The older debug flag still works and forces debug-level logging, but it is now considered legacy.
• Request and response performance logging. Inbound requests and proxied responses are now logged as structured entries that include the request ID, method, URL, status code, client IP, user agent, and response time. This makes it easier to trace individual requests and spot slow upstream calls.
• Keep-alive and connection headers passed through. The keep-alive and connection headers are now forwarded to your upstream application, improving connection reuse and reducing spurious proxy warnings.

Changed​

• Logs stream to standard output by default. The default logger now writes to stdout, honoring the configured logLevel, instead of a fixed log file on disk. To continue writing logs to a file or ship them elsewhere, use a log adapter.

This update focuses on safer deployment behavior and better visibility into unsupported runtime configurations.

New​

• Trial build detection and warning. The server now detects when it is running with an MTE Trial Build and prints a prominent warning at startup. Trial builds offer no security guarantees and should never be run in production.

The release includes streaming controls, Redis TLS support, and several fixes that improve compatibility under real traffic conditions.

New​

• Client streaming control (useStreaming). The server now honors a per-request streaming flag from the client. Clients can opt out of streaming, in which case payloads are fully buffered before encoding or decoding. Streaming preferences are also carried through to outbound server-to-server requests.
• Redis cache adapter TLS support. The example Redis cache adapter now supports connecting to your cache over TLS.

Changed​

• Higher default encoder and decoder pool size. The default maxPoolSize increased to 250, allowing the server to handle more concurrent traffic out of the box. Larger pools use more memory but improve throughput.
• Improved server-to-server outbound proxying. Outbound proxy handling was refined, including correct treatment of hop-by-hop headers so restricted headers are not incorrectly forwarded.

Fixed​

• 204 No Content responses. Responses with no content are now handled correctly and no longer include a body.
• Automatic pair repair on secret change. When the clientIdSecret changes, affected encoder and decoder pairs are refreshed automatically, and cached pairs are cleared in response to the relevant error statuses so clients re-pair cleanly instead of failing.

Eclypses MTE API Relay Server is a proxy server deployed through a docker container. Due to the success of the MTE Relay Server container for Client/Server use-cases, the decision was made to publish the MTE API Relay through the AWS marketplace for Server-to-Server network level communication for HTTP Requests between API Services.

Use Case​

Network-level protection for HTTP Requests between AWS and another AWS Region, account, etc. As the product evolves, the "3rd Party Environment" could be another cloud service like Azure, or an on-premise container.

Big changes:

• Server-to-Server support
• New usage guide

This is available in a limited capacity but Will be public soon!

Big changes:

• Encoded Custom Headers
• Encoded URL Strings and Query Parameters
• Support for MKE Streaming

More information is available here.

Be on the lookout for Server-to-Server capability soon!

The release also simplifies configurations that do not need browser CORS support and improves request tracing while debugging.

New​

• Optional CORS origins. corsOrigins is no longer required. Deployments that do not need browser cross-origin support, such as server-to-server setups, can omit it entirely.
• Debug request-ID response header. When debug mode is enabled, the server adds the request ID to the response as a header, making it easier to correlate client-side activity with server logs.

Changed​

• More reliable proxying. The proxy path was reworked so that the upstream HTTP status code is preserved on the way back to the client, and error responses are encoded and decoded just like successful ones.
• Redirect handling. Redirect responses from the upstream application are now handled correctly through the relay.

MTE Relay Server in AWS has been updated to include MTE 4.0 library and features.

Other changes:

• Added Kyber algorithm for the handshake
• Fixed bugs
• Support for streaming requests and responses
• Consolidated MTE-Relay Header

More information is available here.

Next on the list - Encoded headers, URL Strings, and Query parameters!

Eclypses MTE Relay Server is a proxy server deployed through a docker container, and is ideal for companies that want to protect their Web application data, credentials, and other critical data. Originally, the Relay was designed as a one-size-fits-most implementation for MTE Web customers. Due to the success of the container, the decision was made to publish the MTE Relay through the AWS marketplace.

Big changes:

• Built-in support for AWS Services
  • ECS, Elasticache, CloudWatch
• Streaming support for pass-through routes

More information is available here.

Much more to come.