Skip to content

Operations

This page covers the security model, service management, backups, upgrades and support for Nanobot AI Agent.

Security model

  • The web UI and gateway listen only on 127.0.0.1. Reach the UI through an SSH or Session Manager tunnel, never through the security group.
  • The web UI requires the password generated for this instance on first boot.
  • The service runs as the unprivileged nanobot user with no Linux capabilities. The operating system and runtime are read-only to it, other users' home folders are hidden, and it can only write under /var/lib/nanobot.
  • The service is blocked from the EC2 instance metadata service, so the agent cannot use the instance's IAM role.
  • The agent's tools are restricted to its workspace. This is a single-customer runtime, not a multi-tenant security boundary. Use a separate instance for each trust domain.
  • Credentials in config.json are protected by file permissions, not by an application-level vault. EBS encryption does not protect them from an administrator logged in to the instance.
  • Your model provider receives the prompts and tool context the agent sends. Telegram receives messages only if you turn it on.

Services

Service Purpose
sushi-nanobot-firstboot.service Creates the private configuration once, on first boot
sushi-nanobot.service Runs the nanobot gateway and web UI

Check status and recent logs:

sudo systemctl is-active sushi-nanobot.service
sudo systemctl show sushi-nanobot.service -p ActiveState -p SubState -p NRestarts
sudo journalctl -u sushi-nanobot.service --no-pager -n 50

Check gateway health on the instance:

curl -s http://127.0.0.1:18790/health

Restart, stop or start the service with systemd:

sudo systemctl restart sushi-nanobot.service

Use systemd only. Do not start a second gateway with nanobot gateway --background or nanobot's install-service command.

Backups

Everything you need is in /var/lib/nanobot/.nanobot: configuration and keys, the web UI password, sessions, workspace, memory and schedules. Back up the whole folder, and keep its nanobot ownership and 0600/0700 permissions.

For a consistent backup, wait for running tasks to finish, then:

sudo systemctl stop sushi-nanobot.service
# Take and verify your backup, for example an EBS snapshot.
sudo systemctl start sushi-nanobot.service

Backups contain credentials and your content: restrict access to them, and test a restore on a separate instance. State survives service restarts. It does not survive instance termination or deletion of the EBS volume.

Upgrades

A new AMI version does not update running instances. To upgrade:

  1. Launch the new version on a separate instance.
  2. Restore only the state you need from a protected backup.
  3. Repeat the test task, and the Telegram check if you use it.
  4. Switch over. Keep only one instance polling the bot at a time.
  5. Keep the old instance and its backup until the new one is verified.

Costs

Stop instances you are not using to stop software and compute charges. Retained EBS volumes and snapshots still cost money. Watch your model provider's usage and quotas separately.

Support

Software Sushi provides AMI packaging and setup guidance at info@softwaresushi.com. Include the product version, sanitized steps to reproduce and the kind of error. Never send provider keys, bot tokens, configuration files, the web UI password or your files. Guaranteed response times need a separate agreement. Model provider credits and upstream nanobot support are not included.