# System requirements

> The server, ports, database and secrets Nasnet Linux needs before you install it.

Source: https://joinnasnet.com/en/guides/nasnet-linux/system-requirements/
Last updated: 2026-08-17

---

## Overview

Nasnet Linux runs on one 64-bit Linux server and keeps everything on it,
meaning the panel, the database, and the Xray-core process it supervises.
There is no fleet and no second machine to provision. What you actually have to decide before
installing is the database, whether you have a domain, and which ports you can
open.

## The server

| Requirement | Value |
| ----------- | ----- |
| Operating system | 64-bit Linux |
| Architecture | `amd64` or `arm64` |
| Access | root or `sudo` |
| Panel port | One free inbound port, **`9761`** by default |
| Inbound ports | Whatever your proxy inbounds will listen on, open separately |
| Outbound | Needed for ACME certificates and image pulls; the offline bundle removes this |

The release binaries are static and built without CGO, so there is no
distribution-specific runtime to install. A domain pointed at the server is
strongly recommended rather than strictly required, for the reason given below.

## Supported devices

Two different sets of devices matter here. The **server** is the machine that
runs the panel. The **clients** are what your subscribers use to consume the
proxy access it hands out.

### Servers

| Platform | Supported | Notes |
| -------- | --------- | ----- |
| Linux `amd64` | Yes | The common case. Release binaries and Docker images both cover it. |
| Linux `arm64` | Yes | Fully supported, including on ARM VPS instances. |
| Linux 32-bit | No | No 32-bit builds are published. |
| macOS or Windows | No | The panel supervises a local Xray process and expects Linux. |

Any distribution works, because the release binaries are static and built
without CGO. There is nothing distribution-specific to install alongside them.

### Client apps

Subscribers do not install anything of yours. They paste a `/sub/{key}` link
into a normal proxy client, and the server tailors its response to whichever
client asked by inspecting the `User-Agent`.

| Client | Typical platform |
| ------ | ---------------- |
| v2rayNG | Android |
| v2rayN | Windows |
| Clash and Clash-family clients | Android, Windows, macOS, Linux |
| sing-box | Android, iOS, desktop |
| Shadowrocket | iOS |

One link works across all of them, so a subscriber never has to pick a format
by hand. Clients outside this list still work if they understand the standard
base64 subscription format, but they receive the generic response rather than a
tailored one. A subscriber who opens the link in a browser gets the
[subscriber panel](/en/guides/nasnet-linux/subscriber-panel/) instead.

## Database

Pick one before you install; switching later means a migration.

| Option | When to use it | Setting |
| ------ | -------------- | ------- |
| PostgreSQL 16 | Production. The default, and what Docker Compose brings up. | `DB_DRIVER=postgres` |
| SQLite | Trials and small single-server setups. No database container. | `DB_DRIVER=sqlite`, `DB_PATH=/app/data/nasnet_panel.db` |

Schema migrations run automatically on every startup, so an upgrade is usually
just a new binary and a restart. Take a backup first regardless.

## TLS and cookies

You can run on a bare IP over plain HTTP for testing, but the panel's session
cookies are `Secure` cookies: without HTTPS, logins will not stick. For anything
you intend to use, either point a domain at the server and let the built-in ACME
client issue a certificate, or terminate TLS in a proxy in front of the panel.

Automatic issuance needs `ACME_EMAIL` set, because issuance is disabled without
it.

## For a Docker install

| Requirement | Value |
| ----------- | ----- |
| Docker Engine | Current release |
| Compose plugin | Required, since the repository ships a `docker-compose.yml` |
| Services started | The app, PostgreSQL 16, and Prometheus |
| Volumes | `postgres_data`, `acme_data`, `prometheus_data`, and a bind mount for backups |

## Secrets you must generate

Every install path needs these, whichever way you deploy. The guided installer
generates them for you; otherwise:

```bash
# JWT secret, which must be at least 32 characters
openssl rand -hex 32

# Admin password as a bcrypt hash, not plaintext
htpasswd -nbBC 10 "" "your-password" | tr -d ':\n' | sed 's/$2y/$2a/'
```

`ADMIN_PASSWORD_HASH` holding a plaintext password is the single most common
reason a fresh install will not let you log in.

## Building from source

Only needed for development. The web panel is embedded into the binary with
`go:embed`, so it has to be built before `go build`. Use the `make` targets
rather than calling `go build` directly.

| Requirement | Value |
| ----------- | ----- |
| Go | 1.26 or newer |
| Node.js | 22 or newer |
| Package manager | pnpm |

## Related

- [Installation](/en/guides/nasnet-linux/install/)
- [TLS and domains](/en/guides/nasnet-linux/tls-and-domains/)
- [Architecture](/en/guides/nasnet-linux/architecture/)