Topic

serve.zone

Monthly Update - July 2026 July's releases across code.foss.global share one idea: every consequential action should survive being interrupted, and be answerable afterwards. Monthly Update, Engineering, Infrastructure

Most of what goes wrong in operations work is not algorithmic. It is a person losing the thread. A deploy runs, a laptop sleeps, the terminal comes back with nothing useful, and someone has to decide whether running the command again will finish the job or start a second one. A mail server accepts a message and the process that was going to store it dies a moment later. A cleanup pass is halfway through when it is cancelled. The machines in these stories are usually fine. The human is the one left holding a question nobody can answer.

We build open source infrastructure for families, SMEs, and enterprises, and July's work across code.foss.global had one shape running through it: make consequential actions answerable after the fact. The June update was about connecting control planes into live reconciliation loops. July was about making those loops safe to interrupt.

Assume the connection will drop

An action that exists only as "I ran the command" is not an operation, it is a hope. To survive an interruption, a state change needs three things: an identity both sides can name, enough persisted state that it can be resumed rather than restarted, and a rule that tells a second attempt whether it is continuing the same work or beginning different work. Plenty of systems have vaguely idempotent endpoints; far fewer can name the specific piece of work a retry belongs to. Without that name, "just run it again" is advice you give while watching nervously.

Cloudly now treats a deployment as a durable object rather than a request. Reserve, image promotion, route promotion, retry, cleanup, and rollback each carry persisted state bound to an organization and service slot, an exact release tag, an image digest, a configuration digest, and a revisioned rollout. Because a rollout carries a generation, a reconciliation result that arrives late can be matched against the rollout it actually belongs to and rejected if that rollout has moved on. That one rule eliminates a whole family of failures in which stale feedback quietly mutates current state.

@git.zone/tsdeploy implements the client half of the same protocol, and its most useful July behavior is also its least dramatic: when the server completed an operation but the client never saw the response, the next invocation reconciles instead of deploying again. Coreflow made the matching change on the node side by removing mutable tag pulls, cached-tag fallback, and external tag pulls from workload reconciliation entirely. It pulls the digest that was accepted, inspects running tasks for the repository digest they actually resolved to, and reports that evidence back with the rollout it belongs to. Nothing along that path is permitted to answer "close enough."

The same discipline reached the build tools, where it is cheap and unusually effective. @git.zone/tsdocker requires an expected manifest digest for any test or push that does not build, verifies that destination tags resolve to the same content, and rejects digest mappings that are missing or unexpected. @git.zone/tsrust stamps binaries with project, version, commit, target, and build time, and tsrust inspect reads that trailer back out of a built artifact, so provenance becomes a question you can ask rather than something inferred from a filename.

Ecosystem note. Cloudly holds desired state and durable operations, Coreflow reconciles workloads on cluster nodes, and @git.zone/tsdeploy drives the developer-side release flow. July gave all three the same name for the same artifact and the same operation.

Ask for a capability, not a location

The second theme is older than any of our code. An application that names physical resources becomes hard to move, and every hardcoded path, bucket, or endpoint is a promise about infrastructure the application does not control. Those promises come due at the worst possible time, usually during a migration someone is already nervous about. The alternative is to let an application declare what it needs — durable filesystem space, object storage, owned by this workload, reclaimed under this policy — and let the platform decide where that actually lives.

Corestore shipped a v2 named storage-binding API this month with capability negotiation, canonical request digests, revision compare-and-set, credential-slot fencing, and explicit release operations. Its restore path works the same way: signed, operation-scoped grants with durable fences, bounded archive extraction, object hashes, and immutable receipts. Onebox consumes that model directly. An application template asks for a named filesystem or object-storage binding without naming a backend; Onebox selects a configured storage class, persists ownership and reclaim policy, checks upgrade compatibility, and carries the binding through deployment, backup, restore, and removal. @serve.zone/appstore added the normalization and conformance checks that keep older and named declarations from colliding.

Underneath, @push.rocks/smartstorage moved standalone objects onto a canonical layout, gave mounted NFS and SMB pools exact identity, and made migrations carry fenced source and destination state with a terminal abort receipt for anything that stops before cutover. @push.rocks/smartbucket added create-only streamed uploads and exact-path purge with post-delete verification, and carries cancellation through downloads so abandoned reads close their provider streams.

The rule we now use across that layer is simple to state and surprisingly demanding to implement: a coordinator does not infer success from a method that returned. It negotiates a versioned capability first, and it keeps the receipt it needs to resume or release that exact mutation later.

Ecosystem note. push.rocks packages provide the shared database, object-storage, and transport primitives. Corestore and Onebox put those primitives behind serve.zone ownership and binding contracts, so an application asks for a capability instead of a deployment-specific path.

Make protocols tell the truth at the boundary

A protocol response is a promise made to someone you will never talk to again. SMTP 250 does not mean "received bytes," it means "this is my problem now." An empty DNS answer means something entirely different from a name that does not exist, and resolvers

Monthly Update - June 2026 June's code.foss.global releases connected runtime reconciliation, HTTP/3 edge transport, stricter identity contracts, and repeatable native-binary delivery. Monthly Update, Engineering, Infrastructure

June turned the operating contracts introduced in May into active control loops. Cluster components began reporting live runtime state, control planes gained explicit reconciliation actions, route changes moved closer to event-driven updates, and several services added authenticated read-only MCP surfaces.

The May update focused on App Store contracts, gateway ownership, MFA, and release tooling. June connected those boundaries to the processes that perform updates, move workloads, inspect health, deliver mail, and expose operational state without handing out broad write access.

The version references below come from public code.foss.global tags and changelogs, public Gitea release records, and npm publication timestamps between June 1 and June 30, 2026. A public tag records released source, but it does not prove a production rollout. This update makes no deployment or adoption claims.

serve.zone: reconciliation becomes a live control loop

The largest June thread was the control path between Cloudly, Coreflow, Spark, CoreTraffic, and the workloads they manage.

Cloudly receives live runtime state. The public Cloudly changelog advanced from 6.4.4 to 8.22.0 during June. The 8.x line added runtime deployment snapshots, live node metrics, routed deployment details, interactive shells, log streaming, archived deployment records, service migration orchestration, live health views, and operator-triggered service update actions. The useful change is the data path: node-reported state can now drive a control-plane view and an explicit action instead of remaining a periodic status record.

Coreflow reacts to events. Coreflow 2.x introduced deployment snapshot reporting, workload placement controls, log and shell handlers, Corestore inventory access, current routing retrieval, and base-service reconciliation. The 2.15.0 event bus uses one filtered Docker event stream per node and fans container lifecycle events out to health and routing consumers. Periodic inventory and routing passes remain as safety nets, but they are no longer the only trigger.

Health and resource reporting move into the runtime. Coreflow 2.14 replaced per-container Docker health-check execution with an in-process prober and added live per-deployment resource usage. Follow-up releases made the prober event-driven and moved resource sampling away from repeated full container listings. Spark 1.8.0, published as a public Gitea release on June 18, added Cloudly-triggered managed-service updates and structured update results alongside runtime information in heartbeat payloads.

Update ownership becomes explicit. Cloudly 8.18 can request serve.zone service updates and display their status. Coreflow 2.16 handles base-service reconciliation requests and uses image-aware update checks. Spark skips its scheduled service-update path when it is running in the Coreflow node mode, leaving Cloudly to trigger the operation. That removes two actors independently deciding when the same managed service should change.

Ecosystem note. Cloudly is the cluster control plane, Coreflow manages workloads on cluster nodes, Spark owns the node-side service lifecycle, and CoreTraffic carries routed traffic. June's work made the handoff between those components observable and request-driven.

Corestore and Onebox consolidate the storage boundary

May added tenant-aware database and object-storage operations. June moved more of the hosted runtime behind a single storage service boundary.

Onebox 4.1.0 and 4.2.0 added SmartStorage-backed S3 provisioning and a migration path from the older MinIO platform service. The tagged 4.2.0 changelog marks that unification complete for the Onebox platform model. Onebox 5.0.0 then renamed its SmartProxy platform integration to CoreTraffic and added migration logic for persisted service records and settings. These are tagged source changes; the public record does not establish where either migration has been run.

Corestore 1.1.0 through 1.4.0 added archive manifests, object transfer endpoints, pruning with dry-run support, serialized archive operations, and host-path reporting for its Docker volume plugin. Cloudly 8.9 added Corestore inventory views, while the June backup line added node archive pruning and an external offload tier. Together, those contracts let a control plane inspect stored resources and move archive objects without reaching around Corestore's API.

The underlying npm packages also received narrow correctness work. @push.rocks/smartdb 2.11.0 bounded its in-memory oplog, checkpoints the write-ahead log during runtime, and serializes writes per collection namespace so concurrent unique-key writes cannot both pass the pre-check. Version 2.11.1 allows read-write tenants to perform collection-level DDL within their own database while keeping database-administration commands separate.

@push.rocks/smartstorage 6.5.6 made S3 client discovery compatible with scoped tenant credentials by allowing bucket listing while filtering the result to the credential's assigned bucket. The result is a tighter storage boundary: Corestore owns archive and volume operations, while SmartDB and SmartStorage enforce database and bucket scope below it.

Edge transport adds HTTP/3 WebSockets and DNS-over-TCP

June's edge work concentrated on protocol completeness and long-lived connection behavior.

@push.rocks/smartproxy moved from 27.12.3 to 27.17.5 on npm during the month. Version 27.17.0 added WebSocket over HTTP/3 using RFC 9220 Extended CONNECT on both frontend and backend paths. The follow-up releases added QUIC keep-alives, protected active H3 WebSocket streams from connection-pool age rotation, stabilized route cancellation during hot reload, and cleaned idle QUIC relay sessions on a timer.

The same release line changed certificate work from route-update side effects into bounded maintenance. Version 27.16.0 skips still-valid certificates during provisioning sweeps, coalesces concurrent sweeps, applies per-domain failure cooldowns, and runs periodic renewal checks. CoreTraffic 1.2.0 exposed HTTP/3 on service routes, and DcRouter consumed the SmartProxy 27.17 line in its public June releases.

RemoteIngress 4.25.0 added policy-controlled outbound TCP proxy sessions over QUIC. Earlier June releases fixed same-stream frame ordering and TCP half-close behavior, then switched the Rust build to static Linux binaries where its dependency set permits that.

DNS gained a missing transport path. @push.rocks/smartdns 7.11.0 added RFC 7766

@serve.zone/callrouter: HiFi Calling Engine for SIP, WebRTC, and social.io @serve.zone/callrouter puts high-fidelity Rust audio processing, hub-based call legs, and pluggable SIP/WebRTC workflows behind the calling layer social.io needs. Engineering, Infrastructure, serve.zone

@serve.zone/callrouter is the calling engine being built for serve.zone and social.io. It should be read less as a generic SIP router and more as the media/control boundary for calls that cross browsers, SIP trunks, LAN phones, voicemail, fax, and operator dashboards.

For social.io, the direction is explicit: @serve.zone/callrouter will solve calling by giving the product a Rust-backed media path and a TypeScript-owned operations layer. Browser WebRTC calls can live in the product surface, while trunk/device integration, call state, and media mixing stay in the service layer.

The project was already covered as part of the April 2026 code.foss.global update. The current 1.28.0 line makes the interesting part clearer: performance-sensitive media work is in Rust, call composition is hub-based, and the surrounding TypeScript service keeps the system configurable and operable.

Performance boundary: Rust owns the real-time path

The TypeScript side owns configuration, dashboard views, REST and WebSocket APIs, browser signaling, runtime status, and shutdown/reload orchestration. It does not parse raw SIP packets or process RTP audio.

The Rust proxy-engine owns SIP dialog handling, RTP I/O, WebRTC media sessions, codec boundaries, mixing, jitter handling, fax transport, and live call state. The two sides communicate through high-level commands and events over @push.rocks/smartrust, following the TypeScript/Rust split described in the foss.global bridge architecture note.

That matters for performance because the packet path does not depend on JavaScript timers, object churn, or application-level WebSocket handling once media is in the engine. No public benchmark numbers are documented, so the performance claim is architectural: real-time SIP/RTP/WebRTC work sits in the native process that owns the sockets and mixer.

The HiFi audio engine

The current media engine mixes calls on a 20 ms tick over a 48 kHz f32 internal bus. That is the right center of gravity for a service that has to bridge browser WebRTC and telephony codecs without treating every call as a lowest-common-denominator RTP relay.

Codec handling currently covers Opus, G.722, PCMU, and PCMA through codec-lib. The engine includes per-leg transcoding, resampling, adaptive jitter buffering, packet loss concealment, negotiated SDP payload handling, and denoising work from the recent Rust media updates.

HiFi here does not mean the public telephone network becomes lossless. It means @serve.zone/callrouter keeps an internal audio path that can normalize different codec, packet timing, and loss conditions before distributing mix-minus audio back to each participant.

Hub-based calls, not linear forwarding

@serve.zone/callrouter models a call as a hub with legs. Provider trunks, LAN SIP devices, browser WebRTC sessions, fax paths, recorders, TTS prompts, and tool legs can all be represented as participants in the same call structure.

Call hub
  provider leg: SIP/RTP trunk
  device leg: LAN SIP phone
  browser leg: WebRTC
  recorder/TTS/tool legs: call features
  fax leg: T.38/UDPTL-related paths

The mixer runs mix-minus output per leg, so each participant receives the call audio without its own contribution fed back into the stream. This is the difference between a router that forwards one SIP leg to another and a calling engine that can attach, remove, record, prompt, bridge, or extend legs around a single call state.

The REST surface reflects that model. Existing endpoints can originate calls, hang up calls, add registered device legs, add external dial-out legs, remove legs, start outbound fax jobs, list fax state, and manage voicemail messages. POST /api/transfer is present but still returns 501 not yet implemented, so transfer is not a finished workflow yet.

Pluggability around the call lifecycle

The useful spelling in prose is pluggability, and in @serve.zone/callrouter it is architectural rather than a public plugin marketplace. The service is built so call capabilities attach through typed commands, events, routes, and legs instead of being hardwired as one SIP-to-SIP path.

Browser clients plug in through WebRTC signaling on the dashboard WebSocket.
SIP providers plug in through provider registration, outbound proxy settings, digest auth, and route rules.
LAN phones plug in as registered SIP devices with explicit target matching.
Voicemail plugs in through voiceboxes, WAV storage, heard-state APIs, and call recording flows.
Fax plugs in through fax boxes, job tracking, inbox metadata, TIFF downloads, and T.38/UDPTL-related media paths.
Operations plug in through GET /api/status, WS /ws, dashboard views, and config reload paths.

That gives social.io a practical route to calling: browser-first calls can use the product UI, while @serve.zone/callrouter supplies the service-owned call engine underneath. If a call needs to leave the browser world, the same hub can bridge toward SIP trunks or devices instead of handing control to a separate PBX.

Ecosystem note. serve.zone services usually put operational control in TypeScript and move packet or media handling into Rust where latency, memory control, and protocol correctness matter. @serve.zone/callrouter applies that pattern to telephony.

The result is a focused calling layer: a high-fidelity Rust media engine, a hub-based leg model, and TypeScript-owned operations. That is why @serve.zone/callrouter is the right place to solve calling for social.io.

Monthly Update - May 2026 May's code.foss.global work tied App Store manifests, gateway ownership, MFA/passkeys, and release tooling into a clearer operations layer for hosted services. Monthly Update, Engineering, Infrastructure

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-

Monthly Update - April 2026 April's code.foss.global work made dcrouter, callrouter, idp.global, modelgrid, storage, and UI components more operable through persisted state and admin workflows. Monthly Update, Engineering, Infrastructure

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.

Monthly Update - March 2026 March moved the Rust-hybrid stack into shipping infrastructure: dcrouter, smartproxy, objectstorage, registry, smartstorage, smartvpn, remoteingress, and onebox. Monthly Update, Engineering, Infrastructure

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