Features

What GridWeave does today, area by area, and how far each part has been proven. GridWeave is under construction and not released, so every feature carries a status.

Read this first

How to read the status

“Built” means the code is merged and an automated test or a recorded run exercises it. It does not mean released or ready for production.

Under construction, not released.

Nothing is code-signed. Continuous integration is switched off, so a set of local checks is the gate. The newest Windows parts have never been run. Intel AMT was tested only against a simulator. Remote desktop and notification delivery do not exist. The product has run on one macOS machine and one Ubuntu virtual machine. The roadmap lists the milestones and the known gaps.

  • BuiltMerged, and tested or run as described on the card.
  • Partly builtSome of it works. The card says what is missing.
  • UnverifiedWritten, but not run on the system named in the badge (Windows, macOS, real hardware, Active Directory).
  • Simulator onlyTested against a simulator written by the authors, not the real thing.
  • Not built yetDoes not exist. It may be planned.

Manage devices

Enrol machines, keep them connected, see them and act on them.

Status of this area: The agent plane is built and merged, but its exit criteria are not met: some agent behaviour has run on one macOS machine and one Ubuntu virtual machine only.

  • Enrol and connect agents

    Built

    A device enrols with a token and gets its own certificate. It connects over mutual TLS, renews its certificate over the control connection, and a revoked device is disconnected at once. Presence is tracked.

    Limits and gaps: a WebSocket fallback and proxy support. The agent keeps its key in a protected file, not in the TPM or Keychain.

  • Presence

    Built

    A device is online while its presence lease lives. Any frame the gateway accepts from the agent renews the lease, not only the heartbeat, and the lease follows the heartbeat the server announces: three intervals, at least 45 seconds. The server refuses to start with a lease shorter than twice the heartbeat. This fixed devices flapping between online and offline at a 60 second heartbeat (feature 042; in one 150-second run with 200 simulated agents the disconnect events fell from 407 to 0).

    Limits and gaps: offline detection can take longer than 45 seconds when the heartbeat is lengthened, up to 180 seconds at 60. The default 15 second heartbeat keeps 45 seconds. Not re-measured at 10,000 agents, on Linux or with several gateways.

  • Address lists and abuse detection

    Built

    Allow and deny lists for agent addresses, plus detection of floods, flapping connections and cloned devices.

  • Device list and inventory

    Partly built

    Agents report state, network and inventory (sent only when changed). The web application lists devices with filters and lets you edit, add notes, move and delete them.

    Limits and gaps: card, thumbnail and map views, sorting, a column chooser and export.

  • Signed commands

    Built Unverified on Windows

    Run a script on up to 500 devices as one job, or send power, notify, wake, processes, services, clipboard and open-URL commands. The server signs each command and the agent checks it itself before acting. Executors exist for Linux and macOS and, written against a Windows 11 ARM64 virtual machine, for Windows.

    Limits and gaps: stored scripts, an agent console, chat and wallpaper. Wake works only through a connected agent of the same group. Opening a URL and display control on Windows were never completed.

  • The agent as a service

    Partly built Unverified on Windows Unverified on macOS

    gridweave-agent install enrols the machine and installs the agent as a systemd unit, a macOS LaunchDaemon or a Windows service that restarts it. State is root-only, and a local socket serves helper applications with peer-credential checks.

    Limits and gaps: Proven on Ubuntu 24.04 ARM64 under systemd, including install, run and uninstall again after the binaries were renamed. The macOS LaunchDaemon was only a dry run, and the Windows service was proven in a virtual machine that has since become unreachable; their renamed service names were checked, not run.

  • Remote desktop

    Not built yet

    Viewing and controlling a device screen.

    Limits and gaps: all of it. No desktop session, desktop recording or peer-to-peer upgrade exists.

Access control and tenancy

Who can see and do what, and how tenants are kept apart.

Status of this area: Tenancy and access control are part of the control plane (milestone 1), which is done except for the gaps the product lists.

  • Tenant isolation

    Built

    A multi-tenant data model with PostgreSQL row-level security on every tenant table (22 migrations). Tests show that a cross-tenant read returns nothing.

    Limits and gaps: cross-tenant actions beyond creating, renaming and suspending a tenant.

  • Roles and bindings

    Built

    Roles bound to users with allow and deny rules, at four scopes: platform, tenant, device group and device.

  • Delegation rules

    Built

    Rules that stop anyone from granting more than they hold themselves.

  • User groups and device groups

    Built

    Group users and devices, and bind roles to groups.

  • Per-tenant settings

    Built

    Limits, session policy, address lists, maintenance mode, and the sender address and templates for e-mail.

    Limits and gaps: a few values, such as the login-transaction lifetime, are still constants and not settings.

Remote sessions

Open a terminal or a file transfer on a device through the relay, record it and share it.

Status of this area: Terminal and files are built end to end, but the real agent served them together with the server on macOS only. The web tabs and gridweave ran against fake agent connections and by hand in headless Chrome.

  • Terminal and files

    Partly built Unverified on Windows

    A relay joins the client and the agent with signed single-use grants, slows a fast writer, and closes a session within two seconds of a revoked permission. The real agent serves terminal (PTY) and file sessions. Clients are the web Terminal and Files tabs, gridweave shell and gridweave cp.

    Limits and gaps: folder browsing, rename and delete in the web Files tab, and file audit events. The Windows terminal and consent prompt were never compiled or run.

  • Consent on the device

    Partly built

    A session needs consent on the device, merged from server policy and enforced by the agent. When nobody can be asked, the default is to refuse.

    Limits and gaps: a helper application to show the consent prompt on Linux and macOS desktops.

  • Session recording

    Partly built

    Terminal sessions are recorded into the tenant’s object store when policy or the operator asks. Each recording is integrity-checked, kept to a retention period, and played back in the web application.

    Limits and gaps: terminal sessions only: no desktop recordings. No signed URLs, no object lock, and the agent shows no notice on the device yet. Proven with fake agent connections, the real relay and a real S3 service, not with a real agent or browser.

  • Guest sharing

    Partly built

    A person without an account can join one terminal session through a link. The token is 256 random bits and only its hash is stored. The link is limited in use and time, can be revoked (both ends close within milliseconds), is audited, and never gives the guest more than its creator holds.

    Limits and gaps: terminal sessions only; recurring and HTTP shares are not built. The agent shows no guest notice and does not yet enforce view-only itself (the relay does). The link is shown once. Tried with fake agent connections and the real relay, not with a real agent or browser.

  • Other session protocols

    Not built yet

    The relay defines nine more session protocols and refuses them. Peer-to-peer and multi-viewer sessions are not built either.

    Limits and gaps: all of these.

Identity and sign-in

How people prove who they are, and how accounts are created and recovered.

Status of this area: Everything here is on main. The Active Directory, mail-relay and browser gaps are named on each card.

  • Local accounts and sessions

    Partly built

    Password rules, forced and expired password change, a TOTP second factor, and sessions you can list and revoke.

    Limits and gaps: a longer common-password list. The server now asks for the current password (and a current code if a factor exists) when a TOTP factor is added, but in the current web source the enrolment dialog sends neither, so enrolling from the screen is refused until it is updated (a known open follow-up, read from the source and not run).

  • OpenID Connect

    Built

    Sign in through an OpenID Connect provider, with group mapping.

    Limits and gaps: claim mapping beyond groups.

  • LDAP and SAML 2.0

    Partly built Unverified on Active Directory

    Directory bind and SAML 2.0 providers, with group mapping.

    Limits and gaps: SAML single logout, IdP-initiated sign-in (refused on purpose), nested LDAP groups. Proved only against OpenLDAP and Keycloak in containers.

  • Account invitations

    Built

    Invite a person by e-mail to create an account.

    Limits and gaps: invitation through an identity provider.

  • Password reset and e-mail verification

    Built

    Reset and verification links sent by e-mail from a durable queue, plus security notices.

    Limits and gaps: Proven against an in-process SMTP server and Mailpit only, not a real mail relay.

  • Personal access tokens and gridweave

    Partly built

    A token acts as a bearer credential. gridweave uses it to sign in, run whoami, list devices, run a script, open a shell and copy files.

    Limits and gaps: login by device code or password, events watch and port-forward. gridweave shell and cp were proved only against fake agent connections.

  • Passkeys and self-registration

    Not built yet

    Sign-in with passkeys, and people creating their own accounts.

    Limits and gaps: both.

Web application, command line and API

The ways people and programs use GridWeave.

  • Web application

    Partly built

    React and TypeScript in English and German, accessibility-scanned in its tests. It was redesigned with Tailwind CSS and shadcn/ui, and an optional layout check opens every screen at three widths in both themes. Screens cover account, tokens, tenant and platform settings, users, invitations, groups, devices (with Terminal, Files and Sharing tabs), recordings and their player, agent releases and rollouts, events, identity providers and audit.

    Limits and gaps: the other languages of the 24 planned (only English and German exist), folder browsing in Files, and a check in a real browser against the real server and agent. The tests ran against stubbed answers.

  • HTTP API and event stream

    Built

    An OpenAPI 3.1 contract with 150 operations, an AsyncAPI event stream and Protobuf agent and relay protocols. A contract check forbids breaking API changes.

    Limits and gaps: a resumable event stream.

  • Reports

    Not built yet

    Fleet reports.

    Limits and gaps: all of it.

Deployment and operations

Run GridWeave, keep its keys and files, and ship agent updates.

Status of this area: Nothing here is production ready. The product says its default key store is for development and that its Helm chart is for evaluation.

  • One Linux host

    Partly built

    The server installs on one host with PostgreSQL, TLS and systemd from reference files. It was installed by following the guide on Ubuntu 24.04 ARM64.

    Limits and gaps: packaging, high availability and automated backups. The key store is the development default.

  • Containers and Compose

    Built

    A server image (the role is an argument), a Linux agent image, a split-role Compose stack, and a development environment and builds that run entirely in Docker.

    Limits and gaps: Run on one Docker host. Nothing is signed or published.

  • Helm chart

    Partly built

    A chart for Kubernetes. It was installed on one single-node k3s cluster.

    Limits and gaps: production use. Setting the OpenBao key store was rendered by the chart but never run on a cluster.

  • Object storage

    Partly built

    A tenant-scoped store with a local-disk driver and an S3 driver, tested against SeaweedFS. The agent release store and terminal recordings use it.

    Limits and gaps: presigned URLs, object lock, per-tenant credentials, and a trial against AWS S3, Ceph or MinIO.

  • Key stores

    Partly built

    The default driver keeps keys in plain files, and the server warns about it. An encrypted-file driver and an OpenBao Transit driver with per-role policies exist, managed with gridweave-admin kms. The OpenBao driver was tested against a real OpenBao.

    Limits and gaps: key recovery with dual control, PKCS#11 and cloud key drivers. The file drivers cannot enforce a per-role key boundary.

  • Agent distribution and signed updates

    Partly built Unverified on Windows

    Reproducible release builds, an Ed25519-signed manifest with an offline key and two pinned public keys, releases imported with gridweave-admin releases import and served per tenant policy, and a verified staged update on the agent, by hand with gridweave-agent update or by the agent itself (next card).

    Limits and gaps: Nothing is code-signed and the keys in the repository are development keys; the offline key ceremony has not been done. There is no install page and no enrolment link. The macOS package was built and inspected, never installed, and the Windows package was never run.

  • Staged rollouts and agent self-update

    Partly built Unverified on Windows Unverified on macOS

    An administrator rolls a release out in rings (a stable hash of the device id decides each device’s ring), inside an optional weekly window, with a concurrency limit, a minimum version and per-group or per-device policies, including pins and canary groups. The installed agent downloads the update itself, verifies the signed manifest and the artifact, and swaps its binary. If the new build does not stay connected, the previous build is restored automatically, by the new build or by a watchdog the old binary armed. A health gate halts the rollout when too many devices fail or roll back. The web application has an Updates area.

    Limits and gaps: proven on Linux under systemd (Ubuntu 24.04 ARM64) and on macOS only through a staged install root. The launchd restart and watchdog, Windows (nothing swaps a binary there) and x86-64 are unverified, as are rollouts to more than a handful of devices. No “update now”: nothing is pushed.

  • Load and conformance tools

    Partly built

    gridweave-load simulates a fleet and gridweave-conform runs 33 gateway conformance cases against a real server.

    Limits and gaps: a run on a reference Linux host. 10,000 simulated agents were held once on a shared Mac. The 50,000-agent target was not run.

Observability and audit

What happened, who did it, and whether the record can be trusted.

  • Audit log

    Built

    A transactional outbox feeds a hash-chained audit log per tenant and one for the installation, with retention. gridweave-admin audit verify checks the chain. Every command is recorded before it is sent, scripts included.

    Limits and gaps: audit entries for sessions and files on the agent side, and the daily external anchor of the chain.

  • Events

    Built

    Stored events with visibility rules, and an event stream.

  • Health and metrics

    Built

    Health and readiness endpoints, Prometheus metrics, system warnings, certificate reload for the HTTP listener, and scheduled jobs that run once across workers.

    Limits and gaps: ACME certificates, and a warning for failed backups.

  • Notification delivery

    Not built yet

    Delivering notifications to people. Subscriptions are stored in the web application and nothing sends them.

    Limits and gaps: all delivery. Only e-mail exists as a channel at all.

Optional modules

Parts that run only when you switch them on.

  • Intel AMT

    Partly built Simulator only Unverified on hardware

    An optional amt role. It accepts CIRA connections, speaks WS-Management, and reads inventory, power state and feature state. It also sets power, feature and group policy and handles certificates. It is built and tested against a simulator that the authors wrote.

    Limits and gaps: remote desktop and serial-over-LAN through the relay, activation, Wi-Fi and 802.1x, and the AMT web screens. Every behaviour that depends on firmware is unvalidated on real vPro hardware.

  • The bridge role

    Not built yet

    A role reserved in the server. It answers “not implemented”.

    Limits and gaps: all of it. The adapter and importer for the earlier product are not built either.

Where it has run, and where to go next

Everything ran on one macOS machine. The agent service, the single-host deployment and the agent tests also ran on one Ubuntu 24.04 ARM64 virtual machine. The Windows 11 virtual machine has been unreachable since the Windows parts were last changed, so those parts are unverified. No run has used Active Directory, a real mail relay, real Intel AMT hardware or a reference Linux host at scale.

The binaries are gridweaved, gridweave, gridweave-admin and gridweave-agent. They were renamed from nsd, nsctl, nsadmin and nsagent in feature 043; the NS_* configuration variables, the ns.* protocol packages and the ns_ database roles kept their names.