Security

The appliance runs on hardware and in a network that you operate. IronFlock provides the software and its defaults; how well the appliance is protected also depends on the mode you choose, the network around it and the host it runs on. This page is the checklist for that part.

What Each Mode Protects

The appliance runs in one of three modes, described in HTTPS & Certificates. They differ in what is encrypted and verified:

Use HTTPS with your corporate certificate wherever the appliance shares a network with other systems. It is the only mode in which connected devices verify whom they talk to. The other two modes are suited to a network segment that only the appliance, its devices and its operators can reach.

What Stays Unencrypted

Even with HTTPS, some traffic is not encrypted. Plan your network around it:

• The device link on port 18080 is published on every network interface in every mode. The appliance’s own device agent and the apps running on the appliance connect to it, and in plain mode and with a self-issued CA so do all connected devices.
• Remote-access tunnels to the appliance (port 7000) are encrypted in plain mode and with a self-issued CA, but devices cannot check the appliance’s certificate. Someone with access to the network path could pose as the appliance’s tunnel server. Device agents log a warning when they connect this way.
• Connections between the services inside the appliance, such as to its databases, are not encrypted. They do not leave the host.
• Data at rest is not encrypted by the appliance. Use the encryption of the host’s operating system or disk if the appliance stores sensitive data or may leave your premises.

Hardening Checklist

• Choose the mode that fits your network (see What Each Mode Protects).
• Restrict who can reach the appliance’s ports. The installer opens nothing in your firewall, and Docker publishes the appliance’s ports past the host firewall’s usual input rules (ufw, firewalld). Filter in the DOCKER-USER chain or at your network firewall: the installer leaves a template at /opt/ironflock/docker-user-firewall.sh.example. Allow the device ports (18080, 15001, 15002, 7000, 30000–30049) only from your device networks — see Devices Connecting to the Appliance.
• Keep the host’s operating system up to date and limit who has an account on it. Anyone with root access on the host can read every secret of the appliance.
• Use SSH keys instead of passwords for administrative access to the host.
• Configure time synchronization — see Time Synchronization (NTP).
• Change the admin password after the first login and set up a second factor for the admin account.
• Require a second factor for everyone once all accounts have one (see Accounts and Access).
• Protect the ironflock.com account that owns the instance with a second factor: it has admin access to the appliance from the cloud.
• Install only apps you trust. Apps run on the appliance and on your devices with extensive access to the host, including the appliance’s configuration files.
• Keep the appliance updated (see Updates).

Accounts and Access

• Admin account: every appliance gets its own admin password at installation; the installer shows it once. If it is lost, set a new one as described in Local Operation — this also signs out every admin session.
• New users can only sign up with an invitation from a project on the appliance. Without an invitation, sign-up is refused, also through social login.
• Second factor: users can set up an authenticator app (TOTP), passkeys or security keys, and recovery codes. Passkeys and security keys need HTTPS. The installer option --2fa sets the policy, and it stays set across updates:
  • available — users can set up a second factor, but are never asked for it.
  • effective (default) — users who have a second factor must use it.
  • required — every user must use a second factor. Make sure every account has one first: a user without one can no longer sign in.
• Sessions last 24 hours.
• Access from ironflock.com: the ironflock.com account that created the instance key is connected to the appliance’s admin account. Users you invite connect their own ironflock.com accounts — see Linking Accounts. A user can remove that connection at any time.

Secrets on the Host

The installer generates the appliance’s secrets once, at installation, and keeps them across updates. They live under /opt/ironflock/:

The installer also signs Docker in to the IronFlock registry with your license key, so root’s Docker configuration holds it as well.

Include these files in your backups and protect the backups like the appliance itself.

What you can replace yourself:

• Admin password: in the profile, or with the reset command in Local Operation.
• HTTPS certificate: replace the files in certs/; the appliance picks up the new certificate automatically.
• License key: in the license section of the admin profile.
• SMTP and proxy credentials: in .env, then restart with sudo systemctl restart ironflock.service.

For the internal service secrets, contact the IronFlock team.

Outbound Connections and Telemetry

The destinations the appliance connects to are listed in Firewall Configuration; all of these connections are encrypted.

• License validation sends the license key, a fingerprint of the hardware and the access tokens of the appliance’s connections to the online App Store.
• The AI assistant sends prompts through IronFlock’s LLM gateway, unless you configure a gateway of your own.
• No telemetry. The appliance sends no usage analytics: neither the appliance UI nor its services report usage to IronFlock or third parties.
• From the user’s browser: map tiles are loaded from Mapbox, and voice input uses the speech recognition service Deepgram. These connections are made by the browser, not by the appliance.

Updates

• Appliance updates are started by the admin (see Maintenance). The appliance downloads them over HTTPS and rolls back automatically if an update fails.
• Device agent updates are signed. Every agent checks the signature before it applies an update and rolls back if the new version does not start — see Device Agent Updates.
• The host’s operating system is your responsibility, including Docker.

Backup and Restore

The appliance has no built-in backup. To back it up, stop it with sudo systemctl stop ironflock.service and copy:

• the folder /opt/ironflock/, including .env, license.env, certs/ and registry-token-certs/;
• the Docker volumes of the appliance (docker volume ls), which hold the databases, files, the local App Store and the user files.

Keep .env together with the volumes of the same point in time: the encrypted data in the volumes can only be read with the keys in that .env.

Decommissioning

1. Move or release the license while the appliance is still online — see Moving Your License to New Hardware.

2. Remove the software:

   sudo systemctl disable --now ironflock.service
   sudo docker compose -f /opt/ironflock/docker-compose.yml \
       --env-file /opt/ironflock/.env down -v
   sudo rm -rf /opt/ironflock

   The installer signed Docker in to the IronFlock registry with the license key; remove that login too:

   sudo docker logout instance-registry.ironflock.com

3. If the hardware leaves your premises, erase its disk — the commands above delete files, but do not overwrite them.

Settings That Weaken Security

Some settings exist for troubleshooting only. Leave them unset in production:

• TUNNEL_TLS_INSECURE_SKIP_VERIFY and CLOUD_TUNNEL_TLS_INSECURE_SKIP_VERIFY — turn off the certificate check of remote-access tunnels.
• AGENT_UPDATE_ALLOW_UNSIGNED — lets a device agent apply unsigned updates.
• TUNNEL_AUTHZ_ENFORCE=false — lets devices open tunnels without proving their identity.
• ?tls.rejectUnauthorized=false in SMTP_CONNECTION_URI — accepts any certificate from your mail server.
• --2fa available — second factors are never asked for.