Start

Install on your server

You were emailed a personal installation link. On your own Linux server, one command sets up everything — the assistant, its database, and its automatic updates. There is nothing to configure and no keys to enter. This page covers the whole lifecycle: sizing, the install itself, going live on a domain, updates and backups, moving house, and what a broken first attempt looks like.

Before you start

• A Linux server — Ubuntu 22.04+ or Debian 12+ recommended, with a normal systemd and nothing already bound to ports 80 and 443 (see Ports & network).
• 4 GB RAM and a few GB of free disk as a floor, for a light corpus and a handful of people. Give it more of both the more you connect: the database, the document store and the automatic backups described below all grow with the material you feed it, so a deployment meant to hold a large document library or serve a large team is safer with meaningfully more headroom on both.
• Root access — the command runs as root (sudo) because it installs Docker and writes into /opt.
• Outbound HTTPS to naxistechnologies.com — the assistant checks in to stay licensed, fetches its own updates, and files support tickets through this address. It also needs outbound HTTPS to ghcr.io, the registry the assistant image is pulled from, at install time and again every time it updates. Neither needs an inbound hole in your firewall — only outbound.
• Docker is installed automatically if it isn’t already present.

Install

Open the link from your email — it shows your exact command, personal to this deployment and carrying its licence. Run it on the server as root:

curl -fsSL https://naxistechnologies.com/install/<your-link> | sudo bash

It takes a few minutes the first time (it downloads the assistant). Under the hood it, in order:

1. Installs Docker if the server doesn’t have it already, and confirms the compose plugin is present.
2. Signs in to the Naxis image registry with a read-only credential baked into your link — nothing to type.
3. Lays out /opt/naxis on the server: the compose file, the update helper, and a generated .env that carries this deployment’s identity and a freshly generated database password.
4. Writes the reverse-proxy configuration — plain HTTP on port 80 if you gave it no domain, or your domain with automatic HTTPS if you did (see Give it a proper web address).
5. Pulls and starts the stack, then waits — up to five minutes — for the assistant to answer its own health check before declaring success.
6. Prints the address to open and the one-time link that creates your administrator account.

Ports & network

The installer brings up a small reverse proxy in front of the assistant that listens on ports 80 and 443 on the server, so those two ports need to be free before you run it — stop or reconfigure anything else already bound to them first. Everything else (the database, the background worker, the update helper) talks only to the assistant over a private network inside Docker; nothing else needs to be opened.

Verifying it worked

The installer only prints success once its own health check passes, but you can check it again yourself at any time, on the server:

curl -fsS http://127.0.0.1/healthz
# {"ok": true}

cd /opt/naxis
docker compose ps                 # every service should read "running (healthy)" or "running"
docker compose logs -f app        # tail the assistant's own log
docker compose logs -f updater    # tail the update helper — updates and their outcome show here

The most useful single check after that is opening the address in a browser and getting the administrator setup screen — the health check confirms the assistant and its database are up, not that the page in front of a browser is reachable from wherever you’re sitting.

First run

1. Open the address the installer printed, in a browser.
2. Create your administrator account. The first person to open a fresh install becomes its admin.
3. Follow the setup wizard — set your organisation name, connect your first content source, and invite your team. See Using the assistant.

Give it a proper web address

Without a domain, the assistant is reachable at your server’s IP over plain HTTP — fine for a first look, not for daily use. For a stable, secure address:

1. Point a domain (an A record) at your server’s IP address.
2. Re-run the install command. The reverse proxy in front of the assistant obtains a free HTTPS certificate for that domain automatically, the first time it’s asked for it over HTTPS.
3. In the assistant, open Settings and set your public address to the same domain, so links in emails and channels point to the right place.

What got installed

Everything lives under /opt/naxis on the server and runs in Docker, as five services on their own private network:

You never touch these directly. Day-to-day, you only use the assistant in your browser.

The update window

A self-hosted deployment updates itself the same way a managed one does. When Naxis publishes a new version, this deployment learns of it at its next check-in and the admin console announces it. Unless you choose otherwise, it installs by itself on the coming Sunday at 02:00, in the server’s own local time.

1. Open Settings — the software-update card only appears when a release is actually waiting.
2. Update now installs it within a minute or two, or pick a specific time — you can always move it earlier, never later than the deadline it shows.
3. Behind the scenes: the update helper takes a database backup first — the update is refused if the backup can’t be taken — then starts the new version and waits for it to pass its own health check. Healthy, and the update is done, usually a minute or two of downtime. Not healthy within five minutes, and the previous version is put back automatically; your data is untouched either way.

Backups

Every update takes a fresh database backup first, automatically, into /opt/naxis — the last few are kept and older ones age out on their own, so disk use stays flat. A backup holds your database — your documents, their access rules, your accounts and conversation history; the connected sources themselves are read again on the next sync, they aren’t stored a second time inside the backup.

To restore one by hand, from the server:

cd /opt/naxis
gunzip -c /path/to/paia-<timestamp>.sql.gz | docker compose exec -T db psql -U paia paia

Moving to another server

Because the licence link identifies your deployment, not a machine, the same command that installed it also moves it:

1. On the new server, run the same install command from your original email. It sets up an empty stack under a freshly generated database password.
2. Copy your most recent backup (above) to the new server and restore it, exactly as you would to recover from a failed update.
3. Point the domain’s A record at the new server’s IP, then re-run the install command once more so the certificate reissues for the new address.
4. Decommission the old server once you’ve confirmed the new one answers.

How a first install goes wrong

The installer never leaves a half-running stack — it either finishes or stops with a plain reason. The three that actually come up:

Re-running the installer

The command is safe to run again — it re-applies the setup in place and never touches your data or your account. Use it to move to a new domain, to recover from any of the failures above once the underlying problem is fixed, or if support asks you to.

Removing it

Everything the assistant runs and stores lives under /opt/naxis. To take the stack down, keeping your data on disk in case you want it back:

cd /opt/naxis
docker compose down

To remove it completely, including the database and every document — this cannot be undone unless you kept a backup elsewhere:

cd /opt/naxis
docker compose down -v
rm -rf /opt/naxis

Open a ticket from Help in the assistant before you take it down, or contact your Naxis representative, to formally close out the licence on your end once the server is gone.

Next: Using the assistant →

Last updated 3 Sep 2026