Infrastructure

@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

May connected the operating layer that the April update made visible. April added persisted configuration, dashboards, migration tooling, identity-backed access, and operational metrics. May made those pieces speak the same install, upgrade, security, telemetry, and release languages.

App templates stopped being duplicated metadata. Onebox and Cloudly started sharing the same runtime model. DcRouter and RemoteIngress moved toward authenticated, observable, binary-distributed edge infrastructure. idp.global gained MFA and passkeys. GitZone made releases and remote workspaces more structured. New product surfaces landed around home automation, digital signing, and finance/compliance data.

The common May pattern was ownership boundaries becoming explicit: who can install, who can upgrade, which gateway client owns a route, which VPN identity can reach a target, which tenant owns storage, and which tool is allowed to run an interactive process.

serve.zone: App Store and hosted runtime converge

The largest May story across serve.zone was the move from app hosting as a local feature to App Store-driven runtime management shared by Onebox and Cloudly.

Shared App Store contracts. @serve.zone/appstore introduced a resolver client for linked servezone.appstore.json manifests, digest-tracked Docker image resolution, and curated template metadata in the 0.2.x line. @serve.zone/interfaces renamed the older app catalog contracts into App Store contracts, added upgrade preview and operation tracking, then extended the model with hosted app lifecycle and parent upgrade contracts.

Onebox becomes a stronger single-server PaaS. Onebox moved from the 1.25.x line to 3.0.0 in May. It gained dcrouter gateway client support for domains, DNS records, and route ownership; managed local dcrouter mode; grouped dashboard navigation; dedicated Admin UI domain routing; App Store support for declared volumes and raw published ports; runtime update prompts; self-upgrades launched safely outside the service cgroup; digest-tracked App Store images; upgrade progress tracking; interactive workspace processes; hosted app lifecycle; SmartData persistence; configurable storage classes; strict service deletion cleanup; Valkey naming; and a runtime migration from Deno to Node.js.

Cloudly consumes the same runtime model. Cloudly moved through the 5.6.0 to 6.4.3 line with grouped SPA navigation, service detail pages, live deployments, runtime actions, deployment IDE access, node jump codes, Spark telemetry ingestion, App Store browsing and installation, upgrade previews, async upgrade progress, hosted app lifecycle reporting, and parent upgrade controls when Cloudly itself runs as a hosted service.

Templates become operational objects. The App Store work went beyond catalog presentation. Templates now carry source provenance, resolved manifests, upgrade strategy, digest-pinned image data, volume declarations, published-port declarations, platform requirements, and hosted lifecycle expectations. Redis naming was replaced with Valkey across templates, platform requirements, contracts, UI labels, and runtime data migrations.

Onebox and Cloudly now point at the same application operations layer: one manifest model, one install flow, one upgrade model, and one hosted app lifecycle protocol across single-server and cluster deployments.

Ecosystem note. serve.zone is the hosting and operations product line in the foss.global stack. Onebox covers the single-server runtime, Cloudly covers clustered deployments, and App Store manifests give both the same install and upgrade contract.

dcrouter and RemoteIngress: authenticated edge operations

@serve.zone/dcrouter stayed one of the most active infrastructure projects in May. April expanded what the gateway could manage. May hardened who can manage it, how it is installed, and how operators can inspect live traffic.

Gateway client ownership. DcRouter 13.26.0 through 13.28.0 added persistent gateway client management, scoped gateway-client tokens, token-bound route and DNS ownership, hostname restrictions, allowed route targets, and dashboard administration for gateway clients. This gives systems like Onebox a narrower way to synchronize routes and DNS records without sharing a broad admin token or spoofing another client.

Admin bootstrap and API token auth. OpsServer moved toward persisted account-based administration. The May release line added first-admin bootstrap endpoints, database-backed admin accounts, optional idp.global login, admin user create/delete flows, environment-managed admin API token rotation, and scoped API token authorization across config, logs, stats, security, VPN, RADIUS, remote ingress, users, API tokens, and related handlers.

VPN authorization moves to authenticated metadata. DcRouter and the underlying smartproxy and smartvpn stack shifted VPN route authorization away from simple IP allow-list mutation. SmartVPN can now forward real client source IPs and authenticated VPN metadata through trusted PROXY v2 headers, while SmartProxy enforces VPN client ID and assigned-IP grants per connection. DcRouter maps target profiles to those grants and keeps live client source IPs visible as status data.

Network intelligence and RADIUS. DcRouter added queued IP intelligence observation, filtered retrieval for security views, top connected ASN activity, active connection snapshots from SmartProxy, and RADIUS integration backed by smartradius network secrets, including CIDR-based secret resolution and additional RADIUS attributes.

RemoteIngress performance and distribution. RemoteIngress 4.18.0 through 4.22.3 reduced TCP/TLS tunnel copy overhead, deferred upstream connects until first client data, added first-data and client-write timeouts, introduced server-first port handling, fixed stale-frame and QUIC stream exhaustion cases, and added Linux binary builds plus a one-line installer. DcRouter consumed those changes, added per-edge performance overrides, exposed hub settings management, and added its own CLI binary distribution and installer documentation.

By the end of May, dcrouter was no longer only a configured gateway service. It was becoming an installable edge product with scoped client ownership, identity-aware route security, live connection visibility, and tunable tunnel behavior.

Ecosystem note. dcrouter is the serve.zone edge control plane for routes, DNS, certificates, VPN access, RADIUS, and remote ingress. The May ownership work narrows what each gateway client can change.

push.rocks: network, storage, and AI substrate

The serve.zone work depended on a broad May round of push.rocks library releases.

SmartProxy and SmartVPN. @push.rocks/smartproxy gained authenticated VPN route security from trusted PROXY v2 metadata in 27.11.0, active connection snapshots with per-connection byte counters and protocol metadata in 27.12.0, CA-chain preservation for provisioned certificates, mixed port-range route matching, dedicated WebSocket lifecycle timeouts, and effective-client-IP rate limiting after PROXY parsing. @push.rocks/smartvpn added PROXY v2 real-source forwarding with

@push.rocks/smartvm is a TypeScript control layer for Amazon Firecracker. It downloads and caches Firecracker binaries, resolves bootable base images, starts microVMs through the Firecracker Unix-socket API, creates host networking, stages ephemeral drives, applies optional egress controls, and cleans up the mess when a VM is done.

The point is simple: Firecracker gives you strong, lightweight VM isolation. smartvm gives you a programmable way to use it without writing the same shell scripts, socket calls, TAP setup, bridge setup, and cleanup code for every project.

Why Firecracker Needs a Control Layer

Firecracker is intentionally small. It is a virtual machine monitor, not a platform. That is part of its strength. It exposes an HTTP API over a Unix domain socket and expects the host to provide the rest: kernel image, root filesystem, network devices, boot arguments, process lifecycle, and cleanup.

That leaves every user building the same operational layer:

• Find or download the right Firecracker binary.
• Prepare a kernel and root filesystem.
• Start the VMM with an API socket.
• Wait for the socket and API to become ready.
• Send pre-boot config in the right order.
• Create TAP devices and connect them to host networking.
• Decide how VM traffic leaves the host.
• Stop the VMM and remove sockets, TAPs, bridges, routes, and temp files.

smartvm wraps that host plumbing behind typed TypeScript classes.

SmartVM
  ImageManager          Firecracker binaries, manual kernels, manual rootfs files
  BaseImageManager      cached Firecracker CI or hosted base image bundles
  NetworkManager        TAPs, bridge, NAT, firewall, WireGuard egress
  MicroVM               one Firecracker VM and its state machine
    FirecrackerProcess  child process and socket readiness
    SocketClient        HTTP over Unix socket
    VMConfig            config validation and payload conversion

Your application describes the VM. smartvm handles the host-side sequence.

Ecosystem note. push.rocks packages are reusable infrastructure modules in the foss.global stack. smartvm stays at the control-layer level: it orchestrates Firecracker binaries, sockets, networking, and cleanup while the caller owns the host and workload policy.

The Minimal Boot Path

The happy path is short: create a SmartVM, resolve a base image, create a VM, start it, and clean it up.

import { SmartVM } from '@push.rocks/smartvm';

const smartvm = new SmartVM({
  dataDir: '/tmp/.smartvm',
  runtimeDir: '/dev/shm/.smartvm/runtime',
});

const baseImage = await smartvm.ensureBaseImage({ preset: 'latest' });

const vm = await smartvm.createVM({
  id: 'hello-firecracker',
  bootSource: {
    kernelImagePath: baseImage.kernelImagePath,
    bootArgs: baseImage.bootArgs,
  },
  machineConfig: {
    vcpuCount: 1,
    memSizeMib: 256,
  },
  drives: [
    {
      driveId: 'rootfs',
      pathOnHost: baseImage.rootfsPath,
      isRootDevice: true,
      isReadOnly: baseImage.rootfsIsReadOnly,
    },
  ],
});

try {
  await vm.start();
  console.log(vm.state); // running
  console.log(await vm.getVersion());
  console.log(await vm.getInfo());
} finally {
  if (vm.state === 'running' || vm.state === 'paused') {
    await vm.stop();
  }
  await vm.cleanup();
  await smartvm.cleanup();
}

That snippet hides a lot of host work. Firecracker is downloaded or reused. A base image bundle is resolved and cached. A per-VM runtime directory is created. A Unix socket path is assigned. Writable drives are staged if needed. Firecracker is started as a child process. The API socket is polled until ready. Configuration is sent through the socket. The instance is booted. Cleanup tears down the process and host resources owned by the instance.

Real Isolation, Real Host Requirements

smartvm is TypeScript, but it is not pretending that Firecracker is portable JavaScript. Firecracker is a Linux/KVM technology.

You need a Linux host with /dev/kvm. If you use networking, you need privileges for TAP devices, bridges, IP forwarding, iptables, policy routing, and optional WireGuard setup. The host also needs normal system tools such as curl, tar, ip, sysctl, and iptables; WireGuard routing needs wg.

That constraint is useful to state clearly. smartvm is not a local toy VM emulator. It is a typed operations layer for real microVMs on a real Linux host.

Ephemeral by Default

The most important design choice in smartvm is its runtime model. VMs are treated as disposable execution units unless you opt into persistence.

By default, runtime files go into tmpfs when available:

The default is: immutable base image, staged writable copy, no accidental mutation of cached root filesystems.

const vm = await smartvm.createVM({
  bootSource: {
    kernelImagePath: baseImage.kernelImagePath,
    bootArgs: baseImage.bootArgs,
  },
  machineConfig: {
    vcpuCount: 1,
    memSizeMib: 256,
  },
  drives: [
    {
      driveId: 'rootfs',
      pathOnHost: '/images/rootfs.ext4',
      isRootDevice: true,
      isReadOnly: false,
      ephemeral: true,
    },
  ],
});

If you need persistent state, say so explicitly:

const vm = await smartvm.createVM({
  bootSource: {
    kernelImagePath: '/images/vmlinux',
    bootArgs: 'console=ttyS0 reboot=k panic=1 pci=off',
  },
  machineConfig: {
    vcpuCount: 2,
    memSizeMib: 512,
  },
  drives: [
    {
      driveId: 'state',
      pathOnHost: '/var/lib/my-vm/state.ext4',
      isRootDevice: true,
      isReadOnly: false,
      ephemeral: false,
    },
  ],
});

This default is the right bias for worker pools, test isolation, CI jobs, sandboxed execution, disposable service instances, and workloads where durable state belongs in an external database, object store, or explicit persistent volume.

Base Images Without Checking Rootfs Files Into Git

Firecracker needs a kernel image and a root filesystem. smartvm has two layers for that.

ImageManager is the lower-level helper for binaries, kernels, rootfs downloads, blank rootfs creation, and cloning. It is useful when you already know what files you want.

BaseImageManager is the higher-level path. It resolves bootable Firecracker CI image bundles through presets or a project-owned hosted manifest.

const latest = await smartvm.ensureBaseImage();
const lts = await smartvm.ensureBaseImage({ preset: 'lts' });
const hosted = await smartvm.ensureBaseImage({
  preset: 'hosted',
  manifestUrl: 'https://assets.example.com/smartvm/manifest.json',
});

The presets are deliberately pragmatic:

Cached base image bundles are stored under /tmp/.smartvm/base-images by default. The cache keeps two bundles unless configured otherwise. Cached artifacts are checked for

@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.

Across the ecosystem, the recurring pattern was clear: services gained durable state, explicit policy models, and admin surfaces that make them manageable in production rather than merely functional in isolation.

dcrouter: From Gateway to Datacenter Control Plane

@serve.zone/dcrouter remained the most active infrastructure project in April, reaching the 13.20.x release line and expanding from protocol gateway into a broader datacenter edge control plane.

DB-backed DNS management -- DNS providers, domains, and records are now persisted and managed through the runtime and Ops UI. Provider-managed domains can be mirrored locally for API and dashboard visibility while remaining authoritative at the upstream provider. dcrouter-hosted domains are handled directly by the built-in DNS path.

ACME configuration in the dashboard -- Certificate behavior moved into database-backed configuration with reusable UI flows for provider setup and domain/certificate management. April also aligned dcrouter with smartacme's new forced-renewal support, including safeguards around valid certificates.

Email domain lifecycle management -- Email domains can now be created and managed through dcrouter with DKIM generation, DNS provisioning, validation, optional subdomain support, persistent smartmta storage, and runtime synchronization between configured domains and the mail server.

Unified route ownership -- Route management was reorganized around persisted route origins: config, email, dns, and api. System-generated routes can be shown separately from user-managed routes, while API-owned routes support full CRUD. This gives dcrouter one route model across HTTP, DNS, email, remote ingress, and programmatic configuration.

Profile-based VPN access -- The VPN access model moved away from tag-based rules toward source and target profiles. Source profiles describe who or what is connecting; target profiles describe reachable networks, hosts, and ports. Routes can then reference those profiles instead of embedding ad hoc access rules.

Remote ingress controls -- Route configuration gained remote ingress controls and preserve-port targeting, making tunnel-backed services easier to expose without losing backend port semantics.

Ops dashboard reorganization -- The web UI was reorganized into grouped operations areas covering overview, domains, DNS, certificates, email, access, security, network, routes, VPN, and remote ingress. Tables gained filtering, live update highlighting, and clearer monitoring views as dees-catalog evolved underneath.

Network monitoring -- dcrouter now consumes the richer smartproxy metrics model: protocol distribution, bandwidth-ranked IP and domain activity, request-based domain aggregation, and route-aware traffic statistics.

The result is a gateway that is no longer configured only as a static edge process. It is becoming the operational system of record for routing, certificates, DNS, email, VPN access, and ingress policy.

Ecosystem note. dcrouter is the serve.zone edge control plane. In monthly updates it usually means routing, certificates, DNS, mail, VPN access, and ingress policy are moving from static config into managed runtime state.

callrouter: A Rust-Backed Telephony Stack

April introduced heavy activity around @serve.zone/callrouter, a SIP and WebRTC routing system with a TypeScript control plane and Rust media/SIP data plane.

SIP B2BUA and WebRTC bridge -- callrouter handles SIP provider and device legs, browser WebRTC legs, and internal tool or recording legs as a multi-leg call hub. The architecture is built around controlled call legs rather than a simple pass-through proxy.

Rust proxy engine -- SIP dialog handling, RTP port management, WebRTC bridging, outbound calling, voicemail, IVR, recording, and dashboard event reporting are handled by a Rust-backed proxy engine integrated with the TypeScript runtime.

Audio engine upgrades -- The media pipeline moved to 48 kHz float processing with adaptive RTP jitter buffering, stable 20 ms resampling, Opus packet loss concealment, negotiated SDP payload handling, and per-leg denoising.

Voicemail, IVR, and TTS -- April added DTMF-driven IVR flows, prompt playback, voicemail recording, dashboard management, and Kokoro-based TTS generation with caching and live streaming interaction support.

Guided provider setup -- The dashboard gained guided provider creation, explicit inbound DID routing, provider-based number matching, incoming number ranges, and improved diagnostics for inbound routing.

Fax support -- The 1.26.x line added fax routing, job tracking, inbox management, and T.38/UDPTL media support.

Docker release pipeline -- callrouter also gained multi-architecture Docker build support and tagged release automation.

This is a new major building block for serve.zone: telephony, browser calling, voicemail, IVR, and fax in the same infrastructure style as the existing gateway stack.

idp.global and Swift Tooling: Identity Moves to Devices

April's identity work connected backend authentication, native clients, and Swift automation.

idp.global authentication hardening -- idp.global added argon2 password hashing, legacy hash migration, rotating hashed refresh tokens, refresh-token reuse detection, and persisted email action tokens and registration sessions.

OIDC persistence and consent -- Authorization codes, access tokens, refresh tokens, and user consent records are now stored in SmartData-backed persistence with hashed token storage. OIDC flows gained consent-aware continuation after login and stronger abuse protection around login, magic links, password reset, and token exchange.

Passport device flows -- The identity provider gained passport device enrollment, signed device requests, challenge approval, push token registration, alert lifecycle APIs, and alert-rule management. This pushes identity beyond password/OIDC sessions toward device-backed approvals.

Native companion app -- idp.global/swiftapp built out a SwiftUI companion app for iPhone, iPad, Mac, and Apple Watch. The app now uses the live idp.global backend by default for pairing, dashboard loading, approvals, and alerts. Pairing includes a welcome flow, QR scanning, manual fallback, NFC pairing, and NFC identity proof with signed GPS position on supported devices.

@git.zone/tsswift -- A new Swift/Xcode workflow CLI emerged in April. tsswift can detect SwiftPM, Xcode project, and workspace layouts; run doctor, build, test, run, emulator, launch, screenshot, review, and watch workflows; persist simulator preferences; and operate named remote macOS builders over SSH with rsync-based project sync. Remote screenshot capture syncs outputs back into the local project.

@api.global/swiftsupport -- api.global gained a Swift transport support package for typedrequest over POST /typedrequest and typedsocket over WebSocket, including typed clients, correlation metadata, retry handling, and typed transport errors.

Together, these pieces make Swift clients first-class participants in the code.foss.global identity and API ecosystem rather than one-off consumers.

Ecosystem note. idp.global is

@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

• @push.rocks/smartbucket got a major overhaul
• host.today now publishes its docker images to code.foss.global as main docker registry.
• We are gradually shifting resources from gitlab to code.foss.global allowing for gitlab to act as mirror. The mirror setup will work by aggregating all projects on gitlab in a congruent pattern under the gitlab.com/foss.global/ namespace.

Ecosystem note. code.foss.global is the canonical forge and registry for foss.global projects. GitLab can remain a mirror, but packages and Docker images are moving to the hosted code.foss.global namespace.

• @api.global/typedserver now contains a complete solution to serve PWAs from development to production. It includes the server with mechanics for live reloading, a service worker, a service worker client that can be imported into your app for control purposes, and last but not least an edgeworker that can be deployed anywhere that supports workerd (like Cloudflare workers).

Ecosystem note. typedserver is the @api.global server layer for typed APIs and web apps. The PWA work adds development reload, service-worker control, and workerd-compatible edge deployment around that runtime.

• We started work on docs.foss.global which will scrape all projects automatically to provide a coherent and automated docs experience.
• You may have noticed a change in project documentation. We are now using @git.zone/tsdoc to create docs using AI.
• `@push.rocks/smartguards` got a major overhaul and is now supported by @api.global/typedrequest