serve.zone

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

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

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.