Capabilities

A capability is a composable slice of the NetScript framework — a single, self-contained concern (defining a service, running background jobs, ingesting a webhook, authenticating a user, persisting state) that you add to a workspace without rewiring the host. Each capability owns one mental model, one headline authoring API, and — where it runs — one HTTP surface on a known port. You compose them the way you compose small building blocks: add what the system needs, leave out what it doesn't, and the contracts keep the seams type-safe.

This zone is the hub of hubs. Every page below is a capability hub built on the same shape — a one-screen concept, the headline API lifted verbatim from a scaffolded project, the real endpoints and ports, and a Learn / Do / Reference triplet that points you at the tutorial that teaches it, the how-to that ships it, and the generated API reference for the full surface. The hubs stay deliberately thin so they orient rather than duplicate the reference.

The five composable plugins

These are the slices you bolt on with netscript plugin add. Each is an isolated background processor or service that exposes its own HTTP API on a dedicated port, wired into Aspire automatically. Bring Aspire up first — cd aspire && aspire start provisions Postgres and a shared cache — redis by default, or garnet / deno-kv via --cache-backend — and starts the dashboard at http://localhost:18888 — before any netscript db command or plugin call, so the plugin services and their dependencies exist when you reach for them.

The platform capabilities

These ship with the scaffold — no plugin add required. Services and contracts are the backbone the five plugins lean on; the rest are the persistence, primitives, observability, and UI the whole workspace shares.

The capability matrix

At a glance: what each capability is for, how it runs, and where to read the full generated API. Ports apply only to capabilities that expose an HTTP surface; the primitive and UI capabilities run inside the workspace rather than on their own port. Always read the generated API reference for the exhaustive surface — these hubs orient, the reference enumerates.

How the seams fit together

The plugins are not islands — they compose through the same contracts and durable substrate. A service defines an oRPC contract and serves it at /api/rpc/*. A trigger turns an inbound webhook into a queued job via enqueueJob. A worker picks that job off the queue and runs it thread-isolated, emitting real OTel spans as it goes. A saga drives a message-correlated state machine, persisting its durable state to kv or prisma. A stream producer mirrors execution state out of workers, auth, and sagas over the durable-streams service on :4437. And authentication sits in front as a pure-backend seam: the core defines AuthBackendPort, the three backends are pure adapters, and the plugin composes exactly one active backend at a time. Underneath them all, the platform capabilities — services, database, KV/queues/cron, telemetry, and the Fresh UI — supply the contracts, persistence, primitives, and observability the whole workspace shares.

Where to go next

The hubs are concept-first; the rest of the site does the teaching and the shipping. If you learn best by building, walk the tutorials ladder — it builds one continuous app where a service publishes a saga message, a saga consumes it, and a webhook enqueues a job, exercising several of these capabilities in sequence. If you have a task in hand, the how-to recipes ship each capability directly — including adding authentication. For the why behind the design, the core concepts zone explains the contract type flow, the plugin system, the durability model, the auth model, and the Aspire orchestration that ties it together.