Self-Host Signet AI and Connect It with Localtonet

What Signet AI adds to a self-hosted agent workflow

AI tools commonly store their context inside separate applications, sessions, or provider-specific histories. Moving from one harness to another can therefore fragment decisions, preferences, project history, and other working knowledge. Signet addresses that problem by running as a local-first memory and context layer underneath supported tools. Its purpose is to make context inspectable and portable instead of locking it inside one agent interface.

A Signet installation includes a local daemon, a workspace, command-line management, and a dashboard for inspecting memory and retrieval. The project describes its local workspace as portable files backed by SQLite. Search and ranking remain on the device, and the dashboard exposes the relationships among memories, source material, and claims. This source-backed structure is important when an agent response must be audited rather than accepted as an unexplained recollection.

Signet can build memories from transcripts, imported files, and connected sources. Its background process, called dreaming, distills useful information, supersedes stale claims rather than simply accumulating them, and retains relevant context for later sessions. The resulting memory graph preserves a route back to source material so that a user can inspect why a memory exists.

Remote access is intentionally a separate stage in this guide. A tunnel cannot repair an incomplete Signet installation, a stopped daemon, a failed provider configuration, or an unhealthy memory pipeline. First establish that Signet works on the host. Only then should you decide whether its web endpoint needs to be reachable from another location.

Prerequisites and deployment decisions

Signet's supported native installation targets include Linux on x64 and arm64, macOS on x64 and arm64, and Windows on x64. Docker is also listed as a supported deployment path. Durable transcript imports and deletion of imported sources are documented across Windows, Linux, and macOS.

Before installing, choose a machine that can remain available while your agents need memory services. The machine does not need an inbound public port for Localtonet. Our client establishes an outbound connection to a Localtonet relay server, so the later remote-access workflow does not require router port forwarding, firewall changes, VPN setup, or a public IP address.

Prepare the following:

• A supported Linux, macOS, or Windows host, or an environment in which you will follow Signet's official Docker instructions.
• A terminal with permission to install software for the current user or system, depending on the selected installer.
• An AI provider configuration appropriate for the memory extraction and recall workflow you intend to use.
• Any supported agent harnesses that you want the setup wizard to connect.
• A browser on the local machine for testing the Signet dashboard.
• A Localtonet account and Localtonet client on a device that can reach the dashboard, but only after local verification is complete.

Provider credentials and service tokens should be prepared through the provider's normal credential-management process. Do not paste credentials into shared shell history, screenshots, tickets, tunnel descriptions, or public documentation. Signet's setup supports provider connection through OAuth sign-in or API keys, but the appropriate choice depends on the provider and your operating requirements.

Install Signet AI using an official method

Choose one installation method. Do not run multiple global installers merely to see which one works, because that can create uncertainty about which executable appears first in your command path. After installation, continue with the same signet command regardless of whether the native binary was obtained through the shell installer, PowerShell, npm, or Bun.

Recommended installation on Linux or macOS

Run the project's recommended shell installer:

curl -fsSL https://signetai.sh/install.sh | bash

This command downloads the hosted installer and sends it to the shell. As with any remote installation script, use it only when you trust the official domain and understand that the retrieved script can install executable code. In managed environments, review the installer and apply your organization's software approval process before execution.

Installation on Windows x64

Open PowerShell and run the documented installer:

iwr -useb https://signetai.sh/install.ps1 | iex

The supplied project evidence identifies Windows x64 as the supported Windows target for this installer. It does not establish Windows arm64 support, so do not assume that architecture is supported through this path.

Installation with npm

If npm is already part of your managed toolchain, install the global wrapper:

npm install -g signetai

The npm package is a wrapper that installs the corresponding compiled Signet binary. It is not evidence that Signet's normal runtime is implemented as an interpreted npm application.

Installation with Bun

Bun users can install the corresponding global wrapper:

bun add -g signetai

As with the npm path, the wrapper installs the matching compiled native binary.

Docker installation

Signet lists Docker among its supported deployment methods. However, the supplied official evidence does not specify a canonical container image, tag, volume mapping, internal port, published port, environment variables, health check, or complete container command. Those details affect workspace persistence and network exposure, so inventing them would be unsafe.

If you choose Docker, use the current Signet container documentation to obtain the exact image and persistence instructions. Confirm that the workspace is stored on durable storage before importing transcripts or creating memories. Also determine whether the dashboard is published only to the host loopback interface or to a broader interface. Do not create a Localtonet target until the container's actual host address and published port have been verified.

Development installation from source

A source checkout is intended for development rather than the shortest self-hosting path. The documented repository workflow is:

git clone https://github.com/Signet-AI/signetai.git
cd signetai
bun install
bun run build
bun test
bun run lint

The repository then documents separate development commands for the daemon and dashboard:

cd platform/daemon && bun run dev

cd surfaces/dashboard && bun run dev

Bun is required for the normal repository development workflow. The project also specifies Node.js 18 or later for Node-targeted packages. Development servers can differ from packaged releases in port selection, restart behavior, and network binding, so discover their active endpoint from current command output rather than applying assumptions from a native installation.

Run the Signet setup and configure the daemon

Once the signet executable is available, use the project's quick-start sequence. The setup command configures the local service and integrations, the status command checks daemon and pipeline health, and the dashboard command opens the memory and retrieval inspector.

Run the commands directly if you prefer to see each stage:

signet setup
signet status
signet dashboard

The stable setup flow uses a reviewable plan. Before applying changes, it can show the configuration it intends to create. Current supported setup capabilities include provider connection through OAuth or API keys, model selection from a shared provider catalog, separate configuration for memory extraction and aggregate recall, connection to an Obsidian vault, multiple-agent setup, and background-memory behavior.

Setup also supports a remote Signet service through daemon.url, file or JSON input, dry runs, and non-interactive environments. Those modes are valuable for repeatable operations, but exact file schemas and invocation flags are not included in the supplied evidence. Use the installed version's official CLI reference before automating setup, and never infer a configuration schema from examples for another release.

Configure supported agent harnesses and knowledge sources

Signet runs beneath supported agent tools rather than replacing them. Run signet setup to configure the plugins and connectors required by your environment. Integration mechanisms vary by harness, so do not copy one tool's hook or MCP configuration into another.

Start with one harness if this is your first deployment. Create a harmless test preference or project fact, end the session normally, and then verify that the next session can retrieve it with a visible source trail. Once that path works, add other harnesses to the same workspace one at a time. This approach makes it easier to identify whether a failure belongs to the daemon, a particular connector, transcript capture, provider routing, or recall.

Connect external knowledge carefully

Signet documents real-time connections for Obsidian, Discord, and GitHub. Obsidian can watch multiple vaults in a read-only knowledge workflow and supports the LLM-Wiki format. Discord content can be crawled into memory, while GitHub issues, pull requests, and discussions can contribute to the knowledge graph.

Slack, email, Telegram, WhatsApp, webpage imports, and Notion are described as coming soon in the supplied project material. Do not design a production workflow on the assumption that those connectors are already available in your installed release.

Supported one-time import formats include Word documents with .doc, .docx, and .docm extensions; PowerPoint formats including .ppt, .pps, .pot, .pptx, .pptm, .ppsx, and .ppsm; Excel formats including .xls, .xlsx, .xlsm, and .xlsb; OpenDocument files including .odt, .ods, and .odp; plus .rtf, .epub, .csv, and .pdf.

Verify Signet locally before creating a tunnel

Local verification protects you from debugging several layers at once. If the dashboard cannot be opened on the Signet host, a public URL will not solve the problem. If it opens on the host but not from the device running our client, the issue is local reachability or interface binding rather than the tunnel itself.

Check daemon and pipeline status

signet status

Read the complete status output. The stable release has strengthened reporting for provider routes, embedding coverage, configuration errors, and blocked memory paths, but the exact output can change by version. Treat a reported unhealthy or incomplete component as actionable even if the dashboard itself opens.

Open the dashboard through the supported command

signet dashboard

Observe the browser address or terminal output generated by this command. Record the scheme, host, port, and any path component exactly as shown. The supplied README does not establish a universal local URL, listening port, authentication default, or whether the API and dashboard share one endpoint. We therefore do not provide placeholder values that could send readers to the wrong service.

Exercise a small end-to-end memory workflow

Before adding important data, create a non-sensitive test through a configured harness. Confirm that the relevant session or source is captured, that background processing completes, and that a later recall returns the expected information. Use the dashboard to inspect the memory and its path back to source material. A successful page load alone proves only that the web interface responds, not that ingestion and recall are healthy.

Test from the Localtonet client device

If our client will run on the same machine, test the dashboard locally there. If it will run on another device, confirm that device can reach the Signet endpoint over the local network using the exact address that you plan to enter as the tunnel target. A service bound only to loopback is normally reachable only from the same host. Do not broaden the service's listening interface merely for convenience without evaluating the resulting LAN exposure.

Connect the verified Signet dashboard with Localtonet

Once the dashboard is healthy and you know its exact local IP address and port, you can configure an HTTP tunnel. The Localtonet client should run on the Signet host or on another device that can reach that host. Our client creates an outbound connection to a selected relay server and provides a public address for the tunnel.

HTTP and File Server tunnels support Random Sub Domain, Custom Sub Domain, or Custom Domain process types. Each serves the configured content at a public HTTPS address. Availability of options can vary, and custom-domain DNS requirements must be checked against current documentation before configuration. For a straightforward first test, select an available process type shown in your dashboard rather than assuming a particular custom-domain setup.

For current dashboard details, use our Localtonet tunnel documentation. Exact client installation commands, available regions, plan-specific capabilities, and custom-domain DNS requirements are not fixed in the supplied context, so verify those values in the current dashboard rather than copying unconfirmed settings.

Secure a remotely reachable Signet endpoint

The main security decision is not whether a tunnel can reach the dashboard. It is whether the endpoint is appropriate to expose at all. Signet may centralize exactly the context that an attacker would find useful: development transcripts, personal preferences, project structure, institutional knowledge, identity instructions, source documents, and secrets.

Before starting the tunnel, establish the installed version's authentication behavior from current Signet configuration documentation or the running service. The evidence supplied for this guide does not confirm whether the dashboard authenticates users by default, which mechanisms it supports, or whether dashboard and API authorization are independent. We will not imply protections that have not been established.

TLS at the public tunnel address protects the public HTTP connection at the tunnel edge, but it is not a substitute for application authorization. Authentication decides who may use Signet. Authorization decides which operations and information an authenticated user may access. Network exposure, application security, provider permissions, and workspace contents must all be evaluated separately.

If the installed Signet dashboard does not provide controls appropriate to your risk level, keep it local until a supported protection design is available. Do not improvise undocumented headers, guessed environment variables, or an assumed authentication mode. An inaccessible remote dashboard is preferable to an exposed memory and secrets console.

Routine operation, updates, and workspace care

A self-hosted memory service needs ongoing operational attention. Check signet status after host reboots, provider changes, integration updates, and application upgrades. If agents suddenly stop recalling recent work, verify daemon health and the processing pipeline before changing prompts or reinstalling connectors.

Update a stable installation

Existing installations can use:

signet update

The project also documents this command for reinstalling or updating through npm:

npm install -g signetai

After updating, run:

signet status
signet dashboard

Then test one configured harness and a harmless memory-recall cycle. Updates can affect daemon behavior, connector assets, provider routing, embedding indexes, and managed integration paths. Recent stable release work has specifically improved stale runtime recovery and integrations that retained an outdated SIGNET_PATH after an update or workspace move.

Keep the workspace recoverable

Signet describes its context as portable local files and a SQLite workspace. Establish a backup process appropriate to the current workspace layout, but verify the exact directories and consistency requirements from the installed version before copying a live database. The supplied project material references ~/.agents/signet as the local workspace location, but deployment modes and configuration can vary. Confirm the active workspace rather than assuming every installation uses the same path.

Test restoration in a separate environment using non-production credentials. A backup is not proven until it can be restored and the daemon, dashboard, source provenance, and recall pipeline can all read it correctly.

Coordinate service and tunnel availability

Remote access has two independent lifecycles. Signet must be running and healthy, and the Localtonet client must be connected with the tunnel started. Stopping either side makes the public workflow unavailable. This separation is useful during maintenance because you can stop the tunnel while updating or repairing Signet without deleting the tunnel configuration.

Troubleshooting the installation and remote connection

The signet command is not found

Open a new terminal after installation so that updated command-path settings can load. Confirm that you used one supported installer and review its output for a failed download, permission problem, unsupported architecture, or path warning. Avoid installing through several methods at once, since multiple binaries can make version checks and updates ambiguous.

signet status reports an unhealthy daemon or pipeline

Resolve the reported local problem before working on Localtonet. Review the setup plan, provider sign-in, API-key availability, selected model routes, and any configuration error shown by the installed release. The stable service is designed to surface missing-provider and blocked-route conditions more clearly, so do not treat an explicit warning as a harmless cosmetic message.

The dashboard command runs, but no page opens

Inspect the terminal output for the address generated by signet dashboard, then open that exact address manually on the same machine. Do not substitute a commonly used development port. If no URL is shown or the command reports an error, consult the current Signet CLI and dashboard documentation for that installed version.

The dashboard works on the host but not from the Localtonet client device

This usually indicates a local reachability difference. Confirm whether our client is on the same host. If it is on another machine, verify that the Signet service listens on an address reachable from that machine and that local network policy allows the connection. Changing a loopback-only binding to a LAN-accessible binding increases exposure, so make that change only through a documented Signet configuration and with an appropriate security review.

The tunnel exists but the public address does not work

Confirm that the correct Localtonet client device is connected, the tunnel has been explicitly started, and the target IP address and port match the locally verified Signet endpoint. Creating a tunnel record alone does not run it. Also confirm that Signet remained healthy after the tunnel was configured.

The public URL opens the wrong application

Stop the tunnel immediately and compare its target with the exact URL opened by signet dashboard. A wrong port can expose another local service. Correct the target only after identifying the intended Signet listener.

Memories are missing even though the dashboard loads

Separate web reachability from memory processing. Run signet status, check that the intended harness integration is active, and verify that the transcript or source entered the workspace. Then inspect provider routing, background work, embeddings, and source provenance. A reachable dashboard does not prove that a connector captured the session or that dreaming completed.

An integration stopped working after an update or workspace move

Rerun or review the supported setup process for that integration. Managed integrations can retain an obsolete executable path, and recent stable changes specifically address stale SIGNET_PATH handling. Do not manually invent connector paths if the setup wizard can regenerate the integration safely.

Remote access works, but the authentication model is unclear

Stop the tunnel while investigating. Determine the dashboard and API authentication behavior from current Signet documentation and configuration for the installed version. Public HTTPS transport does not prove that application-level access is restricted.

Frequently asked questions