Skip to content
Open WebUI AI Platform & Data · Open WebUI v0.11.4 Launch on AWS

Operations

This page covers running Open WebUI day to day: how it is secured, how to manage the service, where the logs are, how it is updated, what to back up, and how to get help.

Security model

  • Loopback only. The container publishes port 8080 on 127.0.0.1 only. Nothing is reachable from the network until you add a proxy and open the security group yourself.
  • Non-root, locked-down container. Open WebUI runs as UID 10001 with all Linux capabilities dropped, no-new-privileges, and a process limit.
  • Per-instance secret. The session secret is created on first boot in /etc/open-webui/webui.env, readable only by root.
  • No baked data. The image contains no user database, provider keys or model weights.
  • First account is admin. Create it as soon as the UI is up.
  • SSH. Password authentication and root login are turned off.
  • No AWS access. Open WebUI does not call AWS APIs and needs no IAM permissions beyond AmazonSSMManagedInstanceCore for Session Manager.

Manage the service

sudo systemctl status open-webui --no-pager
sudo systemctl restart open-webui
sudo systemctl stop open-webui

open-webui.service runs the container sushi-open-webui with Docker. It waits for docker.service and for sushi-open-webui-firstboot.service, which creates the session secret and the data directory if they are missing. It restarts the container if it fails.

Check that the UI is up:

curl http://127.0.0.1:8080/health

A healthy instance answers {"status":true}. /ready answers once Open WebUI is ready to serve requests.

Logs

The container's output goes to the systemd journal:

sudo journalctl -u open-webui --no-pager -n 100
sudo journalctl -u sushi-open-webui-firstboot --no-pager

Updates

  • Ubuntu packages get security updates automatically through unattended upgrades.
  • Open WebUI is pinned at v0.11.4, in a container image that is already on the instance. The service never pulls a new image. A new Open WebUI release comes as a new version of the AMI: launch it, restore your backup, and move your users over. A new AMI version does not update running instances.

Do not pull a different Open WebUI image

The service runs only the image built for this AMI. Update by launching a new version of the AMI instead.

Backups

Back up /var/lib/open-webui and /etc/open-webui together. The data needs the matching session secret. Stop the service while you copy, so the database is consistent:

sudo systemctl stop open-webui
sudo tar -czf /root/open-webui-backup.tar.gz /var/lib/open-webui /etc/open-webui
sudo systemctl start open-webui

Copy the archive off the instance and keep it private: it contains the session secret, your users and any provider keys saved in the UI.

When you restore on a new instance, stop the service first, and keep /var/lib/open-webui owned by UID and GID 10001 and /etc/open-webui/webui.env owned by root with mode 0600.

The root volume is the only disk. There is no separate data volume.

Check the installation

The image includes a self-test that runs as root. It checks that the services started on their own at boot, that /health, /ready and the UI page answer, that port 8080 is on loopback only, and that the running container matches the installed image. It then restarts Open WebUI and waits for it to be ready again:

sudo /opt/sushi/bin/smoke.sh

It does not send a chat to any model. It expects the first-boot settings in webui.env, such as ENABLE_OLLAMA_API=False and HF_HUB_OFFLINE=1, so it reports a failure if you removed them.

Support

Software Sushi provides AMI packaging and setup guidance. Email info@softwaresushi.com with your product version and the steps you took. Never send credentials or private data. Guaranteed response times require a separate agreement. This offer does not include Open WebUI Inc. support.

Last updated October 13, 2026 · Suggest an improvement