feat(custom-widgets): add extensible widget platform
This commit is contained in:
ajnart committed
1 parent
6cca757493
commit
8f152f1929
317 files changed
+32326
-1788
No files matched your search
@@ -3,7 +3,8 @@
|
||||
The Homarr image includes a recovery CLI for operations that cannot be completed in the web interface. It is not an
|
||||
application API; use the [API](/docs/management/api) or [MCP endpoint](/docs/management/mcp) for automation.
|
||||
|
||||
Back up the database and stop Homarr before running a command that changes data.
|
||||
Back up the database and stop Homarr before running a recovery command that changes database records directly.
|
||||
Widget project commands and authenticated preview requests can run while Homarr is online.
|
||||
Failed commands print an error and return a non-zero exit code, so shell scripts can stop safely.
|
||||
|
||||
## Run the recovery CLI
|
||||
@@ -43,6 +44,146 @@ homarr <command>
|
||||
|
||||
See the pages in this section for available commands.
|
||||
|
||||
## Build and share custom widget packages
|
||||
|
||||
The `widgets` commands accept a project directory, a v3 package JSON file, or an offline archive. Scaffolding,
|
||||
validation, compilation and packing do not need a running Homarr database.
|
||||
|
||||
Create a project to edit in your own IDE:
|
||||
|
||||
```sh
|
||||
homarr widgets init my-clock --example clock --id example.my-clock --name "My clock"
|
||||
homarr widgets validate my-clock
|
||||
homarr widgets pack my-clock
|
||||
```
|
||||
|
||||
`init` (also `scaffold`) creates a new directory with `homarr-widget.json` and normal TSX, TypeScript, CSS and asset
|
||||
files. It refuses to overwrite an existing directory. Choose `clock`, `timer`, `beszel`, `checklist`, `downloads`,
|
||||
`sonarr`, `rack`, `backup`, `household`, `overview`, `media`, `sqlite` or `mqtt` with `--example`; leaving out `--id` generates a unique
|
||||
local package identity. Edit the manifest and files, then repeat validation and packing. The manifest carries entrypoints,
|
||||
handlers, connection requirements, options and exact dependency versions; it does not embed the files map in this layout.
|
||||
|
||||
Directory loading skips hidden files, symlinks, `node_modules`, `dist`, `coverage`, generated archives and root-level
|
||||
`package.json`, `package-lock.json` and `tsconfig.json`. Keep all widget source under supported TS/JS, JSON, CSS, SVG,
|
||||
text, Markdown, image or font files. Build output defaults to `dist/widget.artifact.json`; packing defaults to
|
||||
`dist/widget.homarr-widget.json`. Remove or rename an existing output before rebuilding, or pass a new `--output`.
|
||||
|
||||
The same commands also accept the single-file format:
|
||||
|
||||
```sh
|
||||
homarr widgets validate widget.json
|
||||
homarr widgets build widget.json --output widget.artifact.json
|
||||
homarr widgets pack widget.json --output widget.homarr-widget.json
|
||||
homarr widgets validate widget.homarr-widget.json
|
||||
```
|
||||
|
||||
`validate` checks the package structure or an archive's source and artifact checksums. It does not execute widget code.
|
||||
`build` compiles JSX/TSX, local modules, CSS and assets into browser and optional server output. `pack` includes the
|
||||
source, compiled output and dependency lock in one JSON archive for offline installation. Output files must not already exist.
|
||||
|
||||
Packages with third-party dependencies need `--trust` to install their exact declared versions:
|
||||
|
||||
```sh
|
||||
homarr widgets pack widget.json --trust
|
||||
```
|
||||
|
||||
Dependency installations are cached in `.homarr-widgets` beside the input file. Installation scripts are disabled;
|
||||
packages requiring native build steps are not supported by these commands. Compilation does not start the widget's
|
||||
server handlers. Installed trusted widgets execute with Homarr's privileges; source and artifact checksums establish
|
||||
integrity, not publisher authenticity. Local connection bindings, credentials and widget state are separate from the archive.
|
||||
|
||||
### Preview a local project in Homarr
|
||||
|
||||
Set `HOMARR_API_KEY` to an admin API key from your own Homarr instance, then run:
|
||||
|
||||
```sh
|
||||
homarr widgets preview my-clock --url http://homarr.local:7575 --trust
|
||||
```
|
||||
|
||||
The command creates a disabled installation on first use, compiles the current local source on that Homarr instance,
|
||||
and prints a link to its exact preview session. Open the link while signed in as the API key owner. Repeating the command
|
||||
replaces the previous preview; it does not activate or overwrite the installation's saved draft. Use `--save-draft` to
|
||||
also save your local source. Use `--installation-id ID` to target an existing installation. The local
|
||||
`.homarr-widget.local.json` file remembers installation and preview IDs and is excluded from scaffolded Git projects.
|
||||
|
||||
Pass `--bindings bindings.json` for a JSON object mapping declared connection names to existing Homarr connection IDs,
|
||||
and `--options options.json` for preview option values. Credentials remain in Homarr. `--live-actions` explicitly allows
|
||||
real mutations during this preview; queries and subscriptions can already execute trusted server code. `--trust` is
|
||||
required on every invocation. Set `HOMARR_URL` instead of `--url`, or select a different secret variable with
|
||||
`--api-key-env VARIABLE_NAME`. Preview compilation may install declared dependencies after this explicit trust choice.
|
||||
|
||||
Use `--scenario NAME` to select synthetic query data declared in the package's `previewScenarios`. This skips server
|
||||
startup and configured service requests; unprovided query fixtures fail explicitly and subscriptions are unavailable.
|
||||
SDK actions stay simulated, so `--scenario` cannot be combined with `--live-actions`. Trusted browser code and dependency
|
||||
compilation keep their normal privileges. See [synthetic preview scenarios](../../management/custom-widgets/trusted-packages.mdx#synthetic-preview-scenarios).
|
||||
|
||||
### Publish the exact offline archive
|
||||
|
||||
Set `HOMARR_WORKSHOP_TOKEN` to an authenticated Workshop token, then publish the archive you reviewed:
|
||||
|
||||
```sh
|
||||
homarr widgets publish my-clock/dist/widget.homarr-widget.json
|
||||
homarr widgets publish next-release.homarr-widget.json --submission-id LISTING_ID --expected-revision 1
|
||||
```
|
||||
|
||||
Use `--url` (or `WORKSHOP_API_URL`) for your own Workshop service, `--token-env` for another token variable,
|
||||
`--changelog` for release notes, and `--forked-from RELEASE_ID` to attribute a new fork. Existing listings require their
|
||||
current revision and a new package version. Forks need their own package identity. Published releases are immutable;
|
||||
publication sends the archive without rebuilding it. You can also import the archive into Homarr and publish through
|
||||
the package workspace.
|
||||
|
||||
### Run a package on another machine
|
||||
|
||||
Run an already packed archive on another machine with the optional widget runner:
|
||||
|
||||
```sh
|
||||
export HOMARR_WIDGET_RUNNER_TOKEN="$(openssl rand -hex 32)"
|
||||
homarr widgets serve widget.homarr-widget.json --trust --host 127.0.0.1 --port 8787
|
||||
```
|
||||
|
||||
`serve` executes the installed package with that machine's operating system privileges. It never downloads packages
|
||||
or accepts source uploads. Set a custom token variable with `--token-env VARIABLE_NAME`. The token must have at least
|
||||
32 characters. Interrupting the command stops its worker and subscriptions. See [remote widget runners](../../management/custom-widgets/remote-runners.mdx)
|
||||
for connection setup, local files, SQL, MQTT, and browser-service adapters.
|
||||
|
||||
### Share several widgets as a collection
|
||||
|
||||
A collection contains independent compiled widget packages and a shared connection blueprint. Write a collection
|
||||
manifest with paths to already packed archives:
|
||||
|
||||
```json
|
||||
{
|
||||
"manifest": { "id": "example.home", "version": "1.0.0", "name": "Home dashboard" },
|
||||
"connections": { "monitor": { "label": "Monitoring server", "kind": "integration" } },
|
||||
"widgets": [
|
||||
{ "key": "clock", "archive": "clock/dist/widget.homarr-widget.json" },
|
||||
{
|
||||
"key": "servers", "archive": "beszel/dist/widget.homarr-widget.json",
|
||||
"connections": { "beszel": "monitor" }
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Pack and verify it without compiling or executing the member packages:
|
||||
|
||||
```sh
|
||||
homarr widgets collection pack collection.json --output home.homarr-collection.json
|
||||
homarr widgets collection validate home.homarr-collection.json
|
||||
homarr widgets collection import home.homarr-collection.json --url http://homarr.local:7575
|
||||
```
|
||||
|
||||
`import` uses `HOMARR_API_KEY`, or the variable selected with `--api-key-env`. Pass `--bindings bindings.json` to map
|
||||
each collection slot to an existing local Homarr connection once; all members that reference that slot receive the
|
||||
binding. Omitted connections can be configured later. Imports create every member as a disabled draft in one database
|
||||
transaction and print their review links. Trust and activation are separate, explicit steps.
|
||||
|
||||
Collections support 1–32 members and up to 128 MiB. Package identities, compiled artifacts, dependency locks and
|
||||
documented Workshop/fork attribution travel with the archive. The collection and each nested artifact have integrity
|
||||
checksums. Local connection URLs, IDs and credentials, board placements, stored widget data and local configuration
|
||||
are excluded. Authored `options` on a member are portable defaults: include only values you intend to share. Package
|
||||
source is included verbatim, so embedded literals are still part of the archive.
|
||||
|
||||
## Build a local branch harness
|
||||
|
||||
The repository's host-side CLI can build the current checkout and run it as a named Docker harness:
|
||||
|
||||
@@ -140,3 +140,14 @@ The advanced deployments environment variables should only be used if you know w
|
||||
|
||||
All public URL variables reject non-HTTP protocols, embedded credentials, query strings, and fragments, and normalize
|
||||
trailing slashes when Homarr or Docusaurus starts.
|
||||
|
||||
## Trusted widget packages
|
||||
|
||||
| Variable | Purpose | Default |
|
||||
| --- | --- | --- |
|
||||
| `CUSTOM_WIDGET_PACKAGE_PATH` | Persistent build and runtime artifact cache. Activated browser/server artifacts and their source are also retained in the database. | `/appdata/custom-widgets` in production; `./appdata/custom-widgets` in development |
|
||||
| `CUSTOM_WIDGET_MAX_SERVER_PROCESSES` | Maximum active trusted widget server artifacts per Homarr process, from 1 to 128. Source-free packages do not start a server process. | `16` |
|
||||
|
||||
Each replica materializes an authorized installed artifact from the database into its own cache. Dashboard requests do
|
||||
not install npm dependencies. Package dependencies are resolved and bundled when an owner previews or activates a new
|
||||
source draft; importing a complete compiled archive supports offline activation. See [trusted widget packages](/docs/management/custom-widgets/trusted-packages).
|
||||
@@ -32,3 +32,10 @@ import { calendarWidget } from "@site/docs/widgets/calendar";
|
||||
},
|
||||
]}
|
||||
/>
|
||||
|
||||
### Trusted widget packages
|
||||
|
||||
The [Sonarr operations reference package](/docs/management/custom-widgets/trusted-packages) can combine two Sonarr
|
||||
integrations, display upcoming and missing episodes and queue progress, and submit a confirmed search for a missing
|
||||
episode. Search actions use the existing integration API key on Homarr's server and require interaction access.
|
||||
A successful command submission means Sonarr queued the search, not that it found or downloaded a release.
|
||||
@@ -98,3 +98,41 @@ and focused references under `/api/custom-widgets/`.
|
||||
|
||||
Use [Custom Widget agent authoring](../custom-widgets/agent-authoring) for the lifecycle and
|
||||
[MCP](../mcp) when the client supports Model Context Protocol.
|
||||
|
||||
## Trusted widget package lifecycle
|
||||
|
||||
The `customWidget.package` tRPC namespace separates authoring from activation. Administrators can save incomplete
|
||||
source with `saveDraft`, inspect `draftChanges`, run `preview`, and call `activate` after acknowledging trusted code.
|
||||
`getRaw` and `repair` on `customWidget` recover existing v2 definitions without rendering their code.
|
||||
|
||||
The package API also manages named local connections, per-placement guest grants, retained collectors, immutable
|
||||
archive import/export, forks, Workshop releases, staged updates, and rollback. `get` and `list` return management data
|
||||
without evaluating submitted package modules. Connection secret values are accepted separately by `saveConnection`
|
||||
and are not returned by connection listing or package export.
|
||||
For an existing connection, `secretUpdates` patches only supplied credential keys while retaining the others;
|
||||
`secrets` replaces the complete credential map. Supply only one. Credential patches require the saved connection
|
||||
kind and authentication method to match the submitted configuration.
|
||||
|
||||
`previewStorageGet` and `previewStorageSet` use the owning administrator's preview session and the same temporary
|
||||
store as its server handlers. They accept `previewId`, `scope`, and `key`; writes also accept `value`.
|
||||
Expired, discarded, and other users' sessions cannot read or write preview storage.
|
||||
|
||||
Connection configuration accepts `kind: "http" | "integration" | "service"`. A service connection supplies a
|
||||
`serviceType` and a JSON `settings` object without requiring a URL; encrypted `secrets` remain a separate input.
|
||||
Package requirements match both `kind` and `serviceType`. Server handlers access these settings through
|
||||
`getWidgetConnection` in `@homarr/widget-sdk/server`. Service diagnostics distinguish file readability, TCP
|
||||
reachability and settings-only checks; preview runs the adapter's actual database or protocol operation.
|
||||
|
||||
Installed widgets use `widget.customApi.packageQuery`, `packageAction`, `packageSubscription`, `packageStorageGet`,
|
||||
and `packageStorageSet`. Each invocation is bound to an existing board item and a manifest-declared handler; the host
|
||||
checks the current board and integration permissions. A public board does not grant action access automatically.
|
||||
Guest grants name a handler and exact allowed inputs, and are invalidated by changes to server behavior, dependencies,
|
||||
connection identity, or resource-selecting options.
|
||||
|
||||
Compiled surfaces are served through `/api/custom-widgets/artifacts/{itemId}/{digest}/{surface}` after board access
|
||||
checks. The optional `?asset=css` selects the corresponding stylesheet. Preview surfaces use
|
||||
`/api/custom-widgets/previews/{previewId}/{surface}` and require the administrator who created the preview.
|
||||
These routes do not expose server source or connection credentials.
|
||||
|
||||
The full package format, SDK examples, trust boundary, and activation behavior are described in
|
||||
[trusted widget packages](../custom-widgets/trusted-packages).
|
||||
@@ -38,3 +38,17 @@ A backup can be restored on another Homarr instance. When its `SECRET_ENCRYPTION
|
||||
integration secrets for the target instance. Version metadata is used to apply compatible migrations.
|
||||
|
||||
The same restore flow is available during first-run onboarding, before the target database contains user data.
|
||||
|
||||
## Custom widget packages
|
||||
|
||||
Database backups include installed v2 definitions and trusted v3 source, compiled artifacts, current and previous
|
||||
activation metadata, local connections, placement bindings, guest grants, and managed widget storage/history.
|
||||
Restoring an encrypted backup re-encrypts widget credentials with the destination instance's key alongside native
|
||||
integration credentials. Compiled artifacts can be materialized again from the restored database without Workshop.
|
||||
|
||||
Keep `SECRET_ENCRYPTION_KEY` with database backups made using MySQL or PostgreSQL administration tools. The built-in
|
||||
ZIP export/restore remains specific to SQLite. A package export is portable distribution material and deliberately
|
||||
excludes local connections, credentials, stored values, and collected history; it is not a complete instance backup.
|
||||
|
||||
Files created directly by trusted Node code, external databases, remote-runner state, and changes already made to
|
||||
other applications are outside Homarr's managed widget storage. Include those resources in your own backup process.
|
||||
@@ -5,15 +5,27 @@ JSON is available when direct editing is faster.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Configure each API source, network scope, authentication method, and credential.
|
||||
2. Add named queries and actions. Values can reference widget options or invocation parameters.
|
||||
1. Start with a static widget, or add API sources, network access, authentication, and credentials when needed.
|
||||
2. Add named queries and actions for connected services. Values can reference widget options or invocation parameters.
|
||||
3. Define widget options and their defaults.
|
||||
4. Write JSX using `data`, `status`, `options`, and temporary `inputs`.
|
||||
5. Run **Test and preview**, inspect the response data and redacted request journal, then save.
|
||||
|
||||
Changing the definition, options, or credentials invalidates the previous preview. Preview actions are simulated unless
|
||||
Changing the definition, options, or credentials ends the previous API preview session. The last response remains visible
|
||||
as a labelled snapshot while you edit JSX. Run **Test and preview** again to refresh data and enable API interactions.
|
||||
Preview actions are simulated unless
|
||||
**Run actions against the configured API** is enabled for that preview session.
|
||||
|
||||
Use the workbench **Undo** and **Redo** buttons or `Ctrl/Cmd+Z` and `Ctrl/Cmd+Shift+Z` for changes across JSX, sources,
|
||||
requests, options, and metadata. History is bounded to 100 entries and about two million characters. **Reset to saved**
|
||||
restores the last saved definition. Credentials are excluded from this history and reset clears unsaved credential values.
|
||||
Undo and Redo retain pending credentials only when the source origin, network scope, and authentication destination
|
||||
are unchanged. Otherwise, enter the credentials again for the restored source.
|
||||
|
||||
Homarr keeps one recovery draft per signed-in user in this browser, replacing the previous draft as you edit. On returning
|
||||
to that widget, choose **Restore draft** or **Discard draft**. Saved credentials stay on the server; unsaved credentials must
|
||||
be entered again. Browser storage is optional, and drafts larger than one million characters are not stored for recovery.
|
||||
|
||||
Widget options support text, textarea, number, switch, select, multi-select, slider, date, time, color, icon, URL,
|
||||
duration, time zone, and JSON controls. Dynamic choices can come from a load query.
|
||||
|
||||
|
||||
@@ -6,8 +6,14 @@ Templates are JSX expressions interpreted inside a widget-local safety and rende
|
||||
- `status.requestId` — `{ loading, ok, status, statusText, error }`
|
||||
- `options.name` — saved widget configuration
|
||||
- `inputs.name` — temporary values from declarative `bind`
|
||||
- `host` — the widget's board context, dimensions, scale, and compact or advanced display mode
|
||||
|
||||
The v2 manifest requires a `default` source and supports up to eight sources, 64 requests, and 64 options. Source IDs are
|
||||
Existing callbacks may still use `host` as their parameter name, such as `data.hosts.map(host => host.name)`.
|
||||
Inside that callback, `host` refers to the current item; outside it, `host` refers to the widget context.
|
||||
|
||||
The v2 manifest supports empty `sources` and `requests` for widgets that do not need an API. Connected widgets support
|
||||
up to eight sources, 64 requests, and 64 options. Each request must reference a defined source; omitting `source` uses
|
||||
`default` only when a source with that ID exists. Source IDs are
|
||||
case-insensitively unique. Each request allows up to 32 static headers and 32 invalidation targets; a widget can contain
|
||||
up to 24 secrets, each up to 8,192 characters, and templates are limited to 50,000 characters. Validation reports the
|
||||
exact field when a limit is exceeded.
|
||||
|
||||
@@ -15,7 +15,10 @@ Custom Widgets may change during the v2 release cycle. Share feedback in the
|
||||
|
||||
:::
|
||||
|
||||
A **Custom Widget** is a validated `homarr-custom-widget-v2` definition containing API sources, queries and actions,
|
||||
Custom Widgets supports [trusted widget packages](./trusted-packages) with full TSX, CSS, modules, optional Node
|
||||
handlers, and advanced views, alongside the restricted v2 authoring format. Both can work without an API.
|
||||
|
||||
A **v2 Custom Widget** is a validated `homarr-custom-widget-v2` definition containing optional API sources, queries and actions,
|
||||
optional settings, and a safe JSX template.
|
||||
|
||||
Homarr executes requests on the server and renders the template in a restricted runtime. Source credentials are
|
||||
@@ -37,6 +40,8 @@ boards; actions require authentication and the permission declared by the reques
|
||||
|
||||
## Authoring
|
||||
|
||||
- [Build a trusted widget package](./trusted-packages), configure local connections, and manage its Workshop releases.
|
||||
|
||||
- [Create a Custom Widget](./authoring) in the workbench or from a copied AI prompt.
|
||||
- [Use the safe JSX runtime](./custom-jsx) for data bindings, temporary inputs, and components.
|
||||
- [Browse the component reference](./component-reference).
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: Remote widget runners
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
A trusted widget server normally runs beside Homarr. The optional runner executes one installed widget package on
|
||||
another machine. Use it when the data lives on a NAS filesystem, a separate Docker network, or a host with a database
|
||||
or browser service that Homarr cannot reach. The runner has the privileges of the account starting it; its child
|
||||
process provides cancellation and restart, not security isolation.
|
||||
|
||||
## Install a runner
|
||||
|
||||
Build an archive using `homarr widgets pack widget.json --trust`, copy the archive to the target machine, and run:
|
||||
|
||||
```sh
|
||||
export HOMARR_WIDGET_RUNNER_TOKEN="$(openssl rand -hex 32)"
|
||||
homarr widgets serve widget.homarr-widget.json --trust --host 127.0.0.1 --port 8787
|
||||
```
|
||||
|
||||
The runner uses the compiled artifact and bundled JavaScript dependencies. It does not contact an npm registry or
|
||||
accept package uploads. Restart it with a different archive to update its installed version. Keep the token in the
|
||||
runner environment and Homarr's encrypted connection store. Use a private interface or an HTTPS reverse proxy when
|
||||
Homarr runs on another machine. `127.0.0.1` identifies the machine or container running the runner.
|
||||
|
||||
In Homarr, create an HTTP connection with the runner's base URL and bearer token. Bind it to the package's named
|
||||
`runner` connection. Only declared query, action, and subscription handlers are remotely callable. Migration
|
||||
handlers remain local lifecycle operations. Homarr still authorizes the dashboard placement and its named handler
|
||||
before calling the runner; the runner token represents the trusted Homarr caller.
|
||||
|
||||
## Call a remote handler
|
||||
|
||||
The local package's `server.ts` can forward to a handler installed on the runner:
|
||||
|
||||
```ts
|
||||
import { callWidgetRunner, defineWidgetServer, subscribeWidgetRunner } from "@homarr/widget-sdk/server";
|
||||
|
||||
export default defineWidgetServer({
|
||||
status: (input, context) => callWidgetRunner(context, { connection: "runner", handler: "status", input }),
|
||||
activity: async function* (input, context) {
|
||||
yield* subscribeWidgetRunner(context, { connection: "runner", handler: "activity", input });
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Declare `status` as a query and `activity` as a subscription in both manifests. The remote package accesses its own
|
||||
environment and filesystem. It has no automatic backchannel to Homarr's storage, native integrations, or connection
|
||||
credentials. Put those operations in the local forwarding handler when needed.
|
||||
|
||||
The pull subscription transport waits up to ten seconds per read, buffers at most 32 values or 8 MiB, and closes
|
||||
subscriptions that are not read for sixty seconds. Returning from an async generator completes the stream. Use
|
||||
`context.signal` to release connections and stop work on cancellation.
|
||||
|
||||
## Apps without an HTTP API
|
||||
|
||||
An API request is optional. A widget may use only JSX, local browser state, a timer, or static information. Trusted
|
||||
server handlers can read files, speak other protocols, or query a database using the runner's location and account.
|
||||
|
||||
For an application that writes a JSON status file, a remote handler can read that file:
|
||||
|
||||
```ts
|
||||
import { readFile } from "node:fs/promises";
|
||||
import { defineWidgetServer } from "@homarr/widget-sdk/server";
|
||||
|
||||
export default defineWidgetServer({
|
||||
status: async (_input, context) => {
|
||||
const path = process.env.APP_STATUS_FILE;
|
||||
if (!path) throw new Error("Set APP_STATUS_FILE on the runner");
|
||||
return JSON.parse(await readFile(path, { encoding: "utf8", signal: context.signal }));
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
For an application's SQLite database, Node 24 provides a built-in driver:
|
||||
|
||||
```ts
|
||||
import { DatabaseSync } from "node:sqlite";
|
||||
import { defineWidgetServer } from "@homarr/widget-sdk/server";
|
||||
|
||||
export default defineWidgetServer({
|
||||
recentJobs: () => {
|
||||
const path = process.env.APP_DATABASE;
|
||||
if (!path) throw new Error("Set APP_DATABASE on the runner");
|
||||
const database = new DatabaseSync(path, { readOnly: true });
|
||||
try {
|
||||
return database.prepare("SELECT name, status FROM jobs ORDER BY id DESC LIMIT 20").all();
|
||||
} finally {
|
||||
database.close();
|
||||
}
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Adapt the query to the application's actual schema. For PostgreSQL, MySQL, or MQTT, declare an exact version of a
|
||||
JavaScript client dependency, bundle it when packing, and use the runner environment for service credentials. MQTT
|
||||
subscriptions fit async generator handlers; close the broker client when the handler's signal aborts. Persistent
|
||||
history belongs in Homarr's collection and history APIs or the application's database.
|
||||
|
||||
A browser-only application can be adapted through an existing browser automation service reachable from the runner.
|
||||
Call that service from a server handler and return structured data to the tile. Browser binaries and native addons
|
||||
are not shipped inside portable widget archives. Directly bundling a library that requires native addon loading is
|
||||
rejected; use an independently installed service for that runtime dependency.
|
||||
|
||||
These paths enable adapters for many self-hosted applications. The application must still expose something the
|
||||
runner can read or control, such as HTTP, a socket, a file, a database, or a browser session.
|
||||
@@ -1,15 +1,21 @@
|
||||
# Configure requests and security
|
||||
|
||||
Most widgets use a single source named `default`; the manifest must contain it. Extra keyed sources are available for widgets
|
||||
Widgets can use empty `sources` and `requests` objects when they do not need an API. Connected widgets may use a source
|
||||
named `default` or explicitly name the source on every request. Extra keyed sources are available for widgets
|
||||
that combine APIs. Source IDs are case-insensitively unique. Base URLs must use HTTP(S), contain no embedded credentials,
|
||||
query string, or fragment, and sources can be `public`, `private`, or `loopback`. Authentication is `none`, `bearer`,
|
||||
`basic`, an API-key header, or an API-key query parameter. Credentials belong to the widget but remain outside its manifest.
|
||||
Source origins are fixed by the definition and source-setup flow; widget options and invocation parameters cannot redirect a
|
||||
request to a different origin.
|
||||
|
||||
Use `private` for LAN addresses, Docker service names, and Tailscale's `100.64.0.0/10` range. Use `loopback` for
|
||||
`127.0.0.1` or `::1`. Requests run from Homarr: in Docker, loopback addresses point to the Homarr container, while a
|
||||
service name such as `http://sonarr:8989` must resolve on its Docker network. Public sources cannot reach private or
|
||||
loopback addresses. Cloud metadata, link-local, multicast, and other reserved targets remain blocked.
|
||||
|
||||
## Named requests
|
||||
|
||||
Requests are keyed by ID. `source`, `kind`, `method`, `trigger`, `auth`, and `permission` have sensible defaults, so a load query can be as small as:
|
||||
Requests are keyed by ID. With a source named `default`, a load query can be as small as:
|
||||
|
||||
```json
|
||||
{ "status": { "path": "/api/status" } }
|
||||
|
||||
@@ -0,0 +1,411 @@
|
||||
---
|
||||
title: Trusted widget packages
|
||||
sidebar_position: 2
|
||||
tags: [Custom Widgets, JSX, Workshop]
|
||||
---
|
||||
|
||||
# Trusted widget packages
|
||||
|
||||
Trusted packages let administrators write complete React/TSX modules, import CSS and dependencies, and optionally run
|
||||
Node server handlers. A package can provide a dashboard tile, an advanced widget view, and a custom configuration
|
||||
view. Static content, clocks, interactive local state, and other source-free widgets need no API connection.
|
||||
|
||||
Open **Management → Custom Widgets → Packages**. The source-free world clock is the default starter. Thirteen reference starters cover clocks, timers, checklists,
|
||||
downloads, Sonarr, racks, backups, household controls, service overview, media, Beszel, SQLite, and MQTT. Each new widget receives
|
||||
its own local package identity. The Beszel
|
||||
reference package demonstrates a connected widget using Homarr's shared SDK and integration data.
|
||||
|
||||
## Trust and execution
|
||||
|
||||
Packages are trusted installed code. Browser modules run within Homarr; Node handlers have Homarr's server
|
||||
privileges. Review the complete source and dependency list before checking the trust acknowledgement. Both
|
||||
**Run preview** and **Activate saved draft** execute package code. An action simulation is not a security sandbox:
|
||||
trusted code can make direct network requests and external changes outside the SDK.
|
||||
|
||||
Workshop browsing displays screenshots, source text, dependencies, and immutable release metadata. It does not run
|
||||
package code. Importing a package creates a disabled draft. Connection credentials are entered separately on your
|
||||
Homarr installation.
|
||||
|
||||
A supplied archive can include compiled browser and server code. Its digest verifies that those bytes are intact;
|
||||
it does not prove they were built from the displayed source. Inspect **Compiled artifact** and the dependency lock
|
||||
as well as the source before activating a supplied build. Rebuilding from reviewed source produces a new local
|
||||
artifact; dependency installation happens during that build, never while rendering a dashboard.
|
||||
|
||||
## Package, installation, and placement
|
||||
|
||||
| Concept | Contains |
|
||||
| ------------ | ------------------------------------------------------------------------------------------------------------- |
|
||||
| Package | Portable manifest, source files, exact dependency versions, named connection requirements, option definitions |
|
||||
| Installation | Saved source draft, active compiled release, previous activation, local connection bindings, enabled state |
|
||||
| Placement | A tile on a board, its option values, connection overrides, board permissions, widget state |
|
||||
|
||||
One installation can appear on several boards. Activating it updates all its placements. A placement's saved option
|
||||
values survive updates; changing package defaults does not overwrite those saved values.
|
||||
|
||||
## Customize a native widget
|
||||
|
||||
Administrators can choose **Customize as a widget package** from supported native widget menus. Homarr prepares a
|
||||
reference package and reuses its existing integration connections. The original native widget remains on the board.
|
||||
Save the new package, preview and activate it, then add its placement to the board. The package has its own identity
|
||||
and can be edited independently of the native widget.
|
||||
|
||||
## Author a package
|
||||
|
||||
The workspace has a file explorer, TSX/CSS/JSON editor, a connection panel, activation and board controls, and a
|
||||
preview canvas with adjustable width and height. Use `widget.json` to edit package metadata. This is a virtual view
|
||||
of the package envelope excluding `files`; each source file is edited separately in the explorer.
|
||||
|
||||
Use **Add**, **Rename**, and **Remove** to organize source files. When renaming a file, update its imports and any
|
||||
manifest entrypoints that reference the old path. JSX imports and ordinary React hooks are supported by the trusted
|
||||
package compiler; the restricted v2 interpreter does not process these files.
|
||||
|
||||
The package envelope uses `$schema: "homarr-widget-package-v3"` and contains:
|
||||
|
||||
| Field | Purpose |
|
||||
| -------------- | ------------------------------------------------------------------------------------ |
|
||||
| `manifest` | Package identity, release version, SDK version, entrypoints, handlers, and metadata |
|
||||
| `files` | Relative file paths mapped to source text |
|
||||
| `dependencies` | Additional npm dependencies pinned to exact versions |
|
||||
| `connections` | Named HTTP, Homarr integration, or service requirements; local bindings are separate |
|
||||
| `options` | Controls, labels, defaults, and constraints for placement settings |
|
||||
|
||||
`manifest.entrypoints.tile` is required. `advanced`, `configuration`, and `server` are optional. Entrypoints must
|
||||
refer to files in the package. A package with named server handlers needs a server entrypoint. The `manifest.id`
|
||||
identifies the package across releases; `manifest.version` uses a complete semantic version such as `1.0.0`.
|
||||
|
||||
Homarr provides React, Mantine, and `@homarr/widget-sdk` as shared host modules. Referenced Tabler icons are bundled
|
||||
from Homarr's installed version, which is recorded in the artifact lock. The reference packages show how to use the SDK for host dimensions, theme and locale, options, state, commands, data queries, and advanced
|
||||
views. Put additional dependencies in the package's dependency map rather than copying Homarr's internal source tree.
|
||||
|
||||
## Convert an existing Custom JSX widget
|
||||
|
||||
Choose **Convert to a widget package** from a valid Custom JSX widget's list row or editor. Conversion uses its saved
|
||||
definition and creates a separate disabled package. The original definition and its board placements remain in
|
||||
place. Local connections and encrypted credentials are copied on the server, keeping them out of portable source.
|
||||
|
||||
The initial package retains a compatible JSX surface and options. Converted dynamic options remain available through
|
||||
the authored configuration surface. Extend the package with TSX modules, CSS, or an advanced
|
||||
view in the workspace. Review the generated files, preview, and explicitly activate the package before adding it
|
||||
to a board. Conversion itself does not execute or replace the original widget. After activation, **Replace an
|
||||
existing Custom JSX tile** lets you choose one original placement and explicitly replace it. Position, size, refresh
|
||||
interval and configured values are retained; the original definition and other placements stay available. Use
|
||||
**Add to board** when you want a separate tile instead.
|
||||
|
||||
## Assistant authoring
|
||||
|
||||
Choose **Ask Assistant** in the workspace to describe a widget or request changes. Shortcuts help improve the
|
||||
current widget, add an advanced view, or fix current errors. This opens Homarr's existing Assistant; it uses the
|
||||
visible unsaved draft, public SDK guidance, reference packages, and source validation diagnostics.
|
||||
|
||||
The Assistant reads source on demand. Local connection settings, bindings, credential fields, preview option
|
||||
values, and runtime response data are excluded. Recognized credential literals are redacted from source context;
|
||||
keep secrets in local connections. Files with redacted credentials must be edited directly before the Assistant can
|
||||
replace them. Files omitted because a response reached its context budget must be read separately before proposing changes.
|
||||
Individual files over 180,000 characters and manifests over 60,000 characters require direct editing.
|
||||
|
||||
Proposals display each changed file before and after in the Assistant. **Apply to draft** applies the complete
|
||||
proposal as one Undo step. If the draft changes while a proposal is waiting, the Assistant must read it again and
|
||||
propose against the new revision. Applying a proposal does not save, trust, preview, activate, or publish it.
|
||||
|
||||
Preview evidence identifies only the exact current candidate that compiled and received a preview session.
|
||||
Compilation does not prove successful browser rendering or live actions. Source, option, and binding changes
|
||||
invalidate that evidence; use the preview canvas to verify the final result before activation.
|
||||
|
||||
## Save, preview, and activate
|
||||
|
||||
Drag the divider between source and preview to resize the workspace. The divider also supports arrow keys,
|
||||
Home/End, and double-click to reset. The preference is saved in your browser. On smaller screens, switch between
|
||||
Code and Preview without unmounting the working preview.
|
||||
|
||||
The preview offers compact, wide, phone, and tablet viewport presets, independent width/height controls, and a
|
||||
25–200% display scale. Scaling changes both the visual surface and the SDK's visible dimensions. Light and dark
|
||||
preview modes stay local to the preview; they do not change your Homarr theme. These presentation controls do not
|
||||
rebuild code, clear query data, or require another preview session.
|
||||
|
||||
The source editor understands the package's TypeScript and TSX files together. Press **Ctrl+Space** for typed
|
||||
completions, hover a symbol for its type and documentation, or press **F12** to open its definition. Definitions
|
||||
inside the installed SDK or its dependencies open as read-only excerpts. **F2** renames a symbol across package
|
||||
files; the complete rename is one Undo operation. **Format** uses TypeScript formatting for TS/TSX files.
|
||||
|
||||
Semantic diagnostics appear in the editor and its expandable issue list. They use declarations generated from this
|
||||
Homarr installation's actual SDK, React, Mantine, and Node dependencies. Include `.d.ts` files when another package
|
||||
needs declarations that are not installed with Homarr. These editor diagnostics do not block saving a draft or
|
||||
replace the preview compiler's runtime compatibility checks. Analysis runs in a local browser worker, without
|
||||
executing your source or downloading code or types from a CDN.
|
||||
|
||||
For Homarr development, `pnpm dev` and the Next.js build regenerate the worker and installed declarations. After
|
||||
editing SDK source while the dev server is already running, run `pnpm --filter @homarr/custom-widgets generate:editor`
|
||||
and reopen the workspace. Generated assets are included in the standalone image's public directory.
|
||||
|
||||
1. **Save draft** persists the current source without building or executing it. Incomplete TSX and metadata JSON can
|
||||
be saved for later repair. Saving a draft leaves the active dashboard release running.
|
||||
2. Review the code and dependencies, acknowledge trust, and choose **Run preview**. The preview builds the current
|
||||
editor contents and runs them in a temporary session. Select tile, advanced, or configuration view when provided.
|
||||
**Preview options** controls the configuration used for this session.
|
||||
3. Save your final changes, review the activation's placement count, then choose **Activate saved draft**. The server
|
||||
validates and builds the saved source before switching the installation. Activation enables the installation.
|
||||
4. Choose a board and configure the new placement under **Activation & boards → Add to board**.
|
||||
|
||||
Changing source, options, local preview bindings, or the live-action mode invalidates execution evidence for the previous candidate.
|
||||
The last successful view remains visible with a stale label and paused SDK activity while you edit or fix a failed
|
||||
build. Its session is released after a replacement loads successfully or the workspace closes. Re-run preview to
|
||||
inspect the changed inputs. Pausing SDK activity does not sandbox arbitrary effects inside trusted code. Preview widget storage is temporary:
|
||||
frontend storage hooks and server handlers share the same preview-session values, isolated from dashboard storage
|
||||
and other preview sessions. Completing an action refreshes queries and managed storage in that preview.
|
||||
SDK named actions are simulated by default. Enable **Allow live SDK actions for this preview session** and run
|
||||
preview again to operate the real service through SDK actions. The session label shows its mode. Changing source,
|
||||
bindings, or connection settings turns this option off. Direct behavior inside trusted code remains the owner's responsibility.
|
||||
|
||||
## Synthetic preview scenarios
|
||||
|
||||
Authors can include `previewScenarios` in package source to review success, loading and partial failures with
|
||||
synthetic data. A scenario maps declared query handler names to JSON results or errors:
|
||||
|
||||
```json
|
||||
{
|
||||
"previewScenarios": {
|
||||
"partialFailure": {
|
||||
"label": "Storage unavailable",
|
||||
"queries": {
|
||||
"memory": { "data": { "usedPercent": 38 } },
|
||||
"storage": {
|
||||
"error": { "message": "Synthetic storage collector timeout", "code": "TIMEOUT" },
|
||||
"delayMs": 700
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Select a scenario when creating a preview. Its ID and the exact compiled source are stored in that preview session;
|
||||
changing the scenario requires a new preview. Required local connections can remain unbound. Fixture queries return
|
||||
the authored JSON without starting the package's server module or calling a configured service. A query without a
|
||||
fixture fails explicitly; it never falls back to live data. Each handler receives the same fixture regardless of its
|
||||
input. Declared input validation still applies.
|
||||
|
||||
SDK actions are simulated in fixture mode, and enabling live actions together with a scenario is rejected.
|
||||
Subscriptions are unavailable in this bounded query-fixture mode. The SDK capability helper remains available so
|
||||
action controls can display their simulated state. Production dashboard queries always execute the active package's
|
||||
normal handlers; a preview scenario never changes an installation or its placements.
|
||||
|
||||
[Download the complete example](/custom-widgets/preview-scenarios.json) for two independent local metrics with ready,
|
||||
delayed and partial-failure scenarios. It needs no API or local connection. Import the source, review trust, and
|
||||
preview its named scenarios. Its ordinary handlers read local memory and filesystem metrics when used without a scenario.
|
||||
|
||||
Scenarios support up to 16 names, 64 query fixtures each, 2 MiB of total fixture JSON, and delays of up to 30 seconds.
|
||||
Errors can use `BAD_REQUEST`, `NOT_FOUND`, `TIMEOUT` or `INTERNAL_SERVER_ERROR`; the latter is the default. Request
|
||||
cancellation and discarding the session cancel pending fixture delays.
|
||||
|
||||
Fixtures are explicitly authored package source and are included in source exports, offline archives and Workshop
|
||||
releases. Homarr does not capture live responses into scenarios. Use invented values and review fixture contents
|
||||
before sharing. This is SDK simulation, not a security sandbox: trusted browser code can still make direct requests,
|
||||
and compiling uncached dependencies can require registry access. Review source and acknowledge trust as usual.
|
||||
|
||||
## Local connections
|
||||
|
||||
The **Unified downloads** starter accepts a primary and optional second download integration. Each source has its
|
||||
own queue, loading state, error and retry control, so a failed client leaves the other queue usable. Advanced view
|
||||
adds filtering, sorting, per-client and per-item controls, and pause/resume for all or selected clients. Batch
|
||||
results identify successful and failed clients individually. Per-item actions resolve the current item from the
|
||||
selected client, and confirmed removal keeps downloaded files. The composed overview reuses the same modules.
|
||||
Controls consult the current viewer's capabilities. Guests need an explicit grant for an exact input such as
|
||||
`{"connection":"secondary","operation":"pause"}` on `control`; batch grants additionally list every target in
|
||||
`connections`. No guest action is enabled merely by installing the starter.
|
||||
|
||||
Choose **Service** for MQTT, SQLite, SSH, local files or another protocol. Service connections require a
|
||||
`serviceType` matching the package requirement, arbitrary nonsecret JSON settings, and optional encrypted
|
||||
credentials. They do not require an HTTP URL. For example, declare
|
||||
`{kind: "service", serviceType: "sqlite", label: "Database"}` in a package and bind a local connection with
|
||||
settings such as `{"path":"/data/app.sqlite"}`. MQTT commonly uses `{"url":"mqtt://mosquitto:1883","topics":["sensors/#"]}`;
|
||||
put its username and password in the encrypted credentials field. Leave that field blank to keep existing
|
||||
credentials, or select **Replace saved credentials** to clear them explicitly.
|
||||
|
||||
Server handlers call `getWidgetConnection(context, {connection: "database", serviceType: "sqlite"})` from
|
||||
`@homarr/widget-sdk/server` to obtain the local settings and secrets for a Node library. These credentials are
|
||||
never returned by the browser connection API. Authors must keep this object server-side and return only the
|
||||
data their widget needs. File paths resolve inside Homarr's container/process; mount the required files there
|
||||
and give the Homarr process access. Use a remote runner when the adapter must execute on another machine.
|
||||
|
||||
Diagnostics report what they actually verify: SQLite/file connections check regular-file readability, and MQTT
|
||||
connections check TCP reachability. Neither check claims database-query validity or MQTT authentication. Run
|
||||
preview to exercise the real query or authenticated subscription. Other service types report configured settings
|
||||
and require their adapter's preview for a protocol check. The **SQLite and local status** and **MQTT live topics**
|
||||
starters include complete adapters; MQTT pins its reviewed `mqtt` dependency, while SQLite uses Node's built-in
|
||||
module. Their package READMEs document connection settings, limits, cancellation and deployment details.
|
||||
|
||||
Declare named requirements in the package and bind them to reusable local connections in **Connections**. A
|
||||
connection can point to an existing Homarr integration or an HTTP endpoint. HTTP setup supports a separate server
|
||||
and browser URL, Basic authentication, bearer tokens, secret headers or query parameters, cookies, TLS verification, and a timeout.
|
||||
|
||||
Server requests originate from Homarr's server or container. Examples include `http://sonarr:8989`,
|
||||
`http://192.168.1.20:8080`, and a Tailscale address. `127.0.0.1` addresses the network namespace running Homarr; it does
|
||||
not address the dashboard viewer's browser or a different container. Enter full URLs including the protocol. For a bare address such as `sonarr:7573`, the connection form offers an
|
||||
explicit **Use http://sonarr:7573** suggestion. Choosing it adds the protocol while preserving the supplied host,
|
||||
port, and path; use HTTPS when required by the service.
|
||||
|
||||
**Diagnose** shows the reached stage, resolved addresses, HTTP status and timing, and top-level JSON field names
|
||||
without response values. The primary result distinguishes name resolution, network, TLS, HTTP and authentication
|
||||
failures; expand **Technical details** for the full diagnostic. **Save installation bindings** changes the defaults inherited by every placement.
|
||||
Individual placements can override connections in their board configuration. **Edit connection** updates a reusable
|
||||
connection for every widget that uses it. Empty credential fields retain stored credentials; changing authentication
|
||||
requires entering the credentials for the new method.
|
||||
For Basic authentication, you can update the username or password independently: leaving the other field blank
|
||||
preserves its saved value. Updating a bearer token, cookie, username, or password also preserves a saved TLS private key.
|
||||
|
||||
Connection credentials are encrypted in Homarr's database. Connection forms and their credential fields are not
|
||||
included in the package editor's Undo/Redo or browser recovery. Keep credentials out of source files: source files
|
||||
are portable and can be exported or published.
|
||||
|
||||
## Recovery and operational rollback
|
||||
|
||||
Disabling an enabled guest action does not depend on the validity of its edited input JSON. You can revoke access
|
||||
immediately from the action's Disable control while repairing those inputs.
|
||||
|
||||
Activation also coordinates with widget settings, board saves, additions, and board duplication. If a package
|
||||
changes while one of these saves is waiting, Homarr asks you to reload before saving again so an older
|
||||
configuration cannot overwrite its migration. Changing a placement's connection overrides invalidates guest
|
||||
action approvals tied to the previous bindings.
|
||||
|
||||
**Undo/Redo** covers the whole source document: metadata, files, and installation name. History is bounded to 100
|
||||
entries and 2 MB in the current editor session. **Reset to saved** restores the saved draft. Homarr keeps one browser
|
||||
recovery draft per signed-in owner, up to 1 MB, and offers to restore it when opening the matching package.
|
||||
Recognized credential literals are redacted from recovery source; use connection fields for secrets.
|
||||
|
||||
Package release history is separate from editor Undo/Redo. **Roll back previous activation** restores the previous
|
||||
compiled release and its activation snapshot of local bindings, placement options, and widget data. You must
|
||||
acknowledge discarding newer widget data. Calls already made to an external service cannot be reversed by rollback.
|
||||
Your source draft remains available for further work.
|
||||
|
||||
**Disable installation** stops that installation across all placements. It is independent of saving a source draft.
|
||||
|
||||
## Import, export, fork, and update
|
||||
|
||||
**Import package** accepts source JSON or a `homarr-widget-archive-v3` archive. Archives contain source plus a compiled
|
||||
artifact; compatible matching artifacts can be activated without rebuilding dependencies. Imports create disabled
|
||||
drafts for review. **Export source draft** exports current editor contents, including incomplete work.
|
||||
**Export active archive** exports the activated release and its compiled artifact. Local connection credentials and
|
||||
board placements are not part of these exports.
|
||||
|
||||
**Stage archive update** replaces the installation's saved draft after explicit acknowledgement and keeps its active
|
||||
release running. **Review saved draft changes** shows changed files before and after, dependency changes, connection
|
||||
requirements, and configuration changes. **Fork as a new package** copies saved source to a new disabled installation
|
||||
with a new package identity; it does not change the original installation's board placements.
|
||||
|
||||
## Portable widget collections
|
||||
|
||||
A `homarr-widget-collection-v1` archive groups several independent packages with named shared connection slots.
|
||||
Import binds a slot once and fans it out to every member that needs it. All imported packages start as disabled
|
||||
drafts; importing does not install dependencies or execute widget code. Each package keeps its own identity,
|
||||
activation, updates, settings and dashboard placements.
|
||||
|
||||
The complete collection is validated before creating installations. Invalid member code checksums, mismatched
|
||||
connection types or invalid portable option defaults reject the import with no new installations. Installation
|
||||
records are committed together; immutable artifact cache entries from a database failure may remain until cleanup.
|
||||
|
||||
Export uses the selected installations' activated archives. Shared local bindings become named requirements, while
|
||||
their connection IDs, URLs and credentials stay local. Export also excludes placement settings and widget storage.
|
||||
Only explicit authored defaults belong in the portable blueprint. Workshop and fork attribution is retained, and
|
||||
normal package updates retain the collection's membership and connection mapping. Review code literals before
|
||||
sharing, since package source is exported verbatim.
|
||||
|
||||
From the installed package library, choose **Collections** to export selected active packages or resume an imported
|
||||
collection. Import its JSON archive using **Import**. The setup page asks for shared connections once, lets you
|
||||
choose widgets and their options, and activates the selected packages after you acknowledge trust. **Activate and
|
||||
add missing widgets** places them on the selected board. Each member reports its own result, and retrying skips
|
||||
placements already present on that board. You can stop after the current member finishes.
|
||||
|
||||
See the [collection CLI commands](../../advanced/command-line/index.mdx#share-several-widgets-as-a-collection) for
|
||||
packing, validation and importing through an admin API key. Collections support up to 32 widgets and 128 MiB.
|
||||
|
||||
## Workshop lifecycle
|
||||
|
||||
In Workshop, select a release, inspect source files and dependencies, and optionally bind its named connections.
|
||||
**Import for review** opens the package workspace with a disabled local installation. Preview and activate it after
|
||||
reviewing trust, then add it to a board.
|
||||
|
||||
The workspace's Workshop section checks for newer releases and reports local source changes. Staging an update
|
||||
requires acknowledging replacement of the saved draft; the active release continues running until activation.
|
||||
Fork or export local changes you want to keep before replacing the draft.
|
||||
|
||||
Publishing requires a Workshop account and an explicit review of the saved source for secrets, local information,
|
||||
and permission to share the code and dependencies. Publish a new package, an immutable release of a package you own,
|
||||
or an attributed fork. Give each release a new version in the manifest and describe its changes. Local bindings and
|
||||
credentials remain on the Homarr installation.
|
||||
|
||||
## Reference packages with local services
|
||||
|
||||
**Sonarr operations** supports two native Sonarr connections, upcoming and missing episodes, queue progress, source
|
||||
filtering, and confirmed episode-search actions. Compact view shows four rows; the advanced view shows all loaded
|
||||
rows with text filtering. Each server contributes up to 100 missing or queued episodes. An unavailable second
|
||||
server does not hide the primary server's results. Searching requires native integration interaction access and
|
||||
submits a Sonarr command; a queued command does not prove an eligible release was found or downloaded.
|
||||
|
||||
**Filesystem backup monitor** reads backup metadata and an optional JSON status report mounted into Homarr. Its
|
||||
README contains the success/failure/running report format, timestamps, duration, size and retained run history.
|
||||
The optional **Run backup** action uses a fixed executable and argument array deliberately configured in
|
||||
`command.ts`. It runs through Node `execFile` without a shell, requires full placement permission, and never accepts
|
||||
command text from the browser. Preview simulates it. Mount the executable into Homarr, then review and activate its
|
||||
configuration. Backup activity and status reports do not verify restore integrity.
|
||||
|
||||
**Media and camera wall** combines native media sessions with optional authenticated camera snapshots and an Immich
|
||||
image gallery. Camera paths share a bound HTTP connection; its credentials stay on the server. Immich uses a secret
|
||||
`x-api-key` header with `asset.read` and `asset.view`. The package fetches images server-side and returns bounded
|
||||
image data to the widget. It supports up to eight camera snapshots and twelve Immich thumbnails. Clicking an image
|
||||
opens the advanced view with shared selection. Camera snapshots poll; this reference does not stream RTSP or other
|
||||
continuous video, and individual images must remain under 675 KiB.
|
||||
|
||||
## Optional history collection
|
||||
|
||||
A placement’s **History collection** shows its latest retained sample and time. Expand the sampled-point table for
|
||||
recent values or **Technical details** for the stored record.
|
||||
|
||||
Expand a placement’s **History collection** to select a named query handler, input JSON, value path, unit, sampling
|
||||
interval, retention period, and maximum sample count. Collection is disabled by default. Enabling it runs the query
|
||||
on Homarr’s server even when the dashboard is closed. Pause it without deleting samples, or explicitly discard
|
||||
the collection and its history. The collection panel shows recent samples and request errors; package code can
|
||||
consume retained history through the widget SDK.
|
||||
|
||||
## Guest actions
|
||||
|
||||
A package can declare a named action as available for guest grants. Under a placement's **Guest actions**, the owner
|
||||
enables that specific handler for an explicit JSON array of permitted inputs. Other inputs remain denied. Changing
|
||||
server code, dependencies, or bound connection configuration invalidates the grant and requires owner renewal.
|
||||
Board access and the package's declared permissions still govern normal authenticated usage.
|
||||
|
||||
## Repair a v2 widget
|
||||
|
||||
The existing restricted v2 workbench remains available from the installed widgets tab. Invalid v2 definitions expose
|
||||
**Repair widget**, which shows validation issues and editable source without changing the widget's dashboard ID.
|
||||
Save repaired source or export a repair draft. Credentials are retained only when the original source and
|
||||
authentication binding remain unchanged; configure credentials again when those bindings change.
|
||||
|
||||
## Build cache maintenance
|
||||
|
||||
Administrators can call `customWidget.package.cleanupArtifacts` through the authenticated API. Start with
|
||||
`{ "dryRun": true }` to inspect candidate artifact IDs and local directories, then call it with `dryRun: false` to
|
||||
remove those that are still unused. Cleanup preserves active and previous releases, every valid saved source draft
|
||||
(including disabled offline imports), and artifacts leased by recent imports, builds or previews. Unreferenced data
|
||||
must be at least seven days old. Preview sessions themselves expire after one hour.
|
||||
|
||||
Each call removes at most 100 database artifacts and 20 local directories by default. Adjust `maximumArtifacts`
|
||||
(up to 500) and `maximumDirectories` (up to 100), or repeat when the result reports `limited: true`. Directory cleanup
|
||||
applies to the current Homarr replica's runtime and dependency cache. Other replicas can clean their own local cache
|
||||
through the same procedure. Cleanup coordinates reference changes across replicas and never invokes package code.
|
||||
This is explicit maintenance; no automatic build-cache cleanup job is enabled.
|
||||
|
||||
For an external editor workflow with normal files, local previews and immutable release publishing, see the
|
||||
[widget CLI commands](../../advanced/command-line/index.mdx#build-and-share-custom-widget-packages).
|
||||
|
||||
Each server worker runs at most eight handlers concurrently and queues at most 64 more for up to 30 seconds.
|
||||
Extra requests receive a capacity error; one failing source does not block successful results from other requests.
|
||||
|
||||
## Webhook lifecycle and advanced links
|
||||
|
||||
Each placement can issue a separate token for a named action with an input schema. Homarr displays the POST URL and
|
||||
bearer token once. Tokens stay outside source drafts, recovery and exports. Code or local binding changes invalidate
|
||||
existing tokens; create a new one for the updated placement. Explicitly revoked tokens remain revoked after rollback.
|
||||
The webhook accepts JSON matching the action schema, up to 1 MiB, and runs with its owner's current authorization.
|
||||
|
||||
A board URL can link directly to an installed widget's advanced view using `#widget=<placementId>`. The viewer still
|
||||
needs access to the board and widget. This opens the dashboard widget surface rather than a standalone app route.
|
||||
@@ -20,3 +20,14 @@ Each task exposes:
|
||||
|
||||
|
||||
Disabling a task stops scheduled runs but does not prevent a manual run.
|
||||
## Widget history collectors
|
||||
|
||||
Trusted widget installations can opt into background sampling from their **Activation & boards** workspace tab.
|
||||
Each collector names a declared query, input, optional response field, interval, and retention limit. Collection is
|
||||
separate from viewer refresh; Redis admits one sampling run per interval across serving replicas. New collectors are
|
||||
disabled until the owner enables them. The owner must retain administrator access for collection to continue.
|
||||
|
||||
The production application schedules enabled collectors while it is running, including when no dashboard is open.
|
||||
Each series is bounded by its configured retention/sample count and a 1 MiB managed record limit. Pausing a collector
|
||||
stops requests. Removing it explicitly removes its retained series. Application history APIs remain preferable when
|
||||
available because Homarr cannot collect observations while it is offline.
|
||||
@@ -37,6 +37,8 @@ Custom Widget credentials are configured in your Homarr instance and are not par
|
||||
|
||||
Publish a saved Custom Widget from its action menu under **Management → Custom Widgets**. Custom CSS and manual
|
||||
submissions can be published from the Workshop website.
|
||||
Trusted v3 packages publish immutable releases. When editing a release and its screenshots together, Homarr validates
|
||||
the screenshot count before publishing, so an invalid screenshot edit does not consume the proposed package version.
|
||||
|
||||
Sign in to the Workshop and open **Yours** to update or delete submissions and review reports. Signed-in users can vote,
|
||||
comment, and report content; Workshop moderators can remove content. Workshop moderation is separate from administration
|
||||
|
||||
@@ -305,7 +305,9 @@ const MarketplaceDetail = ({ workshopUrl }: { workshopUrl: string }) => {
|
||||
const widgetDefinition = useMemo<HomarrCustomWidgetV2 | null>(() => {
|
||||
if (submission?.type !== "customWidget") return null;
|
||||
const result = validateSubmissionContent("customWidget", submission.content);
|
||||
return result.success && typeof result.data === "object" ? result.data : null;
|
||||
if (!result.success || typeof result.data !== "object" || result.data.$schema !== "homarr-custom-widget-v2")
|
||||
return null;
|
||||
return result.data;
|
||||
}, [submission]);
|
||||
|
||||
const handleVote = async (value: 1 | -1) => {
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
import { CUSTOM_WIDGET_SCHEMA, type HomarrCustomWidgetV2 } from "@homarr/custom-widgets/core";
|
||||
import type { CustomWidgetPackage } from "@homarr/custom-widgets/package";
|
||||
import {
|
||||
MAX_WORKSHOP_CSS_LENGTH,
|
||||
type WorkshopSubmissionType,
|
||||
@@ -12,7 +13,7 @@ export const CSS_SCHEMA_VERSION = WORKSHOP_CSS_SCHEMA;
|
||||
export const MAX_CSS_LENGTH = MAX_WORKSHOP_CSS_LENGTH;
|
||||
|
||||
export type WorkshopValidationResult =
|
||||
| { success: true; data: HomarrCustomWidgetV2 | string }
|
||||
| { success: true; data: HomarrCustomWidgetV2 | CustomWidgetPackage | string }
|
||||
| { success: false; error: string };
|
||||
|
||||
export const schemaVersionByType = {
|
||||
|
||||
@@ -0,0 +1,83 @@
|
||||
{
|
||||
"$schema": "homarr-widget-package-v3",
|
||||
"manifest": {
|
||||
"id": "homarr.example.preview-scenarios",
|
||||
"version": "1.0.0",
|
||||
"sdkVersion": "1",
|
||||
"name": "Preview scenario example",
|
||||
"description": "Two independent local metrics with synthetic success, loading and partial-failure scenarios.",
|
||||
"entrypoints": {
|
||||
"tile": "widget.tsx",
|
||||
"advanced": "widget.tsx",
|
||||
"server": "server.ts"
|
||||
},
|
||||
"handlers": {
|
||||
"memory": {
|
||||
"kind": "query"
|
||||
},
|
||||
"storage": {
|
||||
"kind": "query"
|
||||
}
|
||||
}
|
||||
},
|
||||
"files": {
|
||||
"widget.tsx": "import { Alert, Card, Group, Progress, Stack, Text } from \"@mantine/core\";\nimport { useWidgetQuery } from \"@homarr/widget-sdk\";\ninterface MetricData { usedPercent: number; }\ninterface MetricProps { title: string; query: ReturnType<typeof useWidgetQuery<MetricData>>; }\nfunction Metric({ title, query }: MetricProps) {\n return <Card withBorder><Stack gap=\"xs\"><Text fw={600}>{title}</Text>\n {query.isPending && <Text c=\"dimmed\">Loading…</Text>}\n {query.error && <Alert color=\"orange\">{query.error.message}</Alert>}\n {query.data && <><Group justify=\"space-between\"><Text>Used</Text><Text>{query.data.usedPercent}%</Text></Group><Progress value={query.data.usedPercent} /></>}\n </Stack></Card>;\n}\nexport default function LocalMetrics() {\n const memory = useWidgetQuery<MetricData>(\"memory\", {}, {refetchInterval: 10000});\n const storage = useWidgetQuery<MetricData>(\"storage\", {}, {refetchInterval: 10000});\n return <Stack p=\"md\"><Metric title=\"Memory\" query={memory} /><Metric title=\"Storage\" query={storage} /></Stack>;\n}\n",
|
||||
"server.ts": "import { freemem, totalmem } from \"node:os\";\nimport { statfs } from \"node:fs/promises\";\nimport { defineWidgetServer } from \"@homarr/widget-sdk/server\";\nexport default defineWidgetServer({\n memory: () => ({usedPercent: Math.round(100 * (1 - freemem() / totalmem()))}),\n storage: async () => {const value = await statfs(process.cwd()); return {usedPercent: Math.round(100 * (1 - value.bavail / value.blocks))};},\n});\n"
|
||||
},
|
||||
"dependencies": {},
|
||||
"connections": {},
|
||||
"options": {},
|
||||
"previewScenarios": {
|
||||
"ready": {
|
||||
"label": "Both metrics available",
|
||||
"queries": {
|
||||
"memory": {
|
||||
"data": {
|
||||
"usedPercent": 38
|
||||
}
|
||||
},
|
||||
"storage": {
|
||||
"data": {
|
||||
"usedPercent": 72
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"loading": {
|
||||
"label": "Slow storage collector",
|
||||
"description": "Memory appears first; storage stays loading for three seconds.",
|
||||
"queries": {
|
||||
"memory": {
|
||||
"data": {
|
||||
"usedPercent": 38
|
||||
},
|
||||
"delayMs": 100
|
||||
},
|
||||
"storage": {
|
||||
"data": {
|
||||
"usedPercent": 72
|
||||
},
|
||||
"delayMs": 3000
|
||||
}
|
||||
}
|
||||
},
|
||||
"partialFailure": {
|
||||
"label": "Storage unavailable",
|
||||
"description": "Memory still renders when the storage collector fails.",
|
||||
"queries": {
|
||||
"memory": {
|
||||
"data": {
|
||||
"usedPercent": 38
|
||||
}
|
||||
},
|
||||
"storage": {
|
||||
"error": {
|
||||
"message": "Synthetic storage collector timeout",
|
||||
"code": "TIMEOUT"
|
||||
},
|
||||
"delayMs": 700
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
Reference in new issue
Block a user