Roadmap

Edit this page

This is what Loomscope intends to build, in the order it intends to build it, and — just as importantly — what it has decided not to build.

Dates are deliberately absent. Loomscope is maintained by one person; sequence is a commitment, timing is not.

Current release: 0.1.0. Usable, covered by CI, not yet stable.


How to read this

Each item carries a state:

StateMeaning
ShippedIn main and covered by CI.
NextCommitted to, and the next thing to be worked on.
PlannedAgreed in principle, with an ADR where the design is non-obvious.
ConsideringUnder analysis. May be declined.
DeclinedDecided against. The reasoning is recorded so it is not relitigated.

0.2 — Close the credibility gaps

The theme is removing the distance between what Loomscope claims and what it does. Nothing here is a new capability; all of it is making the existing surface trustworthy.

ItemStateNotes
Restore a working linterShippedA root flat config now runs in CI. See ADR-0008.
Test coverage on the HTTP APINextTwo of nineteen route handlers are covered — daemon/observations and daemon/credentials. The other seventeen are not, including every /api/v1/admin/* route and the topology share links.
Test tenant isolation directlyShippedIt did not hold. The application connected as a superuser, which PostgreSQL exempts from row-level security entirely. Scoped transactions now drop to an unprivileged role, and eight tests assert the boundary against a real database.
Lazy configuration loadingShippednext build and every pure-logic test now run with no environment at all.
Replace the magic-link stubShippedIt no longer prints a single-use credential to stdout; it refuses instead, until a mail transport exists.
Design token passShippedEvery colour literal is gone; one token set drives both themes. See ADR-0007.
Browser tests on the critical pathsPlannedSign-in, discovery, topology render, vulnerability list. No browser test framework is installed; the UI has only ever been checked by hand.
Realtime stream trusted a client-supplied org idShipped/api/sse read the tenant from a query parameter and middleware exempts the route from its cookie check, so nothing verified membership. It resolves the org from the session now.
Server-side sort, filter and pagination on every listShippedEvery list page ended in a hardcoded LIMIT with no way past it. Keyset cursors throughout, verified against real row counts for duplicates and gaps.
WCAG 2.1 AA on both themesShippedTwo pairings failed. A test over the token file keeps them passing.
Documentation siteShippedloomscope.dev — the Markdown in docs/ rendered on the product's own tokens. It had not built at all for weeks; CI builds it now.
Decide the fate of eBPFPlannedThe collector attaches no probes. Implement it or remove it from the feature matrix; shipping a scaffold under a feature name is the worst of the three options.

0.3 — Integrations and alerting

Loomscope currently tells you things only if you go and look. This is the release where it can tell you without being asked.

ItemStateNotes
Outbound webhooks with HMAC signaturesPlannedThe generic case, and the one that unblocks everything else via n8n or Zapier.
Slack and Microsoft Teams deliveryPlannedSeverity-coloured cards.
Jira and Linear issue creationPlannedSeverity maps to priority.
PagerDuty eventsPlannedFor daemon.offline and critical CVEs.
Alert rule builderPlannedEvent type plus condition, with a dry-run that shows what would have fired over the last 30 days.
Delivery pipelinePlannedExponential backoff, five attempts, per-event-key deduplication so a flapping daemon cannot spam a channel.

Event types: host.added, host.removed, service.changed, tls.expiring, vuln.critical, vuln.high, snapshot.diff_significant, daemon.offline.

0.4 — Programmable Loomscope

Three interfaces onto the same inventory, for three different consumers. Each has its own ADR because each could reasonably have been declined.

ItemStateADR
Stable public REST API with versioning and API keysPlannedADR-0003
loomscope command-line clientPlannedADR-0004
MCP server exposing the inventory to AI agentsPlannedADR-0005

The ordering is deliberate. The REST API comes first because the CLI and the MCP server are both clients of it — building either one first would bake in an unstable contract.

0.5 — Operable at scale

ItemStateNotes
Backup and restore CLIPlannedA single archive containing the database dump and the credential-key fingerprint, plus the reverse. Currently there is no supported backup path at all.
Helm chartPlannedFor clusters. Same image semver as Compose, external PostgreSQL supported.
Prometheus /metricsPlannedOn both the control plane and the daemon.
Performance pass at 100k hostsPlannedEXPLAIN ANALYZE on every list query, enforced server-side pagination, React Flow virtualisation beyond 2k nodes.
Documented upgrade pathPlannedIncluding how migrations behave across a version jump.

1.0 — Enterprise readiness

ItemStateNotes
SSO — OIDC and SAMLPlannedBetter-Auth supports both; the work is per-organisation configuration and testing against a real identity provider.
SCIM 2.0 provisioningPlannedThe endpoint currently returns 501.
Audit log surfacePartly shippedReadable, filterable by subsystem and paginated under Settings. Search, CSV export and configurable retention are not built.
Verified air-gap bundlePlannedA single offline archive — images, CVE feeds, signatures, documentation — proven on an isolated machine rather than assumed to work.

1.0 means the interfaces are stable and upgrades are supported, not that the feature list is finished.


Considering

Ideas under analysis. Each will get an ADR before any code is written.

IdeaWhy it is interestingWhy it might be declined
Agentless Windows inventory over WinRMCloses a real gap for mixed estatesCredential handling on Windows is a large surface, and SNMP plus port fingerprinting already identify most Windows hosts
Passive discovery via SPAN/mirror portsFinds hosts that never answer a probeRequires switch configuration most users cannot change, and overlaps with the NetFlow path
Config-drift detection on network devicesNatural extension of snapshotsTurns Loomscope into a configuration manager, which is a different product
Multi-instance federationSome estates genuinely cannot route to one control planeDoubles the security model. Explicitly out of scope for multi-site, which solves the common case

Declined

Recorded so the reasoning survives.

ProposalDecision
gRPC between daemon and control planeDeclined. REST and SSE meet the need, and gRPC would add a second transport, a second schema toolchain and proxy complications for no user-visible gain. ADR-0001
A message broker for job distributionDeclined. PostgreSQL with LISTEN/NOTIFY and job rows covers the volume Loomscope targets. A broker is one more component every operator has to run, back up and upgrade. ADR-0002
Redis for caching or pub/subDeclined. Same reasoning. PostgreSQL is already required; Redis would be a second stateful dependency. ADR-0002
A privileged daemon containerDeclined. Capabilities only, always. The security review is a feature.
Telemetry or phone-home, even anonymousDeclined. Loomscope is deployed by people who chose self-hosting specifically to avoid it.
Cloud API calls from the daemonDeclined. Cloud discovery runs in the control plane so daemon hosts never hold cloud credentials.
A hosted SaaS editionDeclined for the foreseeable future. It would change what the project optimises for.

Known gaps

Carried from the changelog so this document is honest on its own:

  • The eBPF collector attaches no probes.
  • Alerting integrations, SSO, SCIM, the Helm chart and the backup CLI do not exist.
  • Automated tests reach two of nineteen HTTP routes, and no browser test framework is installed, so the UI is verified only by hand.
  • The published OpenAPI specification can drift from the Zod contracts if the pre-commit hook is bypassed.

Influencing this roadmap

Open an issue describing the problem you have, not the feature you want. The most useful contributions to this document have been descriptions of an environment Loomscope handled badly.