Update, backup & reset

Updating Node64 is a plain image swap – the database catches up automatically. For emergencies there's a full, encrypted backup that you can restore even on a brand-new machine.

Updating

Node64 doesn't update itself. You pull the new image and recreate the container – your data in the /data volume stays put.

With docker compose

docker compose pull && docker compose up -d

With docker run

Pull the new image, remove the old container and start it again with the same command you used to install:

docker pull ghcr.io/ipv64net/node64:latest
docker stop node64 && docker rm node64
docker run -d --name node64 \
  -p 8080:8080 \
  -v node64-data:/data \
  --restart unless-stopped \
  ghcr.io/ipv64net/node64:latest

Versions and image tags

The image is available for linux/amd64, linux/arm64 and linux/arm/v7 (Raspberry Pi, 32-bit too). Every version is tested automatically before it is built.

If you want to control updates deliberately, use a fixed series or version instead of latest and raise it by hand. GET /api/health shows which version is running. The version numbers in the table are examples.

What happens on the first start after an update

• Migrations run automatically. The database is brought up to date area by area (core, notifications, certificates, modules …).
• A backup comes first. Before every migration Node64 automatically writes a backup to /data/backups. The last 5 are kept.
• Module versions: each module has its own version and a changelog in English and German – see Settings → Modules.

Backup options at a glance

Backup, export, restore, data retention and reset are all under Settings → Data & backup.

Downloading a full backup

1. Open Settings → Data & backup and go to the Backup and restore card.
2. Under Full backup (encrypted with a password), choose a password with at least 8 characters.
3. Optional: tick Include statistics to add the DNS64 query log and PROXY64 access data. This makes the backup larger.
4. Click Download backup. You'll get a file like node64-20261019-1504.n64backup.

Included: the database with all tables of all modules – including honeypot events and Proxmox history –, copied consistently while running; the node's key (secret.key, needed for the API key, credentials and certificates) and the module files under /data, such as the DNS64 allowlist and certificates, the Honeypot64 host keys, certificate and sensor ID and the web interface certificate. Not included: caches the node fetches again (blocklists, country data), the automatic backups in /data/backups and temporary files.

Via the API, e.g. for a nightly script

curl -X POST http://localhost:8080/api/backup \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"password": "YOUR_BACKUP_PASSWORD", "stats": false}' \
  -o node64-$(date +%Y%m%d).n64backup

Create an API key in the node under API – see Local API.

Backing up the database only

Backup and configuration also offers Download only the database (node64-YYYYMMDD-HHMM.db), or via the API with GET /api/backup:

curl -H "Authorization: Bearer YOUR_API_KEY" -o node64.db http://localhost:8080/api/backup

This file does not contain secret.key. It is fully usable on the same node. On a fresh installation, the encrypted secrets inside it (channel tokens, SMTP passwords, ipv64 API key, certificate keys) can't be read without the old key.

Important: back up /data/secret.key too

Backing up the whole volume

Independently of the interface, you can archive the complete volume. To make sure the SQLite databases are in a clean state, stop the container briefly:

docker stop node64
docker run --rm -v node64-data:/data -v $(pwd):/backup alpine \
  tar czf /backup/node64-data-$(date +%Y%m%d).tar.gz -C /data .
docker start node64

Restoring into an (empty) volume:

docker stop node64
docker run --rm -v node64-data:/data -v $(pwd):/backup alpine \
  tar xzf /backup/node64-data-20261019.tar.gz -C /data
docker start node64

Restoring a backup

1. Open Settings → Data & backup → Restore backup.
2. Pick the file: a .n64backup (with password) or a .db database (no password). Node64 detects the type itself and validates the file first.
3. Confirm the prompt. The current data is replaced and the node restarts.
4. After a few seconds, log in again – with the credentials from the backup.

Whatever was replaced is kept in /data/backups – the last five copies per kind; Node64 cleans up older ones itself. The last five backups made before each migration are kept there too. For the restart to work, the container must run with restart: unless-stopped (or --restart unless-stopped) – Node64 exits on its own after restoring, and Docker starts it again.

Moving to a new machine

1. Install Node64 on the new machine.
2. Run through the setup wizard with a temporary account.
3. Restore the full backup (.n64backup) with its password. After the restart, the data, key and user from the backup are in place.

Via the API

curl -X POST http://localhost:8080/api/backup/restore \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F file=@node64-20261019.n64backup \
  -F password=YOUR_BACKUP_PASSWORD

Alternatively, send the file as the raw request body and the password in the X-Backup-Password header.

Exporting and importing the configuration

The export is not a backup but a JSON file with your configuration: node settings (name, location, time zone, quiet hours, data retention, the AI interface switch), channels, certificates (only with a password) and, for each enabled module, its configuration – no measurements. Perfect for setting up a second node the same way.

• Export under Settings → Data & backup → Export and import configuration: either without secrets (tokens, passwords) or with secrets encrypted with a password (at least 8 characters).
• Import under Import configuration: checks are matched by token, channels and maintenance windows by name, status pages by slug. Nothing is deleted. Modules that are needed get enabled. If the password doesn't match, nothing is applied.
• DynDNS: the export contains no tokens; on import the node fetches them again using the ipv64 API key.
• Health checks: checks including group and where they run (nodes), maintenance windows and channel assignments; after the import, checks point to the channels imported along with them on the new node. Plus the Proxmox systems, the Docker hosts and the status pages with entries and logo; the password hash of a protected page only in an export with a password, otherwise it arrives switched off. Announcements stay on the node.
• DNS64: settings, allowlist, custom records, local zones, forwards, rewrites, the selected certificate and the device groups (members, rules, allowed/blocked domains, schedules – without the state of the Block/Free buttons) are included. Groups with the same name on the target node are kept.
• PROXY64: proxy hosts, redirects, 404 hosts, streams, access lists, blocklist, limit and log settings and the honeypot switches (baits, requests to the log sensor, instant block with duration); fixed certificates are matched by their names. The block list itself stays on the node. Hosts of the “status page” kind are matched by the page's slug; if it doesn't exist on the target node, the host is created switched off.
• Honeypot64: services, log sensor and syslog.
• Certificates: only in an export with a password – certificates with keys, DNS credentials, your own CAs and ACME authorities as an encrypted block. On import, the modules' references (DNS64, PROXY64) are switched to the new certificates. Without a password the block is left out.
• Not included: measurements, history and logs, users, sessions, API and MCP keys, passkeys, SSO, the common entrance (80/443), the early-warning networks (kept at ipv64) and CDN64 (belongs to the node).
• API: POST /api/export and POST /api/import.

Data retention

How long the node keeps data locally is set under Settings → Data & backup → Data retention (local):

Honeypot64 (retention and maximum number of events), DNS64 (query log), PROXY64 (access log, hourly statistics 90 days) and DynDNS (history) have their own settings in their modules. Via the API: GET and PUT /api/retention, for the audit log the field audit_days (0 = unlimited).

Resetting the node (factory reset)

Settings → Data & backup → Reset node returns the node to its factory state. You enter your password and confirm a prompt.

• First, the node signs off online: the link with ipv64 is removed, CDN64 names and the tunnel are removed at ipv64 (even if PROXY64 is currently switched off), and the node leaves the cluster. If something fails (e.g. without internet), the reset continues anyway; the problems are listed in the audit log.
• After the restart /data is empty: the database with all tables (checks, measurements, channels, users, settings …), keys, certificates, module files such as the honeypot keys and sensor ID, caches and backups are gone. An automated test makes sure the reset really deletes everything.
• Setup starts again with the wizard.
• Your own certificate (NODE64_TLS_CERT/NODE64_TLS_KEY) under /data is kept. Your own mounts below /data are emptied, not removed.
• Before deleting the container, a reset is worth it: without signing off, ipv64 only removes orphaned CDN64 tunnels after 14 days.
• Via the API: POST /api/reset – only with the user's password in the request, even when signed in with an API key.

Something unclear, missing, or a question about Node64? Ask in the official forum v64.tech.