Rust

@push.rocks/smartdns is a TypeScript-first DNS toolkit with Rust binaries behind the wire-level DNS work.

The public surface stays in TypeScript: create a DNS client, choose a resolution strategy, register authoritative server handlers, retrieve ACME certificates, and wire the package into a larger service. Rust handles the parts where DNS is byte-oriented: UDP queries, DNS-over-HTTPS wire-format requests, packet parsing and encoding, async UDP and HTTPS listeners, and DNSSEC signing.

This is the same TypeScript/Rust split beta.news covered in the foss.global bridge architecture dispatch. TypeScript owns product shape and integration. Rust owns the data path. SmartDNS applies that pattern to DNS without turning the package into a general-purpose recursive resolver.

Three entry points

The package ships three import surfaces:

import { Smartdns } from '@push.rocks/smartdns/client';
import { DnsServer } from '@push.rocks/smartdns/server';
import { dnsClientMod, dnsServerMod } from '@push.rocks/smartdns';

The client entry point resolves records. The server entry point runs an authoritative DNS server with TypeScript handlers. The root entry point re-exports both modules.

The current public package version is 7.9.3. The export map points @push.rocks/smartdns/client to dist_ts_client, @push.rocks/smartdns/server to dist_ts_server, and the root package to dist_ts. The build pipeline runs tsbuild tsfolders --web and tsrust, so the TypeScript and Rust outputs ship together.

The major architecture changes landed in the 7.7.x and 7.8.x line. Version 7.7.0 added the Rust server backend and TypeScript bridge. Version 7.8.0 added the Rust DNS client binary for UDP and DoH. Version 7.8.1 removed the synchronous TypeScript packet-processing fallback; current raw packet processing requires the Rust bridge path.

The client: system resolver, Rust UDP, or Rust DoH

Smartdns supports five resolution strategies:

• prefer-system: try the operating system resolver first, then fall back to Rust DoH;
• system: use only Node's DNS module;
• doh: use DNS-over-HTTPS through the Rust client;
• udp: use raw UDP DNS through the Rust client;
• prefer-udp: try Rust UDP first, then fall back to Rust DoH.

The difference is operational. The system resolver path honors local host behavior and does not start Rust. UDP and DoH use rustdns-client, which is spawned lazily on the first query that needs it and can be stopped with destroy().

import { Smartdns } from '@push.rocks/smartdns/client';

const dns = new Smartdns({ strategy: 'prefer-udp', timeoutMs: 5000 });

const aRecords = await dns.getRecordsA('example.com');
const mxRecords = await dns.getRecords('example.com', 'MX');
const txtRecords = await dns.getRecordsTxt('example.com');

dns.destroy();

The Rust client builds DNS wire-format queries with the recursion desired flag set. It adds EDNS0 with the DNSSEC OK bit, sends UDP queries to an upstream resolver or RFC 8484 DoH POST requests, parses the DNS response, decodes common RDATA types, and reports the upstream AD flag back to TypeScript as dnsSecEnabled.

Type-specific helpers cover A, AAAA, TXT, and NS lookups. Generic queries support A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, and SRV. That makes the client useful for propagation checks, certificate workflows, DNS validation in infrastructure services, and application code that needs predictable DNS behavior without making each consumer parse DNS packets.

The server: authoritative DNS with Rust I/O and TypeScript handlers

The server side is DnsServer. It is an authoritative DNS server, not a recursive resolver. Rust owns UDP socket handling, DNS packet parsing and encoding, DNS-over-HTTPS over Hyper and Rustls, DNSSEC key and signature work, and the IPC management loop. TypeScript owns server lifecycle, handler registration, ACME orchestration, domain authorization, and query events.

import { DnsServer } from '@push.rocks/smartdns/server';

const server = new DnsServer({
  udpPort: 53,
  httpsPort: 443,
  httpsKey: '...pem...',
  httpsCert: '...pem...',
  dnssecZone: 'example.com',
  primaryNameserver: 'ns1.example.com',
});

server.registerHandler('*.example.com', ['A'], (question) => ({
  name: question.name,
  type: 'A',
  class: 'IN',
  ttl: 300,
  data: '10.0.0.1',
}));

await server.start();

When a DNS query arrives, the Rust process emits a dnsQuery event over JSON IPC. TypeScript resolves the question against registered handlers. The answer list goes back to Rust, which assembles the DNS response and signs RRsets when DNSSEC was requested.

Handlers use glob patterns through minimatch, and multiple handlers can contribute records to the same response. That fits dynamic authoritative DNS cases: wildcard service records, generated internal hostnames, tenant-specific answers, ACME DNS-01 challenge records, and dashboard-managed zones.

The 7.9.3 release fixed a real DNS edge case in that handler path. Query names and record types are now normalized before matching, so DNS 0x20 mixed-case randomization still resolves registered records.

DNSSEC is in the Rust layer

DNSSEC is enabled through dnssecZone. The TypeScript server configuration currently sends ECDSA as the default algorithm, and the Rust key implementation covers ECDSA P-256 and ED25519. DNSKEY answers and RRSIG generation are produced in Rust, with RRsets serialized canonically before signing.

That placement is intentional. DNSSEC signing is sensitive to wire format details: canonical ordering, lower-case owner names, TTL handling, record-set boundaries, and the exact RDATA bytes. Those are better handled next to the Rust packet encoder than in an application-level fallback.

DNS-over-HTTPS on both sides

SmartDNS uses DNS-over-HTTPS in both directions.

As a client, rustdns-client sends RFC 8484 application/dns-message requests. Its default DoH endpoint is Cloudflare's https://cloudflare-dns.com/dns-query, and the default UDP upstream is 1.1.1.1:53.

As a server, the Rust backend can expose a DoH listener over HTTPS. The TypeScript options provide HTTPS bind interface, port, certificate, and key. ACME support can retrieve Let's Encrypt certificates through DNS-01 challenge records registered temporarily in the same handler system.

Manual binding and query events

Most deployments can let DnsServer.start() bind UDP and HTTPS directly. The options also support explicit UDP and HTTPS bind interfaces, so the server can be restricted to localhost, a LAN address, or different addresses per protocol.

Manual UDP and HTTPS modes let an outer service own socket placement. In current Rust mode, raw packet processing goes through processRawDnsPacketAsync(); the server must be started

@lossless.zone/objectstorage is a self-hosted, S3-compatible object storage server packaged as a single Docker image. It gives you an S3 endpoint for applications, a browser-based management UI for humans, and a Rust-powered storage engine underneath.

The short version: it is the storage box you can run yourself when you want S3 semantics without signing up for a cloud bucket, wiring together MinIO, or building an admin console from scratch.

Why Another Object Storage Server?

Object storage is one of those pieces of infrastructure that looks simple until you operate it. The protocol is familiar: buckets, keys, objects, credentials, policies, multipart uploads. The hard part is everything around it.

You need a process that starts predictably in Docker. You need credentials that can be managed without rebuilding an image. You need a UI for buckets, policies, object browsing, and quick inspection. You need an S3-compatible API so existing SDKs and tools keep working. If the storage grows beyond one disk, you need clustering, erasure coding, drive awareness, and repair behavior that does not require a separate product.

@lossless.zone/objectstorage wraps those requirements into one product layer. The storage protocol and data path are handled by @push.rocks/smartstorage, a Rust-backed S3-compatible engine. The objectstorage package adds the Docker runtime, Deno-based control process, admin authentication, management APIs, and a dees-catalog web UI.

┌───────────────────────────────────────────────────────────────┐
│                      objectstorage                            │
│                                                               │
│  Management UI                 Storage Engine                 │
│  port 3000                     port 9000                      │
│                                                               │
│  dees-catalog SPA              smartstorage                   │
│  typed ops API      ───────▶   Rust S3 server                 │
│  admin auth                    SigV4, policies, streaming I/O │
│                                                               │
│  optional cluster layer: QUIC, erasure coding, drive paths    │
└───────────────────────────────────────────────────────────────┘

Ecosystem note. lossless.zone is the storage-facing product line in the foss.global stack. objectstorage is the runnable service layer; @push.rocks/smartstorage is the lower-level S3 engine underneath it.

A Docker Container, Not a Framework Exercise

The recommended start path is intentionally boring:

docker run -d \
  --name objectstorage \
  -p 9000:9000 \
  -p 3000:3000 \
  -v objstdata:/data \
  -e OBJST_ACCESS_KEY=myadminkey \
  -e OBJST_SECRET_KEY=mysupersecret \
  -e OBJST_ADMIN_PASSWORD=myuipassword \
  code.foss.global/lossless.zone/objectstorage:latest

Port 9000 is the S3-compatible API. Port 3000 is the management UI. /data is the persistent volume for bucket data and product metadata.

The image is Alpine-based, runs Deno in production, uses tini for signal handling, and exposes the cluster transport port 4433 for distributed deployments. The build is multi-stage: a Node/pnpm stage bundles the frontend with @git.zone/tsbundle, and the final image contains the Deno runtime, backend code, shared interfaces, and bundled web assets.

That split matters. This is not just a library that happens to start a server. It is meant to be deployed as a service.

S3 Compatibility Where Applications Need It

Applications talk to objectstorage through the normal S3 model. Any S3-compatible client can point at http://localhost:9000, use path-style addressing, and authenticate with the configured access key and secret.

import { S3Client, PutObjectCommand, ListObjectsV2Command } from '@aws-sdk/client-s3';

const s3 = new S3Client({
  endpoint: 'http://localhost:9000',
  region: 'us-east-1',
  credentials: {
    accessKeyId: 'admin',
    secretAccessKey: 'admin',
  },
  forcePathStyle: true,
});

await s3.send(new PutObjectCommand({
  Bucket: 'my-bucket',
  Key: 'hello.txt',
  Body: 'Hello, object storage!',
}));

const result = await s3.send(new ListObjectsV2Command({
  Bucket: 'my-bucket',
}));

console.log(result.Contents);

The underlying smartstorage engine handles the protocol details: AWS SigV4 authentication, IAM-style bucket policies, multipart uploads, byte-range requests, and streaming I/O. For large files, that distinction is important. The engine is Rust-based and designed around streaming and backpressure rather than loading whole objects into a JavaScript process.

The Management UI Is Part of the Product

Raw S3 compatibility is useful for applications. It is not enough for operators.

The management UI is served from the same container on port 3000. After logging in as admin with OBJST_ADMIN_PASSWORD, you get views for server status, buckets, objects, policies, access keys, and configuration.

The object browser is the part users notice first. It behaves more like a file manager than a cloud API explorer: column-style browsing, folder prefixes, upload, download, preview, move, rename, delete, and context menus. Text objects can be opened in a Monaco-powered code editor and saved back to storage. PDFs render inline with page navigation, zoom, thumbnails, print, and download controls.

That is a practical difference from a minimal S3 server. Operators do not need to keep switching between aws s3 ls, a bucket policy JSON file, and a separate dashboard. The common workflows are in the product.

Named Policies Instead of Copy-Pasted JSON

S3 bucket policies are powerful, but raw policy JSON is awkward to manage by hand. objectstorage adds a named policy layer on top.

You create a reusable policy once, then attach it to one or more buckets. The PolicyManager persists named policies under the storage directory, tracks bucket attachments, merges attached statements, replaces the ${bucket} placeholder with the concrete bucket name, and applies the resulting S3 policy to the bucket.

[
  {
    "Sid": "PublicRead",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::${bucket}/*"
  }
]

Attach that policy to assets, downloads, and public-site, and each bucket receives the correct concrete resource ARN. Updating the named policy recomputes the attached bucket policies. Deleting a policy detaches it and reapplies the affected buckets.

This is a small abstraction, but it removes one of the most common sources of S3 admin drift: nearly identical policy documents copied across buckets and edited manually.

Runtime Credentials and Admin State

objectstorage has two authentication surfaces.

The S3 API uses access-key credentials and SigV4 verification. The admin UI uses a JWT-backed login flow with the fixed username admin and the configured admin password.

The default standalone configuration is deliberately simple:

OBJST_ACCESS_KEY=admin
OBJST_SECRET_KEY=admin
OBJST_ADMIN_PASSWORD=admin
OBJST_REGION=us-east-1

Production deployments should override those values. Credentials can also be managed from the UI. The container persists runtime-managed access credentials in /data/.objectstorage/admin-config.json, so credential changes survive restart when /data is backed by a persistent volume.

The product boundary here is clear: objectstorage owns admin UX, product metadata, and startup configuration. smartstorage owns the S3 auth and policy enforcement path.

@push.rocks/smartproxy is a production proxy that handles TCP, TLS, HTTP reverse proxying, WebSockets, UDP, QUIC/HTTP3, load balancing, and kernel-level NFTables forwarding — all from a single route-based TypeScript API. Under the hood, a Rust binary does every byte of networking. Your TypeScript code just describes what should happen. The Rust engine figures out how — fast.

The Problem with Proxy Configuration

If you've ever set up nginx, HAProxy, or Envoy, you know the drill: write YAML or a bespoke config language, restart the process, hope the syntax is right, grep through docs for the directive name you forgot. There's no type checking, no autocomplete, no way to express "route this domain to backend A unless the path starts with /api, in which case terminate TLS and forward to backend B with rate limiting."

SmartProxy replaces all of that with typed TypeScript objects. A route is a match/action pair. The match says what traffic to capture. The action says what to do with it. TypeScript catches your mistakes before the proxy even starts.

30 Seconds to HTTPS

import { SmartProxy } from '@push.rocks/smartproxy';

const proxy = new SmartProxy({
  acme: {
    email: 'ssl@yourdomain.com',
    useProduction: true
  },
  routes: [
    // Redirect HTTP → HTTPS
    {
      name: 'redirect-to-https',
      match: { ports: 80, domains: 'app.example.com' },
      action: {
        type: 'socket-handler',
        socketHandler: SocketHandlers.httpRedirect('https://{domain}{path}', 301)
      }
    },
    // Terminate TLS, forward to backend
    {
      name: 'app-https',
      match: { ports: 443, domains: 'app.example.com' },
      action: {
        type: 'forward',
        targets: [{ host: 'localhost', port: 3000 }],
        tls: { mode: 'terminate', certificate: 'auto' }
      }
    }
  ]
});

await proxy.start();

Two routes. The first catches HTTP on port 80 and redirects to HTTPS using a built-in socket handler with template variables ({domain}, {path}). The second terminates TLS on port 443 with an automatic Let's Encrypt certificate and forwards plain HTTP to your backend. No certificate files to manage. No cron jobs for renewal. The Rust engine handles ACME challenges, stores nothing to disk, and calls back into your TypeScript code if you want custom persistence.

The Route Model

Every route in SmartProxy follows the same shape:

{
  name: 'api-route',
  match: {
    ports: 443,
    domains: 'api.example.com',
    path: '/v1/*'
  },
  action: {
    type: 'forward',
    targets: [{ host: 'backend', port: 8080 }],
    tls: { mode: 'terminate', certificate: 'auto' }
  }
}

The match block supports ports (single, array, or ranges), domains (exact or wildcard), paths, transport protocol (tcp, udp, or all), application-layer protocol (http, tcp, quic), client IP ranges, TLS versions, and HTTP headers. The action block is either forward (proxy to backends) or socket-handler (hand the raw socket to your TypeScript function). Every field is typed. The match criteria compose — you can have a route that only fires for QUIC traffic from a specific IP range on a specific port with a specific SNI hostname.

Routes are evaluated in priority order. First match wins. You can update them at runtime with proxy.updateRoutes() — the operation is atomic and mutex-locked, so in-flight connections aren't affected.

Three TLS Modes

SmartProxy supports three ways to handle TLS, and the choice matters:

Passthrough routes encrypted traffic based on the SNI hostname without decrypting it. The backend handles TLS. The proxy never sees plaintext. This is what you want when you can't or don't want to terminate TLS at the proxy layer.

{
  name: 'tls-passthrough',
  match: { ports: 443, domains: 'secure.example.com' },
  action: {
    type: 'forward',
    targets: [{ host: 'backend-that-handles-tls', port: 8443 }],
    tls: { mode: 'passthrough' }
  }
}

Terminate decrypts at the proxy and forwards plain HTTP to the backend. This is the standard reverse proxy model. The proxy can inspect HTTP headers, match paths, add headers, and do request-level routing.

Terminate-and-reencrypt decrypts at the proxy, then re-encrypts to the backend. HTTP traffic gets full per-request routing (Host header, path matching) via the HTTP proxy; non-HTTP traffic uses a raw TLS-to-TLS tunnel. This is for zero-trust environments where traffic must be encrypted on every hop.

The Rust Engine

All networking — TCP listeners, TLS handshakes, HTTP parsing, connection pooling, security enforcement, metrics collection, UDP sockets, QUIC — runs inside a Rust binary. The TypeScript process communicates with it over JSON IPC on stdin/stdout. This isn't an FFI binding or a WASM module. It's a separate process.

The architecture diagram tells the story:

┌─────────────────────────────────────────────────┐
│              Your Application                    │
│     (TypeScript — routes, config, handlers)      │
└──────────────────┬──────────────────────────────┘
                   │  IPC (JSON over stdin/stdout)
┌──────────────────▼──────────────────────────────┐
│              Rust Proxy Engine                    │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐           │
│  │ TCP/TLS │ │  HTTP    │ │  Route  │           │
│  │ Listener│ │  Proxy   │ │ Matcher │           │
│  └─────────┘ └─────────┘ └─────────┘           │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐           │
│  │   UDP   │ │Security │ │ Metrics │           │
│  │  QUIC   │ │ Enforce │ │ Collect │           │
│  └─────────┘ └─────────┘ └─────────┘           │
└─────────────────────────────────────────────────┘

The process split is deliberate. The Rust engine doesn't parse config files. The TypeScript side never touches a raw packet. When a route uses a JavaScript socket handler or a dynamic host function (a callback that can't be serialized to Rust), the Rust engine relays that connection back to a TypeScript-side Unix socket server. Everything else stays in Rust.

Ecosystem note. The TypeScript/Rust bridge pattern keeps configuration and API ergonomics in TypeScript while the Rust subprocess owns the packet path. smartproxy is one of the clearest examples because route objects stay typed and byte handling stays native.

Load Balancing with Health Checks

{
  name: 'load-balanced-app',
  match: { ports: 443, domains: 'app.example.com' },
  action: {
    type: 'forward',
    targets: [
      { host: 'server1.internal', port: 8080 },
      { host: 'server2.internal', port: 8080 },
      { host: 'server3.internal', port: 8080 }
    ],
    tls: { mode: 'terminate', certificate: 'auto' },
    loadBalancing: {
      algorithm: 'round-robin',
      healthCheck: {
        path: '/health',
        interval: 30000,
        timeout: 5000,
        unhealthyThreshold: 3,
        healthyThreshold: 2
      }
    }
  }
}

Three algorithms: round-robin, least-connections, and ip-hash. Health checks run at the configured interval and remove backends that fail the unhealthy threshold. They come back when they pass the healthy threshold. No external health checker needed.

UDP, QUIC, and HTTP/3

SmartProxy isn't TCP-only. Set transport: 'udp' in a route match and you're listening for datagrams. Pair it with a datagramHandler and you can implement any UDP protocol in TypeScript:

const udpHandler: TDatagramHandler = (datagram, info, reply) => {
  console.log(`UDP from ${info.sourceIp}:${info.sourcePort}`);
  reply(datagram); // Echo it back
};

const proxy = new SmartProxy({
  routes: [{
    name: 'udp-echo',
    match: { ports: 5353, transport: 'udp' },
    action: {
      type: 'socket-handler',
      datagramHandler: udpHandler,
      udp: {
        sessionTimeout: 60000,
        maxSessionsPerIP: 100,
        maxDatagramSize: 65535
      }
    }
  }]
});

For QUIC and HTTP/3, set protocol: 'quic' and configure TLS (QUIC requires TLS 1.3). SmartProxy can receive QUIC on the frontend and translate to TCP

The Rust-hybrid stack goes production.

Over the past two months, the code.foss.global ecosystem underwent a fundamental architectural shift: critical infrastructure projects gained Rust data planes while keeping TypeScript control planes. February laid the groundwork -- Rust networking engines, IPC bridges, and toolchain automation. March turned that groundwork into shippable products: a self-hosted S3-compatible storage appliance, a multi-protocol package registry, a unified datacenter gateway handling seven protocol families, and a VPN system that matured from proof-of-concept to deployment-ready.

The Hybrid TypeScript/Rust Architecture

The foundation enabling this shift is @push.rocks/smartrust, the bridge library that establishes IPC channels between TypeScript processes and compiled Rust binaries via stdio and Unix domain sockets. smartrust handles serialization, process lifecycle, and bidirectional message passing, letting any TypeScript module offload compute-intensive work to a Rust subprocess without abandoning its existing API surface.

@git.zone/tsrust complements this with zero-setup Rust toolchain management and cross-compilation. It detects the host platform, downloads the appropriate Rust toolchain on first run, and compiles Rust crates as part of the standard pnpm build pipeline. No manual rustup or cargo configuration required.

@git.zone/tsdeno launched in March as a new companion tool: a smart wrapper around deno compile that isolates package.json during compilation, preventing devDependencies from inflating binaries by hundreds of megabytes. It supports cross-compilation, config-based multi-target builds, and a programmatic API for CI/CD integration.

Ecosystem note. The Rust/TypeScript bridge keeps the public API and build workflow in TypeScript while moving packet, storage, media, or VM data paths into Rust subprocesses where native I/O is useful.

dcrouter: The All-In-One Datacenter Gateway

@serve.zone/dcrouter was the most actively developed project across both months. What started as an HTTP reverse proxy is now a unified infrastructure gateway consolidating seven protocol-level services into a single deployment.

HTTP/HTTPS with Automatic TLS -- TLS termination with automatic certificate provisioning via ACME, including Cloudflare DNS-01 challenges for wildcard certificates. Routing decisions are based on SNI and Host headers, supporting both termination and transparent passthrough for services that manage their own certificates.

HTTP/3 and QUIC -- A full QUIC listener alongside the TCP stack enables HTTP/3 for clients that support it. The QUIC implementation shares the same routing table as the HTTP/1.1 and HTTP/2 paths, so configuration is unified regardless of transport.

TCP/SNI Proxying -- Transparent TCP passthrough based on SNI extraction from the TLS ClientHello, for services that require end-to-end TLS without termination at the gateway.

Multi-Domain SMTP -- An integrated SMTP server (powered by smartmta) with per-domain routing, DKIM signing, SPF validation, and DMARC policy enforcement. Inbound mail is routed to backend services based on recipient domain, making dcrouter the MX entry point.

DNS Server (Rust-backed) -- An authoritative DNS responder implemented in Rust for packet parsing and response assembly, serving zone data configured through dcrouter's TypeScript API. Eliminates the need for a separate DNS daemon.

RADIUS Authentication -- Network device authentication via RADIUS supporting PAP, CHAP, MAC-based authentication, and VLAN assignment. This enables dcrouter to serve as the AAA backend for switches, access points, and VPN concentrators.

Remote Ingress -- A NAT traversal system allowing nodes behind firewalls to register with dcrouter edge instances and receive proxied traffic via persistent WebSocket or QUIC tunnels with PROXY protocol headers to preserve client IP information.

OpsServer Dashboard -- A built-in web UI exposing real-time connection counts, throughput graphs, certificate status, and per-route health checks.

The result is a single deployment that replaces nginx, postfix, bind, freeradius, and a reverse tunnel service.

smartproxy: Kernel-Level Forwarding and Unified Route Config

@push.rocks/smartproxy reached a major milestone in March with a complete routing overhaul and kernel-level packet forwarding.

Unified Route-Based Configuration -- All proxy behavior is now defined through a single route configuration system. Each route specifies match criteria (domain patterns, IP ranges, ports), the action (forward, terminate, redirect, block), and backend targets. This replaces the previous separate configuration for HTTP, TCP, and TLS modes.

NFTables Kernel-Level Forwarding -- For high-throughput passthrough routes, smartproxy can now install NFTables rules to forward packets entirely in kernel space, bypassing both the Rust and Node.js layers. The TypeScript API manages rule lifecycle while the actual forwarding happens at line rate in the kernel's netfilter subsystem.

Rust Networking Engine -- Connection acceptance, TLS handshake, protocol detection, and byte-level forwarding all run in Rust. The Rust engine communicates with TypeScript via socket-based IPC. For passthrough routes, bytes never touch the Node.js event loop. For terminated routes, the Rust layer handles TLS and forwards plaintext to the TypeScript-managed backend pool.

PROXY Protocol v1/v2 -- Both sending and receiving PROXY protocol headers, enabling smartproxy to sit behind or in front of other proxies while preserving original client addresses through the entire chain.

JWT Authentication -- Route-level JWT validation with configurable JWKS endpoints, claim-based routing decisions, and token refresh handling.

IP Filtering and Rate Limiting -- Per-route IP allowlists/denylists and token-bucket rate limiting, evaluated in the Rust layer before connections reach backend services.

Real-Time Metrics -- Per-connection byte counters and throughput sampling at configurable intervals, exposed via IPC and a Prometheus-compatible HTTP endpoint.

Ecosystem note. smartproxy is the shared proxy engine beneath dcrouter and related gateway services. dcrouter owns the operator-facing control plane; smartproxy owns route matching and network forwarding.

lossless.zone/objectstorage: Self-Hosted S3 in a Single Docker Image

lossless.zone launched as a new organization in March, debuting with objectstorage -- a fully-featured, self-hosted S3-compatible storage server with a web-based management interface packaged as a single Docker image.

Rust Storage Engine -- Built on @push.rocks/smartstorage, the storage layer uses hyper 1.x with streaming I/O, zero-copy data paths via sendfile(2), and optional Reed-Solomon erasure coding for distributed deployments.

SigV4 Authentication -- Full AWS Signature Version 4 request signing, making it compatible with any S3 client library, the AWS CLI, and tools like rclone or s3cmd.

IAM-Style Policy System -- Bucket-level access policies with principal-based permissions, enabling fine-grained access control for multi-tenant deployments.

@push.rocks/smartvpn tunnels all VPN traffic inside a standard WebSocket connection over HTTPS. To any firewall, DPI box, or network observer, it looks indistinguishable from ordinary web traffic (the same kind of connection a chat app or real-time dashboard would open on port 443). It passes through Cloudflare, corporate proxies, and restrictive networks that block traditional VPN protocols on sight. Under the hood, smartvpn splits the work between a TypeScript control plane for configuration, client management, and telemetry, and a Rust data plane that handles encryption, tunneling, QoS, and packet classification at native speed. The two halves talk over typed JSON-lines IPC. Neither side compromises.

The Architecture in 30 Seconds

Your TypeScript code instantiates a VpnClient or VpnServer. Under the hood, smartvpn uses @push.rocks/smartrust to spawn a Rust binary (smartvpn_daemon) and opens a bidirectional JSON channel to it, either over stdio for development or a Unix socket for production. Every method call on the TypeScript side becomes a JSON command to the Rust daemon. Every response is typed end to end.

The Rust daemon handles everything that needs to be fast: Noise NK handshakes, XChaCha20-Poly1305 encryption with random 24-byte nonces, TUN device I/O, a three-tier priority queue (ICMP/DNS/SSH at the top, bulk flows at the bottom), per-client token-bucket rate limiting, adaptive keepalives, and automatic path MTU calculation. The TypeScript side never touches a raw packet. The Rust side never parses a config file.

Ecosystem note. @push.rocks/smartrust is the runtime side of the TypeScript/Rust bridge. smartvpn uses it so callers work with VpnClient and VpnServer while a Rust daemon handles privileged packet and crypto work.

What the TypeScript Looks Like

Connecting as a client is about what you would expect from a well-designed Node library:

import { VpnClient } from '@push.rocks/smartvpn';

const client = new VpnClient({
  transport: { transport: 'stdio' },
});
await client.start();

const { assignedIp } = await client.connect({
  serverUrl: 'wss://vpn.example.com/tunnel',
  serverPublicKey: 'BASE64_SERVER_PUBLIC_KEY',
  dns: ['1.1.1.1', '8.8.8.8'],
  mtu: 1420,
});
console.log(`Connected: ${assignedIp}`);

That's it. Behind that await, the TypeScript layer spawned a Rust daemon, negotiated a Noise NK handshake with the server, stood up a TUN interface, and started routing encrypted traffic through a WebSocket tunnel. The transport choice (WebSocket over HTTPS) is deliberate. It passes through Cloudflare, corporate proxies, and anything else that terminates TLS. Most WireGuard setups choke in these environments. smartvpn doesn't.

Once connected, you get real-time telemetry for free. Call client.getConnectionQuality() and you get back smoothed RTT, jitter, loss ratio, and a link health classification (healthy / degraded / critical) — all measured by the daemon's own adaptive keepalive system, not by WebSocket pings that Cloudflare would swallow.

Easy Serverside Control over Clients

The server API (via VpnServer class) gives you a typed control surface over every connected client, and you can change anything at runtime without dropping connections.

You can list clients, pull per-client telemetry (bytes in/out, packets dropped, keepalive history), set individual rate limits with server.setClientRateLimit(), and kick anyone with server.disconnectClient(). Rate limits use a token-bucket algorithm at byte granularity in the Rust daemon. When you call setClientRateLimit('client-id', 5_000_000, 10_000_000), the bucket parameters change in the Rust process instantly — no reconnection, no config reload, no restart. Most VPN stacks need custom C extensions for this kind of runtime control.

KeepAlive and Adaptive HealthChecks

If you tunnel over WebSocket through a reverse proxy like Cloudflare, your WebSocket-level pings get swallowed. The proxy responds on behalf of the server, so your client thinks the link is healthy when the backend might be dead. smartvpn solves this with application-level keepalives — custom ping/pong frames inside the encrypted tunnel carrying 8-byte timestamps for precise RTT measurement.

The interval adapts. The daemon runs a three-state finite state machine: healthy (60s interval), degraded (30s), and critical (10s). Transitions have hysteresis — you need three consecutive good checks to upgrade from degraded to healthy, two bad ones to downgrade, which prevents the flapping that wastes bandwidth on unstable mobile connections. Dead peer detection fires after three consecutive timeouts in critical state. The whole thing runs inside the Rust process with zero allocations in steady state.

Quality of Service

The Rust data plane classifies every decrypted IP packet into three priority tiers by inspecting headers — no deep packet inspection, just port numbers and packet size. ICMP, DNS (port 53), SSH (port 22), and small packets under 128 bytes get high priority. Bulk flows that exceed 1 MB within a 60-second window get demoted to low. Everything else is normal. The priority channels drain with biased scheduling: high-priority packets always go first.

Under backpressure, the drop policy is equally deliberate: low-priority packets get dropped silently, normal packets get dropped next, and high-priority packets wait up to 5ms before being dropped as a last resort. Drop statistics are tracked per priority level and exposed through the telemetry API. This means your SSH session stays snappy even when someone on the same VPN is saturating the link with a large download.

Crypto Choices

The Noise NK handshake pattern means the client knows the server's static public key upfront but doesn't authenticate itself — the same trust model as connecting to a website via TLS. Two DH operations (ephemeral-static, then ephemeral-ephemeral) produce forward-secret transport keys. Post-handshake, everything goes through XChaCha20-Poly1305 with random 24-byte nonces. The large nonce space means you never need counter synchronization between peers; just generate a random nonce per packet. The wire format is minimal: [nonce:24B][ciphertext][tag:16B], inside a binary frame of [type:1B][length:4B][payload].

The MTU Math

The daemon also calculates tunnel overhead precisely. IP header (20 bytes) + TCP with timestamps (32 bytes) + WebSocket framing (6 bytes) + VPN frame header (5 bytes) + Noise AEAD tag (16 bytes) = 79 bytes of overhead. On a standard 1500-byte Ethernet link, that gives you an effective TUN MTU of 1421 bytes. The default of 1420 is conservative and correct. Oversized packets get an ICMP Fragmentation Needed written

TypeScript is great for building applications. The type system catches bugs, the tooling is mature, and you can hire for it. But if you've ever tried to build a high-throughput TLS proxy, a DNS server with DNSSEC, or an SMTP security pipeline that needs to verify DKIM signatures at wire speed, you know where Node.js starts to hurt: CPU-bound work, memory-sensitive long-running daemons, and anything that needs to talk to the kernel.

We ran into this repeatedly at foss.global, where we build open-source infrastructure tools for startups and SMEs. Our answer wasn't to rewrite everything in Rust. Instead, we built two packages that let TypeScript and Rust coexist in the same project, compiled with a single pnpm build, and connected by typed IPC at runtime. Today, eight of our production services use this pattern.

The Two Packages

@git.zone/tsrust is the build side. It follows the same convention as @git.zone/tsbuild: TypeScript source lives in ts/ and compiles to dist_ts/. Rust source lives in rust/ and compiles to dist_rust/. Running tsrust from your project root parses the Cargo workspace, calls cargo build --release, and copies the binaries into dist_rust/.

@push.rocks/smartrust is the runtime side. It provides RustBridge<T>, a generic class that spawns a Rust binary (or connects to an existing daemon via Unix socket), talks to it over newline-delimited JSON, and gives you typed sendCommand() calls.

Your build script looks like this:

{
  "scripts": {
    "build": "tsbuild tsfolders && tsrust"
  }
}

Both languages compile in one step.

Ecosystem note. @git.zone packages usually own build and workspace tooling, while @push.rocks packages provide reusable runtime libraries. tsrust and smartrust split the Rust bridge along that same line: build first, IPC at runtime.

No Rust Installation Required

tsrust can install Rust for you. If cargo isn't on the system, it downloads a minimal toolchain (~70-90 MB) to /tmp/tsrust_toolchain/ and reuses it on subsequent runs. This means pnpm install && pnpm build works on a fresh CI runner or a teammate's machine that has never seen Rust before.

Cross-compilation uses friendly target names:

tsrust --target linux_arm64 --target linux_amd64

The output binaries get platform suffixes (rustproxy_linux_arm64, rustproxy_linux_amd64), and the TypeScript bridge knows how to find the right one at runtime based on process.platform and process.arch.

How the Bridge Works

You start by defining a type map that describes every command the Rust binary supports:

type TDnsCommands = {
  start: {
    params: { config: IDnsConfig };
    result: Record<string, never>;
  };
  stop: {
    params: Record<string, never>;
    result: Record<string, never>;
  };
  ping: {
    params: Record<string, never>;
    result: { pong: boolean };
  };
};

Then you create a bridge and call commands on it:

import { RustBridge } from '@push.rocks/smartrust';

const bridge = new RustBridge<TDnsCommands>({
  binaryName: 'rustdns-server',
  cliArgs: ['--management'],
  requestTimeoutMs: 30_000,
  localPaths: [
    path.join(packageDir, 'dist_rust', 'rustdns-server'),
  ],
});

const ok = await bridge.spawn();
if (!ok) throw new Error('Failed to start DNS server');

// params and return type are inferred from TDnsCommands
await bridge.sendCommand('start', { config: myDnsConfig });

const { pong } = await bridge.sendCommand('ping', {});

Under the hood, the protocol is newline-delimited JSON over stdin/stdout. The Rust binary reads a JSON request, does its work, and writes a JSON response. No FFI, no native addons, no node-gyp. Two processes talking over a pipe.

Stdio vs. Socket Mode

bridge.spawn() launches the Rust binary as a child process. Your TypeScript app owns the lifecycle.

bridge.connect('/var/run/daemon.sock') connects to a Rust process that's already running, typically as a system service. This matters when the Rust side needs root privileges (binding to port 443, managing TUN devices for a VPN) but the TypeScript control plane should run unprivileged. Socket mode has auto-reconnect with exponential backoff:

await bridge.connect('/var/run/smartvpn.sock', {
  autoReconnect: true,
  reconnectMaxDelayMs: 30_000,
  maxReconnectAttempts: 10,
});

The sendCommand() API is the same in both modes.

Streaming

Some operations produce output over time: a traceroute returning hops one by one, a log tail, a chunked file transfer. For these, you add a chunk type to your command definition and use sendCommandStreaming:

type TNetworkCommands = {
  traceroute: {
    params: { host: string; maxHops?: number };
    chunk: { ttl: number; ip: string; rtt: number | null };
    result: { totalHops: number };
  };
};

const stream = bridge.sendCommandStreaming('traceroute', { host: 'example.com' });

for await (const hop of stream) {
  console.log(`Hop ${hop.ttl}: ${hop.ip} (${hop.rtt}ms)`);
}

const result = await stream.result;
console.log(`Trace complete: ${result.totalHops} hops`);

The timeout resets on each chunk, so it works as an inactivity timer rather than an absolute deadline.

What's Running in Production

This pattern isn't theoretical. Here's what we've shipped with it:

smartproxy is an HTTP/TLS reverse proxy. The Rust side is 8 workspace crates handling TLS termination (with automatic Let's Encrypt via ACME), domain-based routing, SNI passthrough, nftables integration, and Prometheus metrics export. TypeScript handles configuration and route management.

smartmta is a mail transfer agent. Rust runs the SMTP server and client, connection pooling, and a full security pipeline: DKIM signing and verification, SPF validation, DMARC policy enforcement, IP reputation checks, and content scanning. It uses tokio for async I/O and mimalloc to avoid memory fragmentation in long-running processes.

smartdns is a DNS server with DNSSEC. The Rust workspace handles protocol parsing, UDP and DNS-over-HTTPS serving, key management, and zone signing. TypeScript provides the configuration and zone management API.

smartfs wraps filesystem operations in a Rust daemon that handles file reads, writes, atomic operations, and filesystem watching (via the notify crate). The TypeScript side connects over a Unix socket.

smartnetwork does ICMP ping and traceroute. It uses cross-compiled, platform-suffixed binaries (rustnetwork_linux_amd64, rustnetwork_macos_arm64) so the right binary is picked up at runtime.

smartvpn is a VPN daemon using the Noise protocol for encryption. It runs as a privileged system service; TypeScript connects over a Unix socket to manage tunnels.

Why JSON-over-IPC Instead of FFI or WASM

There are other ways to call Rust from TypeScript. napi-rs gives

smartproxy A proxy built for handling high workloads — now internally powered by Rust for maximum performance.

smartproxy

a proxy for handling high workloads of proxying, internally using rust for performance.

GiteaJuergen Kunz

smartproxy retains the exact same TypeScript interface as before, but uses Rust under the hood for all network operations.

Ecosystem note. The recurring Rust move in foss.global packages is to keep the TypeScript surface stable and shift workload-heavy internals into Rust where native networking or OS access matters. smartproxy is an early example of that boundary.

We'll continue optimizing foss.global products and further leverage Rust across the ecosystem where it makes a real difference — without sacrificing the ease of use you get from TypeScript-based packages.

Happy coding.

The foss.global team.