Host your own server

Run Nod on a Linux server or Mac mini, then use the same assistant from your other devices.

One server belongs to one person. Its access token grants full access to that person's assistant and connected accounts. There is no registration or multi-user setup.

What you need

Requirement	Detail
Computer	Linux AMD64 or ARM64, or a Mac with Docker Desktop. Start with two CPU cores, 8 GB of memory, and 50 GB of disk.
Tools	Docker Engine 25 or newer with Compose v2, OpenSSL, and `sha256sum` or `shasum`. Source builds also need Git.
Remote access	An SSH tunnel, or a domain and inbound ports 80 and 443 for HTTPS.
Model	Connect one after startup. No model key is needed to install the server.

Choose a cloud server or prepare a Mac mini. The suggested size is a starting point; simultaneous browser tasks and local models need more capacity.

Install a prebuilt bundle

Download a server-<commit> release from the private Nod releases, when one is available. Choose amd64 for Intel or AMD servers, or arm64 for Apple Silicon and ARM servers. The Docker Engine must use Linux containers.

For a revision without a server release, use a successful Self-host bundle workflow run. Workflow artifacts expire after 14 days; approved release assets remain available beyond that window. Both paths check each architecture natively and validate its standalone installer. Keep the downloaded bundle with your backups.

Check the full source commit in the release tag or workflow run before downloading. Download only from authenticated GitHub; the bundle's checksums detect transfer corruption. Repository access is needed on the computer downloading the files. Maintainers can prepare a private server release after approval; this does not make the repository public.

Download the .tar.gz bundle and matching .sha256 file from the server release. If you use a workflow run, download the artifact named nod-server-linux-<architecture>-<commit> and extract its ZIP to get those two files.
Transfer those two files to your server using SCP, SFTP, or your provider's file transfer. On a Mac mini, copy them to the Mac.

Check the archive and unpack it. Replace the placeholders with the downloaded filename.

sha256sum -c nod-server-linux-<architecture>-<commit>.tar.gz.sha256
tar -xzf nod-server-linux-<architecture>-<commit>.tar.gz
cd nod-server-linux-<architecture>
sh install.sh

On macOS, use shasum -a 256 -c instead of sha256sum -c.

If the server is on another computer, first open an SSH tunnel. Open the address printed by the installer and enter NOD_AUTH_TOKEN from the server's private .env. Finish onboarding to connect a model.

The installer checks the bundle and Docker architecture, loads its exact application images, generates private keys, and waits for a healthy stack. Each fresh installation gets its own Compose project name and data volumes. An existing .env keeps its keys, project name, and settings. PostgreSQL and the runtime helpers download from pinned public images, so installation needs internet access. The server needs no Node.js, Git, registry login, or GitHub credentials.

For another independent assistant on the same computer, use a fresh folder and a different PORT for each loopback installation. Run sh setup.sh before editing the new .env. Keep each installation's COMPOSE_PROJECT_NAME unchanged after its first start. Use Restore to move saved data into a new project.

Multiple HTTPS installations on one computer need a shared reverse proxy instead of the bundled HTTPS profile. That profile always uses host ports 80 and 443, regardless of PORT.

To configure a domain before the first start, run sh setup.sh, set NOD_PUBLIC_URL in .env, then run sh install.sh --https. See Add public HTTPS for DNS and firewall setup.

Build from source

Get Nod's source and open the server folder.

git clone https://github.com/n8n-io/nod.git
cd nod/deployment/self-host

Generate the configuration.
Terminal
```
sh setup.sh
```
This creates a private .env with a server token, a Vault encryption key, and a database password. It preserves an existing .env and never prints the secrets. Keep these secrets in .env; unset shell overrides before running setup or Compose.
Build and start the stack.
Terminal
```
docker compose up -d --build --wait
```
The first build downloads dependencies and browser tools. Later starts reuse the images. Keep the terminal open until the command completes.
If the server is on another computer, first open an SSH tunnel. Then open http://localhost:4310 on your computer. For a same-computer install, open that address directly. Copy NOD_AUTH_TOKEN from the server's .env into the access form. Finish onboarding to connect a model.

This option compiles the application and its browser tools on the server. Use a prebuilt bundle to avoid that first build. Neither option needs a separately installed database.

Open a remote server without a domain

On your own computer, open a tunnel to the server:

ssh -L 4310:127.0.0.1:4310 <user>@<server-address>

Keep that connection open and visit http://localhost:4310. Leave NOD_PUBLIC_URL at its local default for this setup. The token is still required.

To use another port, change PORT in .env and use that port in the tunnel and browser address. The default NOD_PUBLIC_URL follows PORT.

Add public HTTPS

Point a domain, such as nod.example.com, at your server's public address. Allow inbound TCP 80 and 443.
Edit the server's .env:
.env
```
NOD_PUBLIC_URL=https://nod.example.com
```
Start the HTTPS profile. For a bundle, run:
Bundle installation
```
sh install.sh --https
```
For a source checkout, run:
Terminal
```
docker compose --profile https up -d --build --wait
```
Open your HTTPS address and enter the server token.

Caddy obtains and renews the certificate. This profile accepts a DNS or IPv4 host with HTTPS on port 443. Use an existing proxy for a different HTTPS port or an IPv6 URL. Keep using --profile https when you operate this installation. If certificate setup fails, check DNS and whether the provider or router blocks ports 80 or 443.

The public URL must be an origin: scheme, hostname, and optional port. Paths, query strings, fragments, and embedded credentials are refused.

Use an existing proxy

You can use your own HTTPS reverse proxy instead of the HTTPS profile, including an origin with a custom port such as https://nod.example.com:8443. Forward requests to the stack's loopback port 4310, or the port you set in PORT.

Preserve the public Host header and support WebSockets and streaming responses. Set NOD_PUBLIC_URL to that exact HTTPS origin. Nod does not trust forwarded headers to decide which origin is allowed.

Keep the backend port private. Never expose PostgreSQL, the browser, the workspace, or the Docker connection.

Nod allows five minutes to receive a request body. This does not limit the duration of assistant responses or event streams. Configure your proxy's request limits to suit your connection and expected uploads.

Connect the desktop app

Open Server connection in the Nod app menu or tray. On first launch, you can also choose Connect to a server. Enter the server address and the value of NOD_AUTH_TOKEN.

Use the HTTPS address, or http://localhost:4310 while your SSH tunnel is open. The app uses the server's conversation, files, models, and connected accounts. Closing the app does not stop the server.

The app verifies the server before saving the token in your operating system's secure storage. It restarts into the remote assistant without starting a local runtime. The server owns the Composio identity and connected accounts, so another device reaches the same assistant without reconnecting those accounts.

The app's local assistant is separate. Connecting does not migrate its data. To return to it, open Server connection and choose Use this computer.

Model and app connections run on the server too. Use addresses the server can reach; localhost inside a Docker installation refers to its server container, not the device running the client. For ChatGPT subscription sign-in, follow the remote callback instructions.

Connect Telegram or WhatsApp

Open Channels in Nod and follow Telegram and WhatsApp. Leave that channel's environment variables blank or unset to configure it in the app. Both share the server's assistant.

Telegram polling and the WhatsApp QR connection need outbound internet access. They can work without a public domain.
Telegram webhooks and Meta's WhatsApp Cloud API need a public HTTPS address.
Private sign-in and payment steps stay in Nod's web or desktop app.

For environment-managed channels, see the configuration reference.

What runs on the server

flowchart LR
  client[Web or desktop app]:::accent --> proxy[HTTPS proxy]
  proxy --> server[Nod server]:::accent
  channels[Telegram or WhatsApp] --> server
  server --> db[(PostgreSQL)]
  server --> runtime[Restricted Docker connection]
  runtime --> workspace[Workspace container]
  runtime --> browser[Browser container]

The database, workspace, and browser stay private. Model keys and saved credentials stay with the server, outside the workspace and browser containers.

The stack uses named volumes for its persistent data. Recreating a container keeps those volumes. Deleting the volumes removes your data.

Keep it running

The containers restart when Docker starts. On a Mac, Docker Desktop starts after you sign in when its startup setting is enabled.

Follow Back up and update a server before your first update. Keep the Vault key with your backup; the database alone cannot recover saved credentials.