Operations¶
This page covers the security model, service management, backups, upgrades and support for OpenHands Core.
Security model¶
- Agent Canvas is published only on
127.0.0.1:8000. Reach it through an SSH or Session Manager tunnel, never through the security group. - The container runs as UID/GID
10001:10001, drops all Linux capabilities, blocks privilege escalation, and has no access to the host Docker socket, home folders or root file system. - No provider key, bot token or account is baked into the image. Each instance generates its own session and encryption keys on first start.
- Your model provider receives the prompts and tool context the agent sends. Telegram receives messages only if you turn on the bridge.
- One instance is one shared workspace. Separate conversations or bots do not isolate users from each other. Use a separate instance for each trust domain.
Services¶
| Service | Purpose | Default |
|---|---|---|
sushi-openhands.service |
Runs the Agent Canvas container sushi-openhands |
Enabled, starts on boot |
sushi-openhands-telegram.service |
Optional Telegram bridge | Off until you configure and enable it |
Check status and recent logs:
sudo systemctl is-active sushi-openhands.service
sudo systemctl show sushi-openhands.service -p ActiveState -p SubState -p NRestarts
sudo journalctl -u sushi-openhands.service --no-pager -n 50
The service restarts the container automatically if it fails. Do not start a second container to work around a failing service.
Backups¶
Your data lives in:
| Path | Contents |
|---|---|
/var/lib/sushi-openhands/state |
Settings, profiles, conversations, session and encryption keys |
/var/lib/sushi-openhands/projects |
Project files |
/etc/sushi/openhands-telegram.local.json |
Telegram configuration, if used |
/var/lib/sushi-openhands-telegram |
Telegram bridge state, if used. Systemd may store it under /var/lib/private. |
Back up state and projects together. The saved model settings can only be
decrypted with the encryption key in state. Do not reset the Telegram state
to retry a task: it holds the bridge's message position and job records.
For a consistent backup, wait for running tasks to finish, then stop the services, take your backup, and start them again:
sudo systemctl stop sushi-openhands-telegram.service
sudo systemctl stop sushi-openhands.service
# Take and verify your backup, for example an EBS snapshot.
sudo systemctl start sushi-openhands.service
sudo systemctl start sushi-openhands-telegram.service
Only start the Telegram service if you configured it. Backups contain credentials and your content: restrict access to them, keep file ownership and permissions, and test a restore on a separate instance.
State survives service restarts and container replacement. It does not survive instance termination or deletion of the EBS volume.
Upgrades¶
A new AMI version does not update running instances. To upgrade:
- Launch the new version on a separate instance.
- Restore only the state you need from a protected backup.
- Repeat the test task, and the Telegram check if you use it.
- Switch over. Keep only one Telegram bridge polling the bot at a time.
- Keep the old instance and its backup until the new one is verified.
Changing the instance's encryption key in place is not supported. To rotate it, use a new instance and enter your provider credentials again.
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.
Licenses¶
OpenHands is MIT-licensed. Its license notice is in
/opt/sushi/licenses/openhands/.
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, session or encryption keys, or your files. Guaranteed response times need a separate agreement. Model provider credits and upstream OpenHands support are not included.