Hey folks, I’ve been tinkering with getting SuperAGI running on a Raspberry Pi 4 (8GB) for a local-only project, and I wanted to share my approach and ask a few questions about the security side. My main goal was to run it entirely offline, blocking all external network access at the firewall level, because the idea of an open web UI and marketplace plugins pulling from the internet on my home network felt… risky.
I used the default docker-compose setup from their GitHub, but before bringing the containers up, I set up nftables on the host to drop all outgoing and incoming traffic except for loopback and established connections. This way, even if SuperAGI’s components try to phone home or fetch a plugin, they can’t. The UI is accessible only from the Pi’s own browser via localhost.
My main curiosity is about what’s *still* exposed internally that I might have missed. For example:
- The web UI (port 3000 by default) is now local-only, but does it have any built-in authentication? The default install didn’t seem to.
- The marketplace and toolkit configurations are in the YAML files. If those point to external URLs, they’ll fail now, which is fine. But are there any default scripts or agents that try to write to disk or spawn processes in an unsafe way?
- I’m using the default SQLite for the agent memory backend. Since it’s just files on the container volume, that seems okay for isolation, but I wonder if there’s any risk of container escape from the SuperAGI code that I should harden against. Maybe apparmor or seccomp profiles?
Also, has anyone looked at the systemd services for keeping this running on a Pi? I made a simple service to start the docker-compose stack, but I’m not sure if I should be dropping capabilities or setting a read-only root filesystem for the containers. I’m still learning runtime security, so any tips on using auditd or eBPF to watch for unexpected syscalls from these containers would be awesome 😅.
That's a great setup, and I'm doing something similar with my own projects. Your question about the web UI lacking default authentication is a big one. Even on localhost, if another piece of malware somehow gets a foothold on the Pi, it could potentially interact with that unauthenticated API.
Have you looked at putting something like Authelia or a simple nginx reverse proxy with basic auth in front of the UI? It adds a step, but for a service meant to be offline anyway, that local login prompt could be a worthwhile last line of defense.
What about the internal container network? Your nftables are on the host, but the containers can still talk to each other. Did you review the default docker-compose network rules to see if any service is unnecessarily exposed to the others?
Trust no one, verify every packet.
Blocking egress is smart. But you're right to worry about that unauthenticated localhost port.
Check the container images for any baked-in TLS keys or certificates. If they were built expecting to talk to an external service, they might still have the private material sitting there, unused but readable. That's a waste, but more importantly, it's a sign of how they think about secrets.
If you find any, rotate them immediately, even in an offline setup. Old keys are a liability if the system ever gets connected by mistake.
What's your plan for credential storage inside the project? Does it just use plaintext in the config files?
Your approach to network isolation is sound, but your question about what remains exposed internally is the critical one. Even with egress blocked, the attack surface within the container network is substantial.
Focusing on the web UI port is correct, but you must also examine the artifact supply chain that built your running containers. An offline deployment relies entirely on the integrity of the images you pulled before disconnecting. Did you generate an SBOM for each image to verify its constituent libraries and their versions? A vulnerability in a dependency within your isolated network is just as exploitable. I would recommend using a tool like `syft` on the images you downloaded to create a baseline bill of materials; this is your only map of what you're actually running.
your statement that "if those point to external URLs, they'll fail now, which is fine" is potentially dangerous. Failure modes can be unpredictable. A script configured with an external URL might hang, crash, or fall back to a hard-coded default behavior that could be undesirable. You need to audit those YAML files and any default Python scripts in the toolkit for such fallback logic. The safest method is to remove or comment out any configuration stanza that references an external resource you cannot allow.
Trust but verify the build.