MaxKB 2.10.8

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick MaxKB 2.10.8 on Ubuntu 24.04 as the software version, pick your Region, then choose Launch through EC2. Choose m5.large (MaxKB with its database and embedding model uses about 2 GiB of memory at rest), your key pair and a security group as above. The root EBS volume is 30 GiB. Knowledge bases and uploaded files live under /var/lib/maxkb on it, and you can grow it later.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=maxkb}]'

• MaxKB 2.10.8 on Ubuntu 24.04: SSH user ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot generates the secrets and the certificate, creates the database, starts MaxKB, sets the admin password, opens nginx and runs a sign-in check before it finishes. This takes two to three minutes on the first start:

systemctl is-active docker maxkb-egress-guard maxkb nginx maxkb-firstboot
sudo test -f /var/lib/sac/data/maxkb-firstboot.done && echo FIRSTBOOT_DONE

active active active active active FIRSTBOOT_DONE

Only SSH and nginx listen on public addresses. MaxKB is published on loopback only:

sudo ss -lntp | awk 'NR>1 {print $4}' | grep -vE '127\.0\.0\.(5[0-9]|1:[0-9]*[^0-9])' | sort -u

0.0.0.0:22 0.0.0.0:443 0.0.0.0:80 127.0.0.1:8080 [::]:22 [::]:443 [::]:80

sudo docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'

maxkb sac/maxkb:v2.10.8-lts-sac 5432/tcp, 6379/tcp, 127.0.0.1:8080->8080/tcp

Print the URL and the user name:

sudo grep -E '^MAXKB_(URL|USERNAME)=' /root/maxkb-credentials.txt

MAXKB_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/admin/ MAXKB_USERNAME=admin

The password is in the same root-only file. Display it when you need it:

sudo cat /root/maxkb-credentials.txt

• MAXKB_URL is the address of the MaxKB console. It uses the instance's public DNS name from EC2 instance metadata (the public IP address when the subnet has no public DNS names). The certificate also names the public and private IP addresses. To use your own DNS name, see Step 11.

• MAXKB_USERNAME and MAXKB_PASSWORD sign in as the administrator.

• MAXKB_NEW_USER_DEFAULT_PASSWORD is the initial password that MaxKB fills in when you create the second user. It cannot sign in as the admin.

Open MAXKB_URL in a browser. The certificate is self-signed, so your browser warns once. Continue past the warning, or install your own certificate (Step 11). Sign in as admin with the password from the file, then change it under the avatar menu, Change Password. The new password must be 6 to 20 characters with an uppercase letter, a lowercase letter, a digit and a special character.

After one failed sign-in, MaxKB asks for a CAPTCHA. After five failures, it locks the account for ten minutes. nginx also limits each client address to 10 sign-in attempts a minute.

C=/etc/ssl/maxkb/maxkb.crt; U=https://127.0.0.1 for p in /admin/api/user/profile /admin/api/workspace/default/application /admin/api/workspace/default/knowledge /admin/api/workspace/default/model; do echo "GET $p (not signed in) -> HTTP $(curl -s --cacert $C -o /dev/null -w '%{http_code}' $U$p)"; done curl -s --cacert $C $U/admin/api/profile | jq -c '.data | {version, edition}'

GET /admin/api/user/profile (not signed in) -> HTTP 401 GET /admin/api/workspace/default/application (not signed in) -> HTTP 401 GET /admin/api/workspace/default/knowledge (not signed in) -> HTTP 401 GET /admin/api/workspace/default/model (not signed in) -> HTTP 401 {"version":"v2.10.8-lts (build at 2026-10-22T10:35, commit: 792a525)","edition":"CE"}

MaxKB's published default password is refused:

U=https://127.0.0.1; C=/etc/ssl/maxkb/maxkb.crt printf '{"username":"admin","password":"MaxKB@123.."}' | curl -s --cacert $C -H 'Content-Type: application/json' --data @- $U/admin/api/user/login | jq -c '{code, message}'

{"code":1005,"message":"Login failed 5 times, account will be locked, you have 4 more chances !"}

That attempt counts as a failed sign-in, so MaxKB asks for a CAPTCHA the next time you sign in as admin. You can also wait ten minutes. From another machine, use MAXKB_URL instead of https://127.0.0.1, and add -k because the certificate is self-signed.

MaxKB's container ships with outbound network closed: it can resolve names but reach nothing outside the instance, so nothing is sent anywhere until you decide where it may go. Check the current state:

sudo maxkb-egress status

MODE=closed ALLOW=none Chain MAXKB-EGRESS (1 references) pkts bytes target prot opt in out source destination 2 120 REJECT 0 -- * * 0.0.0.0/0 169.254.0.0/16 reject-with icmp-admin-prohibited 0 0 REJECT 0 -- * * 0.0.0.0/0 168.63.129.16 reject-with icmp-admin-prohibited 0 0 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 RETURN 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 RETURN 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 2 120 REJECT 0 -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-admin-prohibited

Choose one:

• A hosted model (OpenAI, Azure OpenAI, Anthropic, Google Gemini, DeepSeek and others), and web knowledge bases that crawl public websites. Open the public internet. Private address ranges (your VPC) stay closed.

text sudo maxkb-egress open

• A model server in your VPC (Ollama, vLLM, LM Studio, LiteLLM). Allow just that address and port, and allow this instance in that server's security group.

text sudo maxkb-egress allow 10.0.1.20:11434

sudo maxkb-egress close returns to the shipped default, and sudo maxkb-egress deny <address> removes an allowed address. The policy is kept in /etc/maxkb/egress.conf and applied by the host's firewall, not by anything inside the container. Whatever you set, the instance metadata service (169.254.169.254) stays blocked.

Then add the model in MaxKB. Open Model, select Add Model, choose the provider and enter its endpoint and key. For an OpenAI-compatible server, choose OpenAI and set the API URL to the server's /v1 address. MaxKB checks the model by calling it when you save. Keys you enter are stored encrypted in MaxKB's database on this instance. Your provider bills you for the tokens your agents use.

The screenshots in Steps 6 and 8 use a stand-in model endpoint added as Stand-in model (demo). Your models and answers are your own.

• Open Knowledge, select Create, then General Knowledge.

• Give the knowledge base a name and keep maxkb-embedding as the embedding model.
• Select Upload Document and add your files. MaxKB accepts PDF, Word, Markdown, text, HTML, Excel and CSV files, among others. It splits each document into segments and indexes them on the instance. The File Status column shows Successful when a document is ready.
• Choose Web Knowledge to crawl a website instead of uploading files. This needs outbound access (Step 6).
• Open Retrieval Testing in the knowledge base's menu to see which segments a question would retrieve. For English content, the hybrid search mode usually ranks best with the built-in embedding model, which was trained mainly on Chinese text. You can add another embedding model under Model.

• Open Agent, select Create, then Simple Agent. Give it a name and a description.

• Under AI Model, choose the model you added in Step 6.
• Next to Related Knowledge, select + and add your knowledge base.
• Under Prologue, write the greeting your users see, with suggested questions as list items.
• Select Save, then ask a question in Debug Preview. The answer shows the Knowledge Source it used.

Select Publish to make the agent available. Its Overview page then shows a Public URL (a chat page anyone with the link can use without signing in, with an On switch), Get Embed Code for your own website, and API Access Credentials, which give a base URL and API key for the agent's OpenAI-compatible chat API:

MAXKB_BASE="https://<your-host>/chat/api/<agent-id>" curl -sk "$MAXKB_BASE/chat/completions" -H "Authorization: Bearer <agent-api-key>" -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"What are your support hours?"}],"stream":false}' | jq -r '.choices[0].message.content'

Public chat is per agent. A new instance has no agents, so it has no public chat page at all. Anyone with a published agent's link can ask questions, and those questions use your model. Share the link as you would share an API key, and keep the security group limited to the people who should reach it.

The image ships an end-to-end check that you can run at any time. First boot runs it too. The check reads the credentials file itself and talks to MaxKB over HTTPS through nginx with the instance's certificate pinned. It confirms that:

• Port 80 redirects, and an unknown host name is dropped.
• The console is served.
• Every admin, model, knowledge, tool and user API, and the OpenAI-compatible chat API, refuse an anonymous request.
• A made-up public chat token is refused.
• The published default password, a wrong password and forged session tokens are refused.
• This instance's password signs in with a Secure and HttpOnly cookie.

Run the check:

sudo maxkb-verify.sh

port 80 -> 301 https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/ ; an unknown Host is dropped on 80 and 443 ; certificate verifies for ec2-<public-ip-dashed>.<region>.compute.amazonaws.com ; UI served anonymous: 6 admin/model/knowledge/tool/user APIs 401, OpenAI-compatible chat 401, made-up public token refused (agents/tokens/users: 0 0 1) sign-in: MaxKB@123.. refused, wrong password refused, this instance's password -> token -> 200 (Secure + HttpOnly cookie); forged tokens 401 (MaxKB v2.10.8-lts CE) MAXKB_ROUNDTRIP_OK

The files that hold secrets are root-only, and the database and Redis use this instance's passwords:

sudo stat -c '%a %U:%G %n' /etc/maxkb /etc/maxkb/maxkb.env /root/maxkb-credentials.txt /etc/ssl/maxkb/maxkb.key /var/lib/maxkb/conf/redis.conf
sudo grep -oE '^[A-Z_]+=' /etc/maxkb/maxkb.env

700 root:root /etc/maxkb 600 root:root /etc/maxkb/maxkb.env 600 root:root /root/maxkb-credentials.txt 600 root:root /etc/ssl/maxkb/maxkb.key 600 root:root /var/lib/maxkb/conf/redis.conf POSTGRES_PASSWORD= <set-at-first-boot>= MAXKB_DB_PASSWORD= <set-at-first-boot>= MAXKB_REDIS_PASSWORD= <set-at-first-boot>= MAXKB_HMAC_SIGNED_SERIALIZER_SECRET_KEY= MAXKB_DEFAULT_PASSWORD= <set-at-first-boot>= MAXKB_TIME_ZONE= TZ= MAXKB_SANDBOX_PYTHON_BANNED_HOSTS=

PostgreSQL accepts only scram-sha-256 password logins, over the container's own loopback:

sudo grep -vE '^\s*(#|$)' /var/lib/maxkb/data/postgresql/pgdata/pg_hba.conf

local all all scram-sha-256 host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 local replication all scram-sha-256 host replication all 127.0.0.1/32 scram-sha-256 host replication all ::1/128 scram-sha-256 host all all all scram-sha-256

The host's firewall rules for the container, and the metadata service seen from inside it:

sudo iptables -S DOCKER-USER | head -4; sudo iptables -S MAXKB-EGRESS | head -3 sudo docker exec maxkb /opt/py3/bin/python -c 'import urllib.request try: urllib.request.urlopen("http://169.254.169.254/latest/meta-data/", timeout=5); print("metadata service: reachable") except Exception as e: print("metadata service from the container: blocked")'

-N DOCKER-USER -A DOCKER-USER -i br-maxkb -j MAXKB-EGRESS -A DOCKER-USER -d 169.254.169.254/32 -j DROP -A DOCKER-USER -d 168.63.129.16/32 -j DROP -N MAXKB-EGRESS -A MAXKB-EGRESS -d 169.254.0.0/16 -j REJECT --reject-with icmp-admin-prohibited -A MAXKB-EGRESS -d 168.63.129.16/32 -j REJECT --reject-with icmp-admin-prohibited metadata service from the container: blocked

The MaxKB service, nginx, Docker and containerd are denied the metadata service too:

systemctl show maxkb nginx docker containerd -p Id -p IPAddressDeny | paste - - -

IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 Id=maxkb.service IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 Id=nginx.service IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 Id=docker.service IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 Id=containerd.service

nginx passes MaxKB a fixed host name and the real client address from the connection, never values a client sends, and marks every cookie Secure and HttpOnly:

grep -E 'proxy_set_header (Host|X-Forwarded-For|X-Real-IP|Forwarded)|proxy_cookie_flags' /etc/nginx/maxkb-proxy.conf

proxy_set_header Host $maxkb_host; proxy_set_header Forwarded ""; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_cookie_flags ~ secure httponly;

No password or key reached a log, the journal, the container's log or configuration, shell history, backups or /etc (other than the secrets file):

sudo maxkb-secret-leak-check.sh

LEAKCHECK_OK no password or key in the journal, auth.log, syslog, cloud-init, nginx, the container log or configuration, MaxKB's logs, shell history, MOTD, /var/backups, /etc (only maxkb.env), /usr/local or /tmp

Point a DNS record at the instance, then set the name that MaxKB is served as. This mints a new self-signed certificate for the name, updates nginx's host rule and the URL in /root/maxkb-credentials.txt, reloads nginx and keeps the name across reboots:

sudo maxkb-set-hostname <your-domain>

Without a configured name, the instance re-reads its address from EC2 instance metadata at every boot, so a stop and start that changes the public IP address keeps MaxKB reachable. To use a certificate from your own certificate authority instead, copy it over /etc/ssl/maxkb/maxkb.crt and maxkb.key (key mode 0600), then run sudo systemctl reload nginx. Running maxkb-set-hostname again replaces it with a self-signed one.

If you lose the admin password, set a new random one. The command writes it to /root/maxkb-credentials.txt:

sudo maxkb-reset-admin-password

Everything MaxKB stores (the database, uploaded files and logs) is under /var/lib/maxkb, and its secrets are in /etc/maxkb. Back up both with EBS snapshots, or stop MaxKB to take a consistent copy:

sudo systemctl stop maxkb
sudo tar -C / -czf /root/maxkb-backup-$(date +%F).tar.gz var/lib/maxkb etc/maxkb
sudo systemctl start maxkb

The archive contains your secrets, so keep it as private as the instance. Run sudo systemctl restart maxkb to restart the MaxKB container. The console answers again after about a minute.

cat /usr/share/maxkb-appliance/VERSIONS

MaxKB v2.10.8-lts Community Edition (github.com/1Panel-dev/MaxKB, GPL-3.0), commit 792a525c5a78e42bf04b91c251f747a0bc3e8517. Upstream image: docker.io/1panel/maxkb@sha256:27ac6c21323e5018078f7a1c4c2d82dc9ab48725b65165cb54fca5e540f66216 (linux/amd64), built by upstream's public GitHub Actions workflow from that commit. Shipped image: sac/maxkb:v2.10.8-lts-sac = sha256:78ab999133353db8ddd2455c59ed70045f5bfb2371a80e845ad462946decd435, upstream plus the sac same-line patch layer (CPython 3.11.17 from docker.io/library/python@sha256:b95327ce1439e687237841b0210677aeadd62d55a060a5f6bcb9c15bf6251dd3, Debian trixie/security/PGDG updates, curl and vim removed, djangorestframework 3.18.3, pypdf 6.21.2, pip 26.2.2, setuptools 84.2.1). Docker Engine 5:29.9.2-1~ubuntu.24.04~noble, containerd.io 2.4.2-3~ubuntu.24.04~noble, nginx 1.24.0-2ubuntu7.18.

sudo docker exec maxkb bash -c 'python3 --version; /opt/py3/bin/python -m pip freeze 2>/dev/null | grep -iE "^(django|djangorestframework|pypdf)=="; postgres --version; redis-server --version | cut -d" " -f1-3; dpkg-query -W -f="\${Package} \${Version}\n" postgresql-17-pgvector libssl3t64' nginx -v 2>&1; docker --version; lsb_release -ds ls /usr/share/doc/sac/maxkb/

Python 3.11.17 Django==5.2.17 djangorestframework==3.18.3 pypdf==6.21.2 postgres (PostgreSQL) 17.11 (Debian 17.11-1.pgdg13+2) Redis server v=8.0.6 libssl3t64 3.5.7-1~deb13u3 postgresql-17-pgvector 0.8.7-1.pgdg13+1 nginx version: nginx/1.24.0 (Ubuntu) Docker version 29.9.2, build a82e528 Ubuntu 24.04.5 LTS LICENSE VERSION

• MaxKB Community Edition 2.10.8 LTS: container maxkb from image sac/maxkb:v2.10.8-lts-sac, service maxkb, data /var/lib/maxkb, logs sudo docker logs maxkb and /var/lib/maxkb/logs
• PostgreSQL 17.11 with pgvector 0.8.7: inside the container, on its loopback
• Redis 8.0.6: inside the container, on its loopback
• Docker Engine 29.9.2: service docker, with firewall rules by maxkb-egress-guard
• nginx 1.24.0: TLS on 443, redirect on 80, site /etc/nginx/sites-available/sac-maxkb
• Ubuntu 24.04 LTS: unattended security upgrades on

Known open upstream items. After SecureAnyCloud's patches, a vulnerability scan of the container still lists items that have no fixed release yet. SecureAnyCloud publishes a new version when MaxKB or Debian release fixes.

• diskcache 5.6.3 (unsafe data in its cache directory). The cache directory inside the container is writable by root only.
• Debian packages that Debian has not fixed for this release or marks as minor, among them glibc, util-linux, ncurses, perl, and the Kerberos and SASL client libraries (PostgreSQL uses neither).
• libxml2 CVE-2026-6653, which is reachable only through PostgreSQL's XML functions. MaxKB does not use those functions, and MaxKB's tool sandbox has no database access. The image's build tests that a Python tool cannot connect to PostgreSQL or Redis over TCP or PostgreSQL's socket, and cannot read their passwords. SecureAnyCloud re-checks this at each MaxKB release.
• Redis's cluster bus. Cluster mode is off and Redis listens on the container's loopback.