UnCorded SDK

Appearance

UnCorded Plugin SDKBuild features that feel native.

Production guidance for secure, host-independent plugins—from manifest to realtime UI.

Build your first plugin
Read the platform model
Load for an AI session

Enforced contracts

Manifest fields, capabilities, and SDK calls are tied back to the validators and runtime gates that enforce them.

Native-hosting aware

Build once for native WSL hosting and Docker fallback, with explicit guidance for local-only and Transport servers.

Production patterns

Authorization, readiness, data ownership, realtime fan-out, theming, packaging, and failure recovery are first-class.

What UnCorded is ​

UnCorded is a self-hosted collaboration platform where every feature is a plugin—chat, voice, dashboards, game integrations, and embedded applications. Central provides identity, discovery, entitlements, and marketplace metadata; each server runtime owns its content and executes its plugins.

A packaged Windows server normally runs through native hosting in an app-owned WSL2 distro. Docker remains a supported fallback and migration path. The plugin contract is identical on both hosts, so production plugins must not depend on container paths, Docker DNS aliases, or a particular process manager.

The three-part plugin ​

  1. Manifest (manifest.json) — declares identity, entry points, UI contributions, and the exact capabilities the runtime may grant. Undeclared capability means a typed, fail-closed rejection.
  2. Backend — an optional sandboxed Bun subprocess using createPlugin() over stdio JSON IPC. It owns private SQLite/KV/files, request handlers, events, schedules, notifications, and host-brokered integrations.
  3. Frontend — an optional HTML bundle rendered in a sandboxed iframe using createPluginFrontend(). It calls handlers, receives realtime updates, uploads files, follows the active theme, and asks the shell to render native surfaces.
text
manifest.json ── declares ──▶ runtime-enforced capabilities
      │
      ├── backend/  ── createPlugin() ──▶ sandboxed process ⇄ runtime (stdio IPC)
      │                                     SQLite · events · broadcast · net
      │
      └── frontend/ ── createPluginFrontend() ──▶ sandboxed iframe ⇄ shell
                                                    request · files · surfaces

Hosting, reach, and visibility are different ​

AxisChoicesWhat it changes for a plugin
Runtime hostNative WSL2 (default) or Docker fallbackNothing in the SDK contract. Avoid host-specific paths and DNS assumptions.
ReachabilityLocal-only, UnCorded Transport, or owner tunnelPublic hostnames, raw public ports, and off-device access may or may not exist.
VisibilityPrivate or publicDirectory and membership policy; it does not create a network path.

Read Platform & hosting model before building a proxy, network, companion, or homelab integration.

Where to start ​

You want to…Read
Build a complete pluginGetting started
Understand hosting and TransportPlatform & hosting model
Ship something maintainableProduction plugin checklist
Look up a manifest field or capabilityManifest · Permissions
Look up an SDK methodBackend SDK · Frontend SDK
Proxy a self-hosted appReverse-proxy plugins
Copy a small, complete implementationNoteboard golden example
Study a shipped data-owning plugintext-channels walkthrough
Prime an AI coding sessionAgent guide & source map

For AI coding sessions ​

This site publishes the llms.txt convention:

Inside the monorepo, start with root AGENTS.md, then docs/site/ai/agent-guide.md. Those files point to the validator, public type exports, runtime capability gates, hosting implementation, and production examples. Historical plans are context, not current behavior.

Documentation is part of the SDK contract. CI checks generated manifest content, public SDK coverage, capability coverage, plugin manifests, stale host-specific guidance, and the VitePress build.