Nanobot: launch, configure and verify

1. Launch and wait for automatic startup

When an approved Marketplace version is available, subscribe and launch x86_64 CPU EC2 with IMDSv2 and at least 16 GiB root storage. Runtime dependencies are already installed; no GPU is required. Select an encrypted gp3 customer root volume at launch and use a customer-approved KMS key when required. The Marketplace ingestion snapshot is unencrypted; customer EBS encryption is a separate launch setting. No filesystem encryption/decryption prompt is required by the recipe. For SSM access, assign the customer instance role required by Systems Manager, ensure its HTTPS/DNS connectivity and grant your administrator session access. The application itself does not need AWS credentials. Allow outbound HTTPS to the selected model provider and, only when enabled, Telegram. If using SSH, restrict TCP 22 to your trusted administrator CIDR. Keep the application port private.

sudo cloud-init status --wait
sudo systemctl is-active sushi-nanobot.service

In the EC2 console, select the correct Region and this instance, then confirm its system and instance status checks passed. If launch fails for capacity or quota, review the Region's EC2 On-Demand Standard instance vCPU quota and EBS storage quota in Service Quotas before retrying; a larger instance or extra retained volumes add AWS charges. The recipe does not automatically create extra instances, databases or load balancers. First initialization can take several minutes. Wait for cloud-init and the enabled service before opening the interface. A failed or repeatedly restarting service requires diagnosis; do not start a second gateway/container to bypass it.

No local inference engine. A fresh October 5 consumer of the exact distribution image passed automatic boot and offline tools on t3.medium / 4 GiB with 16 GiB root storage; this is not a load benchmark. Retained October 4 full-host scan: 94 Critical / 710 High, all on the kernel binary or kernel-modules package; no findings were ignored. Scanner findings are not a count of distinct proven exploitable vulnerabilities.

2. Open the local interface securely

Install AWS CLI and the Session Manager Plugin on your own workstation. Replace the profile, region and instance placeholders:

aws --profile CUSTOMER_PROFILE --region CUSTOMER_REGION ssm start-session \
  --target INSTANCE_ID \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["8765"],"localPortNumber":["8765"]}'

Open http://127.0.0.1:8765. The WebUI requires a generated per-instance password from channels.websocket.tokenIssueSecret in /var/lib/nanobot/.nanobot/config.json. Retrieve it through a private SSH connection into a local file protected by umask 077; open that file privately. Never use Run Command output, a screenshot or a support transcript for this secret. The initial-password retrieval procedure was not part of the filmed wizard.

3. Configure your cloud model

In Settings → Models choose Anthropic and Claude Haiku 4.5. Enter your API key privately. The bounded verified task used context 16384, max output 512 and six tool iterations.

A supported provider account, credentials and quota are required and billed independently. The image does not include model credits. Your selected provider receives the prompts and tool context sent by the agent; Telegram receives messages when that optional channel is enabled. Keep keys out of shell arguments, user data, recordings, shared logs and support messages. Never upload private configuration files.

4. Connect a dedicated private Telegram bot

Telegram is optional; finish the UI acceptance check before enabling it. Create a dedicated bot with the official BotFather in your own Telegram account. In a private Bot API client, verify the bot identity with getMe and identify your own private-chat sender/chat IDs from getUpdates before starting the poller. Treat the bot token as a secret; never place it in recorded URLs, shell arguments or shared output. Do not inspect other users' messages or connect an existing webhook/poller. Only one running consumer should poll that bot. Download the empty configuration template, edit it privately and install it at /var/lib/nanobot/.nanobot/telegram.private.json.

{
  "telegramToken": "",
  "allowedUserIds": [],
  "allowedChatIds": []
}

Fill the token and allowedUserIds/allowedChatIds as numeric ID strings. Empty lists, usernames, zero and wildcards are rejected. The helper preserves existing model configuration. Use this helper: a GUI-only chat-allowlist path has not been verified.

sudo chown nanobot:nanobot /var/lib/nanobot/.nanobot/telegram.private.json
sudo chmod 0600 /var/lib/nanobot/.nanobot/telegram.private.json
sudo runuser -u nanobot -- /opt/nanobot/venv/bin/python /opt/nanobot/telegram-config.py \
  --config /var/lib/nanobot/.nanobot/config.json \
  --private-input /var/lib/nanobot/.nanobot/telegram.private.json
sudo systemctl restart sushi-nanobot.service

5. Run a real tool task and inspect the result

Create a new run ID, send this synthetic task once in the interface, and repeat it with a different run ID in the authorized Telegram bot:

Run ID: CUSTOMER-UNIQUE-UTC-ID
In your allowed workspace, create e2e_CUSTOMER-UNIQUE-UTC-ID/input.csv with exactly:
value
5
17
20
Use native file/terminal tools to read the CSV and assert values [5,17,20],
sum 42 and row count 3. Write result.json containing run_id, sum=42,
row_count=3 and passed=true. Read result.json back with a separate tool call.
Reply in English with the run ID and verified result. Stop after this task.

Expect actual tool execution, a reply stating total 42 / three rows, and matching result.json on disk. Verify the saved CSV and JSON independently; a saved API key, a running service or a provider ping alone does not prove end-to-end success. The October 5 fresh consumer of the exact distribution image passed the native UI and real private Telegram task, with native trace and independent file readback. Larger workloads, extra providers and the complete GUI-only onboarding sequence remain separate validations.

6. Persistent state, restart and backups

/var/lib/nanobot/.nanobot contains configuration, sessions, workspace, memory and schedules. It is owned by nanobot:nanobot; private configuration must retain mode 0600. Back up the whole directory, including the browser password and provider configuration. Credentials are private application state, not an application-encrypted vault. EBS encryption does not replace file permissions or protect data from a logged-in administrator. Browser-password rotation is not verified by the current distribution acceptance; do not infer a supported GUI reset procedure from this guide.

Services preserve customer state across normal restarts. Instance termination or deletion of the underlying EBS volume does not. Before a consistent protected backup or migration, wait for tasks to finish, stop the owning service and poller, and use your approved encrypted EBS snapshot or file-backup procedure. Backups contain credentials and customer content: restrict access, retain ownership and permissions, and test restoration on a separate instance before replacing the original.

sudo systemctl stop sushi-nanobot.service
# Take and verify your protected backup while services are stopped.
sudo systemctl start sushi-nanobot.service

Use one instance per trust domain. A new AMI version does not update an existing instance automatically. Launch the approved replacement separately, check state-format compatibility, restore only the required protected customer state, then repeat the tool and channel acceptance checks before cutover. Keep exactly one bot poller active during migration. Retain the old instance and its protected backup until the replacement is verified.

7. Diagnose and recover

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

Inspect logs privately and redact credentials, private URLs, chat IDs and customer text before requesting support. A provider authentication or quota error must be fixed in native model settings; service readiness alone does not prove inference. If Telegram is silent, check the dedicated bot identity, private allowlist, one-poller rule, provider settings and outbound connectivity. Do not delete another integration's webhook or clear job state to force a retry. After a deliberate idle restart, reload the browser interface and repeat a new uniquely identified tool task; independently inspect the saved output. The October 5 UI success was observed before restart. Backend readiness, file persistence and a new Telegram recovery reply passed afterward; automatic frontend reconnection and a full EC2 reboot were not tested.

Stop unused EC2 instances to stop running software/compute charges; retained EBS volumes and other AWS resources can still incur costs. Rotate provider keys through the native model settings and bot tokens through BotFather plus the private channel helper/configuration. Stop the poller before replacing its token, then restart only its owning service and repeat acceptance. Revoke credentials when decommissioning. Remove only customer-owned temporary copies; keep the required workspace/history and protected backup.

Support: info@softwaresushi.com. Include the product/version, sanitized reproduction steps and error category. Never send populated private configuration, provider keys, bot tokens, session/encryption keys or customer files. Software Sushi covers AMI packaging and setup guidance; provider credits, upstream vendor support and guaranteed response times are not included.

8. Distribution acceptance and reference video

The fresh distribution acceptance record identifies the exact AMI ami-094c88272019cbdc1, baked source d919e451f7476f2afbc6c7d70849239cefe8417f, actual UTC receipts, model, native tool calls and synthetic CSV/JSON hashes. The October 5 bounded task used claude-haiku-4-5-20251001. Native UI identifier: UI-NANO-DIST-20261005T0728Z; Telegram identifier: TG-NANO-DIST-20261005T0730Z; idle-recovery identifier: TG-NANO-RECOVER-20261005T0700Z. These identifiers are unique labels, not execution timestamps. The test verified total 42 and three rows in saved files, retained those files across an idle service restart, and received a new recovery reply in the dedicated private chat.

The linked YouTube video shows an earlier candidate and remains labeled with that earlier version/source. It has not been replaced with a recording of this October 5 distribution run. Full security findings and the October 4 rejection remain retained; functional checks alone do not establish full security clearance or public availability.