Upgrading from v1

Back up

Stop the v1 server and copy its data and config:

docker compose down
sudo cp -a /opt/netignite /opt/netignite-v1-backup

Start v2 next to the v1 data

Change the image to v2 and add NETIGNITE_APP_URL with the address users open the dashboard at. Keep the volumes:

services:
  netignite-server:
    image: ghcr.io/netignite-project/server:latest
    container_name: netignite-server
    restart: unless-stopped
    ports:
      - "18232:18232"
    environment:
      NETIGNITE_APP_URL: https://netignite.example.com
    volumes:
      - /opt/netignite/data:/opt/netignite/data
      - /opt/netignite/config:/opt/netignite/config

docker compose pull
docker compose up -d

v2 creates its own database data/netignite.sqlite next to the v1 data/db.sqlite, and a new admin with a password link. Don't use the link yet if you want the v1 admin password to carry over.

If you use a reverse proxy, check that it forwards WebSockets on /ws/agent and /ws/console (v1 only needed /api/agent-control-service). See HTTPS & Reverse Proxy.

Try the import

A dry run imports everything inside a transaction and rolls it back, so nothing changes:

docker exec netignite-server bun /opt/netignite/app/.output/import-v1.mjs \
  --from /opt/netignite/data/db.sqlite --dry-run

Dry run — nothing was changed.

Users imported: 2
Users merged:   admin
Agents imported: 2
Devices imported: 5
Favorites imported: 3
Imported users got a placeholder email (…@imported.netignite.invalid) and are asked to change it after logging in.

Users whose username already exists in v2 (other than admin) are skipped: skipped user alice: username already exists in v2 (use --merge-users to merge them). With --merge-users, such a v1 user is merged into the existing v2 user instead; the v2 user takes over the v1 password only if nobody has logged in to it in v2 yet.

Import

docker exec netignite-server bun /opt/netignite/app/.output/import-v1.mjs \
  --from /opt/netignite/data/db.sqlite

The import uses the container's NETIGNITE_* settings and writes to the running server's database. Running it again is safe: records that were already imported are skipped. When the admin takes over the v1 password, the import deletes config/initial_admin_password_reset_token.txt.

Running the server from source? Run the import from the repository root: bun scripts/import-v1.ts --from <path to db.sqlite> [--dry-run] [--merge-users].

Log in

Log in as admin with the v1 password (or, if you set a v2 password with the link before the import, with that one). Every user gets the welcome page at the first login; ask your users to enter their real email address under Settings → General.

Set up the agents again

Open Agents. The imported agents show Not set up; their devices still point at them.

• ESP32 boards need the v2 firmware once over USB: open the agent's Install tab and follow the web installer. v2 uses a new partition table with two firmware slots, so it can't be installed over the network on a v1 board. After that, updates come over the network. Your old config.h isn't needed anymore: the installer sets the server and the Wi-Fi.
• Server agents (your own v1 agents) don't work with v2: the protocol changed. Install the Linux agent on the machine instead (turn on Wake-on-LAN mode to wake other devices), or update your agent to protocol v2.

As each agent comes online, its devices can be woken again.

Check the devices

The imported devices keep the v1 status check, which doesn't work for most Windows and many Linux machines. Open each device and choose a better status check, for example its IPv4 address. While you're there, consider sharing, shutdown through the Linux agent or over SSH.