Rust-native memory-safe proxy, API gateway, and service mesh data plane that combines Envoy-grade protocol depth, Traefik-style discovery, distributed ACME, xDS, traffic control, observability, and an embedded visual flow control plane in one binary.
Rust-native memory-safe proxy, API gateway, and service mesh data plane that combines Envoy-grade protocol depth, Traefik-style discovery, distributed ACME, xDS, traffic control, observability, and an embedded visual flow control plane in one binary.
One Rust data plane replaces the pattern of stacking Traefik, Envoy, separate ACME tooling, and external dashboard fragments.
HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, QUIC, Redis, MongoDB, MySQL, PostgreSQL, Kafka, Thrift, Dubbo, ZooKeeper, RocketMQ, and SIP.
Listener, network, and HTTP filters map Envoy-style filters and Traefik middlewares into one ordered execution model.
ORCA-aware load balancing, locality, priority spillover, health, outlier detection, circuit breaking, retries, hedging, rate limits, and mirroring.
xDS, provider discovery, Kubernetes, Docker, Consul, Nomad, ECS, file, HTTP, Redis, ZooKeeper, and distributed ACME share one config model.
The embedded VFP dashboard edits routes, filters, clusters, certificates, tenant views, approval flows, and real-time topology.
Janus is the network-boundary product for platform teams that refuse to layer one proxy for service mesh, another for discovery, another for certificates, another for dashboard visibility, and another for gateway traffic shaping. It is specified as a Rust-based single binary that sits at ingress, egress, edge, service mesh, and API gateway boundaries while keeping protocol parsing, filtering, routing, health, xDS, providers, observability, and visual control under one coherent runtime.
The product is not a foundational core. It consumes selected core capabilities where they serve the data plane: Argus for authorization and identity surfaces, Athena for topology context, KAOS and fullSET for analytical signals, Prometheus-compatible metrics surfaces, and CRS ring state for bootstrap and product-bitmask negotiation. Janus owns traffic movement, policy enforcement in the proxy path, dynamic configuration, edge gateway operations, and operator control of the network boundary.
Janus is organized as a single-process, N-worker-thread data plane. The main thread coordinates lifecycle, configuration, certificate rotation, provider updates, and graceful drain. Each worker owns a Tokio runtime, connection table, upstream pools, arena allocator, metrics arrays, and hot-path network execution.
The protocol layer feeds listener, network, and HTTP filter chains. Those chains feed traffic management, where clusters, endpoints, health, locality, priority, retries, hedging, rate limits, and connection pools determine where traffic goes and how failure is contained.
Janus owns transport foundations across TCP, UDP, QUIC, Unix domain sockets, TLS, mTLS, connection pooling, keep-alive, and half-close behavior. Above that substrate, Janus speaks HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, and protocol-aware data-store or message-bus formats including Redis, MongoDB, MySQL, PostgreSQL, Kafka, Thrift, Dubbo, ZooKeeper, RocketMQ, and SIP.
The filter system is three-level: listener filters inspect connection metadata, network filters manage byte streams and protocol managers, and HTTP filters apply request and response policy. This lets Janus map Envoy filters and Traefik middlewares into one chain while preserving ordering, short-circuit behavior, asynchronous authorization, external processing, Lua, WASM, RBAC, CORS, CSRF, compression, header transforms, tap, session affinity, GeoIP, and response mapping.
Janus treats traffic management as a first-class runtime, not an afterthought after routing. Load balancing includes round robin, weighted round robin, least request, ring hash, Maglev, random, locality, priority, slow start, and subset selection. Failure control includes active health checks, outlier detection, per-priority, per-host, and per-route circuit breakers, retry budgets, request hedging, local and global rate limits, and quota service integration.
Janus can receive xDS from an external control plane and can also serve xDS to downstream Janus or Envoy instances. It supports SotW, Delta, ADS multiplexing, resource warming, wildcard subscriptions, snapshot cache, linear cache, and bootstrap in YAML, JSON, or TOML. Provider discovery is the Traefik-originated half: Docker, Kubernetes, Consul, Nomad, etcd, Redis, ZooKeeper, ECS, file, and HTTP providers all feed the same internal configuration model.
Janus exposes an OpenTelemetry-native tracing engine, thread-local metrics, access logging, admin API, self-diagnostics, overload manager, watchdog, config dump, health control, drain and shutdown operations, certificate views, and runtime mutation surfaces. The observability model instruments Janus itself without blocking the request path.
The VFP dashboard is embedded in the Janus binary as a visual control plane. It is a ReactFlow single-page application with real-time WebSocket updates, topology graph, filter-chain composer, route builder, cluster manager, certificate manager, metrics overlay, tenant views, RBAC-gated mutations, audit trail, approval flows, configuration diff, and rollback history.
Janus should not be written as a generic cloud dashboard, a configuration file editor, or a wrapper around existing proxies. Its authority is the data plane boundary: parse traffic, apply policy, move requests, route to upstreams, keep certificates current, receive and serve configuration, expose operator control, and produce high-integrity telemetry about those actions.
Specific operational pain this product is designed to resolve.
Teams layer gateway, ingress, service mesh, certificate automation, provider discovery, dashboard, and policy systems until no one can prove which component owns a routing decision.
Audit teams need evidence for traffic policy, identity checks, certificate state, route changes, and incident handling, but proxy configuration is scattered across dashboards, YAML, providers, and control planes.
Tenant isolation fails operationally when routes, rate limits, certificates, provider-discovered endpoints, logs, traces, and metrics lack a shared tenant boundary.
Disconnected environments cannot rely on SaaS gateways, remote identity fetches, public ACME paths, or external observability paths.
Ingress, Gateway API, service mesh, provider discovery, xDS, and certificate flows often produce competing sources of truth.
Edge gateways run with constrained memory, intermittent connectivity, local-only policy, and limited tolerance for garbage-collector pauses or oversized sidecar stacks.
Complaint: Teams layer gateway, ingress, service mesh, certificate automation, provider discovery, dashboard, and policy systems until no one can prove which component owns a routing decision.
Resolution: Janus consolidates the data plane, discovery intake, xDS intake, traffic policy, certificates, observability, and visual control in one Rust-native gateway product.
Buyer pressure: Platform owners need one accountable boundary for traffic, policy, and operator action.
Complaint: Audit teams need evidence for traffic policy, identity checks, certificate state, route changes, and incident handling, but proxy configuration is scattered across dashboards, YAML, providers, and control planes.
Resolution: Janus combines mTLS, Argus-backed authorization surfaces, RBAC-gated VFP mutations, immutable audit trails, config diffs, rollback history, and traceable route policy.
Buyer pressure: Security and compliance teams need operator accountability without slowing gateway changes.
Complaint: Tenant isolation fails operationally when routes, rate limits, certificates, provider-discovered endpoints, logs, traces, and metrics lack a shared tenant boundary.
Resolution: Janus applies tenant-scoped views, server-side RBAC on mutations, per-tenant telemetry attribution, tenant-aware VFP graph surfaces, and routing policy that preserves tenant separation.
Buyer pressure: SaaS operators need tenant isolation visible at the traffic edge, not only in application code.
Complaint: Disconnected environments cannot rely on SaaS gateways, remote identity fetches, public ACME paths, or external observability paths.
Resolution: Janus supports air-gapped profiles with file-first configuration, local certificates, local auth services, local WASM and Lua modules, minimal provider surfaces, and self-contained admin operation.
Buyer pressure: Air-gapped operators need full edge control without outbound dependencies.
Complaint: Ingress, Gateway API, service mesh, provider discovery, xDS, and certificate flows often produce competing sources of truth.
Resolution: Janus merges Kubernetes, Docker, Consul, Nomad, file, HTTP, and xDS configuration into one internal model with provider namespaces, priority rules, hash deduplication, and VFP provenance badges.
Buyer pressure: Cloud platform teams need fast discovery without losing explainable configuration ownership.
Complaint: Edge gateways run with constrained memory, intermittent connectivity, local-only policy, and limited tolerance for garbage-collector pauses or oversized sidecar stacks.
Resolution: Janus provides edge profiles, Rust memory safety, reduced filter sets, AOT WASM requirements, local control, and a compact VFP profile for constrained deployments.
Buyer pressure: Edge operators need deterministic network behavior and local control when links degrade.
Janus should be positioned as the traffic-boundary product that removes split ownership between ingress, API gateway, service mesh, certificate automation, provider discovery, xDS, dashboard, and proxy telemetry. The operator complaint is not that existing proxies lack features in isolation. The complaint is that every team ends up explaining an outage across multiple runtimes with different configuration models, different dashboards, different certificate lifecycles, and different failure semantics.
Janus gives the website a precise network infrastructure story: one memory-safe data plane owns traffic movement, policy enforcement, dynamic configuration, provider discovery, certificate lifecycle, observability, and visual operations. That does not make Janus a replacement for Argus, Athena, KAOS, fullSET, Prometheus, or CRS. It makes Janus the product that uses selected core services to make the gateway edge understandable, enforceable, and controllable.
Operator relevance: A platform operator needs to answer which listener, route, filter, certificate, provider, cluster, and upstream caused a traffic outcome.
Platform teams complain about proxy layering and unclear ownership. Regulated infrastructure teams complain about route changes and certificate state that cannot be reconstructed during audit. SaaS teams complain about tenant boundaries that disappear inside gateway configuration. Air-gapped teams complain that common gateway stacks expect remote identity, SaaS dashboards, public ACME, and external telemetry. Edge teams complain that oversized sidecars and garbage-collected gateways are a bad fit for constrained sites.
The Janus page should speak to those complaints directly. It should not only list protocols. It should explain why memory safety, single-binary deployment, provider/xDS coexistence, distributed ACME, VFP control, tenant-scoped governance, and high-integrity telemetry matter when the gateway is the blast-radius boundary.
Operator relevance: Gateway copy must connect technical surfaces to the business pain of downtime, audit failure, tenant bleed, rollout risk, and edge isolation.
The VFP dashboard is a key Janus differentiator because traffic systems are graph systems. A route is not only a YAML record. It is a path from listener to filters to clusters to endpoints, shaped by certificates, provider provenance, health, rate limits, retry policy, tenant scope, and real-time metrics. A read-only dashboard cannot safely operate that graph.
Janus therefore treats the dashboard as a visual control plane. Operators can inspect topology, edit filter chains, build routes, manage clusters, watch certificate state, compare configuration versions, submit approvals, roll back changes, and see live metrics on the same graph that represents traffic flow.
Operator relevance: Visual flow control lets users inspect and change the actual traffic graph while preserving review, audit, and rollback paths.