> For the complete documentation index, see [llms.txt](https://docs.bosonnetwork.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bosonnetwork.io/core-concepts/node-types.md).

# Node Types

Boson defines three node roles. The role you choose determines whether you participate directly in DHT routing, whether you host Layer-2 services, and how you connect to the network.

## The three types

### Super Node

A super node runs a **full Kademlia DHT node** and **hosts one or more Layer-2 services**. It requires a public IP address so that its services are reachable from anywhere on the internet.

Super nodes are managed by the **Director** process, which owns the DHT node lifecycle, starts and stops services, manages user accounts and devices, and handles inter-node federation.

Typical deployments: VPS servers, dedicated servers, on-premises infrastructure with a public IP.

### Regular Node

A regular node (also called a native node) runs a **full Kademlia DHT node** but does **not host services**. It participates in routing and can store and retrieve values and peers directly from the DHT. It connects to Layer-2 services hosted on super nodes as a client.

A regular node does not need to be reachable by others to use the DHT: it sends its own requests and receives the answers. It joins the network through one or more known bootstrap nodes or super nodes.

Typical deployments: native desktop applications, mobile apps, embedded devices.

### Light Node

A light node does **not run a DHT node at all**. Instead it uses the `web-gateway` service to proxy all DHT operations over HTTP. The gateway translates `FIND_NODE`, `FIND_VALUE`, `STORE_VALUE`, `FIND_PEER`, and `ANNOUNCE_PEER` requests into actual DHT calls on the client's behalf.

All gateway requests must carry a valid CWT, so light nodes still have a cryptographic identity - they just do not contribute to DHT routing.

Typical deployments: web applications running in a browser, thin clients, environments where UDP is blocked.

## Comparison Table

| Feature                | Super Node            | Regular Node                | Light Node                |
| ---------------------- | --------------------- | --------------------------- | ------------------------- |
| DHT participation      | Full (UDP)            | Full (UDP)                  | None - via web-gateway    |
| Hosts Layer-2 services | Yes                   | No                          | No                        |
| Requires public IP     | Yes (for services)    | No                          | No                        |
| Managed by Director    | Yes                   | No                          | No                        |
| CWT-authenticated      | Services accept CWTs  | Issues CWTs                 | Issues CWTs               |
| Typical use case       | Server infrastructure | Native desktop / mobile     | Browser app               |
| Network bootstrap      | Seeds the network     | Bootstraps from super nodes | Connects to a web-gateway |

## When to choose each type

{% tabs %}
{% tab title="I need to run a server" %}
Deploy a **Super Node**. Install the Boson Debian package or ZIP distribution on a VPS with a public IP. The Director runs the DHT node and all configured services. Start with [Planning a Deployment](/deploy-a-node/planning.md), then [Installation](/deploy-a-node/installation.md).
{% endtab %}

{% tab title="I'm building a native app" %}
Embed a **Regular Node** so your app participates in DHT routing directly and consumes services on remote super nodes. You have two options:

* **Java SDK** (`boson-dht`) - available today. See [Java SDK - Creating a Full Node](/build-applications/java-sdk/full-node.md).
* **Rust DHT node** - a native DHT node implementation purpose-built for native applications. **(Coming soon.)**
  {% endtab %}

{% tab title="I'm building a web app" %}
Use a **Light Node** pattern via the `web-gateway` HTTP API. Your frontend authenticates with a CWT and calls the gateway endpoints for DHT operations. You have a few options:

* **JavaScript SDK** - a light node implementation for browser apps. **(Coming soon.)**
* **HTTP / REST** - call the gateway endpoints directly from any language. See [HTTP / REST Integration](/build-applications/http-rest.md).
* **Java SDK** (`HiggsNode`) - for JVM-based clients. See [Java SDK - Light Node via Web Gateway](/build-applications/java-sdk/light-node.md).
  {% endtab %}
  {% endtabs %}

## Bootstrap Nodes

There is a fourth deployment variant not listed above: the **bootstrap node**. This is a stripped-down super node that runs only the DHT node (`KadNode`) - no Director, no Layer-2 services. It exists purely to seed new nodes into the network.

The Debian bootstrap package (`boson-bootstrap-<version>-amd64.deb`) installs and manages a bootstrap node as a `systemd` service. See [Bootstrap Node](/deploy-a-node/installation/bootstrap-node.md).

{% hint style="info" %}
Bootstrap nodes are not a different *type* - they are regular DHT participants with no services running. The distinction is purely operational.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bosonnetwork.io/core-concepts/node-types.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.