How to Secure Project NOMAD on a Shared Network

To secure Project NOMAD on a shared network, you control who can reach it, because the software has no login of its own. Project NOMAD is a free, open-source offline server for libraries, learning tools, maps and optional local AI. We explain the whole package in What Is Project NOMAD?.

This piece answers one question: how to run that box safely in a school, library, office or field kit on a shared network. It covers authentication, open ports, a Docker firewall issue, adding a login, the AI assistant, updates, backups and physical security. If you are still choosing a machine, start with Project NOMAD hardware and storage.

The short version: anyone who can reach a NOMAD box can use all of it, including settings and app installs. Keep it off the internet. Put a public-facing kit on its own Wi-Fi network or VLAN. Do not count on Ubuntu’s ufw firewall to block its ports. A reverse proxy with a password can protect the Command Center, but not every app. Treat uploaded documents as readable by anyone on that network.

What the project says about authentication

The project is open about this. Under "About Security," its README on GitHub says that "By design, Project NOMAD is intended to be open and available without hurdles," and that "it includes no authentication."

The README’s advice: "For now, we recommend using network-level controls to manage access if you’re planning to expose your NOMAD instance to other devices on a local network." It also says "NOMAD is not designed to be exposed directly to the internet" and advises against it.

The project’s security policy lists the missing login and internet exposure as out of scope for vulnerability reports. It states that "Local network access is the trust boundary by design." In plain terms, anyone on the same network is trusted.

Asked whether authentication will be added, the README answers "Maybe." As of November 1, 2026, the latest stable release is v1.35.1 from October 5, per the project’s releases page. It adds no login.

Which ports a NOMAD box opens

To secure Project NOMAD, first know what it opens. The Command Center runs on port 8080. The install script’s Docker Compose template also publishes port 9999 for Dozzle, a log viewer. MySQL and Redis publish no ports.

Each app you install from the Supply Depot opens its own port. These come from the service catalog in the project’s source code, as of November 2026:

Two rows stand out. Qdrant’s security documentation says self-deployed instances "are open to all network interfaces and do not have any kind of authentication configured." Dozzle’s docs warn that Docker socket access, unless restricted, is "equivalent to root on the host." NOMAD turns off Dozzle’s container actions and shell, but anyone on the network can read the logs.

Why Docker can bypass ufw on a NOMAD box

The obvious fix is to turn on ufw and block these ports. On a Docker host, that does not work. Docker’s packet filtering and firewalls page says "Docker and ufw use firewall rules in ways that make them incompatible with each other."

The page explains: "When you publish a container’s ports using Docker, traffic to and from that container gets diverted before it goes through the ufw firewall settings." In Docker’s words, packets are routed "before the firewall rules can be applied, effectively ignoring your firewall configuration."

Docker’s port publishing guide adds that "Publishing container ports is insecure by default." NOMAD publishes every port in the table without a bind address. Each one listens on every network the box joins.

So a sudo ufw deny 8090 rule can show in ufw status and still leave Kiwix open. Use ufw for services outside Docker, such as SSH. Block NOMAD’s ports at the router instead. More on how containers use the network is in our post on containers, Docker and Kubernetes.

Keep it on the local network to secure Project NOMAD

The first rule to secure Project NOMAD is that it never faces the internet. Do not forward ports to it on the router or put it in a DMZ. Staff who need remote access should use a VPN.

For a kit the public will use, give NOMAD its own network:

• A separate Wi-Fi network or VLAN with only the NOMAD box and visitor devices.
• Router or access point rules that block traffic between that network and your main one. Port blocking works here, before traffic reaches the Docker host.
• No internet route on the visitor network if you do not need one. The README says NOMAD needs internet only for installation and for downloading new content.

On the box itself, Ubuntu’s firewall documentation notes that ufw "by default is initially disabled." Turn it on to protect SSH. For example, run sudo ufw allow proto tcp from 192.168.0.0/24 to any port 22 for your admin subnet, then sudo ufw enable. See our firewall basics post.

Adding a login with a reverse proxy

If only staff should use a box, a reverse proxy with a password can help secure Project NOMAD’s Command Center. Caddy’s basic_auth directive and nginx’s auth_basic module both do this. Caddy requires hashed passwords. Nginx reads them from a password file.

It helps, with limits:

• It only guards traffic that goes through it. Bind port 8080 to 127.0.0.1 in compose.yml so only the proxy reaches it. The NOMAD FAQ says core service ports can be changed, but installed app ports cannot yet. Kiwix, Ollama and the rest stay open.
• It needs HTTPS. Caddy’s docs say “basic auth is not secure over plain HTTP.” On a LAN, that means managing a certificate.
• Everyone shares one login. There are no roles.
• Re-check after updates. The current update script reuses your compose.yml, but confirm the binding after major versions.

For public kits, network separation does more.

The AI assistant and uploaded documents on a shared box

The AI chat runs on the box. The README says NOMAD "has ZERO built-in telemetry," so prompts stay local unless you connect a remote AI server.

The bigger risk is the Knowledge Base, where you upload documents for the AI to search. NOMAD’s Supply Depot guide says uploads sit in a kb_uploads folder that File Browser can open. Their searchable copies sit in Qdrant, which has no API key in NOMAD’s setup. With no user accounts, every upload is open to anyone using that box.

Upload only material you would put on a public shelf: manuals, curriculum, local guides. Keep student records, HR files and donor data off a shared box. Our post on local AI agent security covers other risks of self-hosted models.

To run the model on a second machine, the README says that host must start Ollama with OLLAMA_HOST=0.0.0.0. That opens the second machine to the network too. We explain the runtime in What Is Ollama?.

Updates that keep a secure Project NOMAD box current

The security policy says "Only the latest released version of Project NOMAD receives security fixes." Updating is part of how you secure Project NOMAD.

NOMAD’s update guide says automatic updates are "opt-in and off by default." Turn them on under Settings, then Updates. Core software takes only minor and patch releases. They install inside hours you set, after a cool-off period, and only if pre-flight checks pass. Major versions always need a manual update. Apps also need a per-app toggle on their Supply Depot card.

The update_nomad.sh script in /opt/project-nomad pulls new images for the Command Center only. Update apps from the Command Center.

For the OS, Ubuntu’s automatic updates guide says unattended-upgrades is installed by default. It applies security updates "without user interaction." An offline field kit gets none of this until it reconnects, so schedule online time.

The README’s contributor section describes a dry run, node ace auto-update:dry-run, that shows whether NOMAD would update. "No real update is ever requested." Ubuntu offers sudo unattended-upgrade -v --dry-run for the OS.

Backing up notes, uploads and settings

NOMAD’s docs do not describe backups, so this is our suggestion based on where files live. The service catalog stores app data under /opt/project-nomad/storage by default. The compose file keeps MySQL in /opt/project-nomad/mysql.

Library files and AI models can be downloaded again, so back up flatnotes, kb_uploads, kolibri-gen2 and filebrowser under storage, plus the MySQL folder. Stop NOMAD with stop_nomad.sh before copying the database.

Encrypt the backup if it holds uploads. The install script deletes /opt/project-nomad/mysql when it runs. Reinstalling over an old box wipes its database. Our backup strategy basics cover where to keep copies.

Physical security for a portable kit

To secure Project NOMAD in a field kit, plan for theft. Whoever holds the drive has every file. Ubuntu’s security documentation says encrypted LVM "allows you to encrypt all partitions in the logical volume, including swap." Choose it at install, and plan who types the passphrase at boot.

Give the kit an asset tag and track it, as in our IT asset management basics. Keep the box where staff can see it.

A checklist to secure Project NOMAD on a shared network

1. No port forwarding or DMZ. Remote staff use a VPN.
2. Public kits get their own Wi-Fi network or VLAN, blocked from staff networks at the router.
3. Turn on ufw for SSH. Do not rely on it for NOMAD’s Docker ports.
4. Change the File Browser and Calibre-Web passwords on day one.
5. Turn off open sign-ups in Vaultwarden and Homebox if installed.
6. Add a reverse proxy with HTTPS and a password if only staff should reach the Command Center.
7. Upload only public material to the Knowledge Base.
8. Turn on NOMAD auto updates and Ubuntu security updates. Schedule online time for field kits.
9. Back up notes, uploads, Kolibri data and MySQL, encrypted.
10. Encrypt the disk at install and tag the hardware.

Frequently Asked Questions