Artificial Intelligence (AI) AWS

MaxKB 2.10.8 on AWS User Guide

| Product: MaxKB 2.10.8 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the MaxKB 2.10.8 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg vector databases and RAG listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

MaxKB is an open source platform for building question answering agents on your own content (retrieval augmented generation, or RAG). You upload documents or crawl a website into a knowledge base, connect your language model, and publish agents that answer from your content and show the sources they used, in MaxKB's own chat page, embedded in your website, or through an OpenAI compatible API. This image ships the Community Edition of MaxKB 2.10.8 LTS.

MaxKB runs in one container: the web application and API, a background worker, a built in embedding model that indexes your documents on the instance (no external service needed for that), PostgreSQL 17 with pgvector for vector search, and Redis. The language model is yours: OpenAI, Azure OpenAI, Anthropic, Google Gemini, DeepSeek, or an OpenAI compatible server such as Ollama or vLLM in your VPC. No model and no model key ship in the image.

The cloudimg image ships it the secure way:

  • No default login. Upstream MaxKB creates its admin account with a published password. This image never lets that password exist: first boot gives the admin a password generated on your instance, proves the published default is refused, and writes the password to /root/maxkb-credentials.txt (root only).
  • Every secret unique to your instance. First boot generates the PostgreSQL and Redis passwords, MaxKB's secret keys and the TLS certificate, and creates the database itself, so MaxKB's token signing keys are created in your own database too. Nothing is baked into the image, and the secrets reach MaxKB from a root only file, never through a command line or the container's configuration.
  • HTTPS from the first boot. nginx serves MaxKB on port 443 with a certificate generated on your instance's first boot. Port 80 redirects to HTTPS. MaxKB listens on 127.0.0.1:8080; PostgreSQL, Redis and the embedding model listen on the container's own loopback and are not reachable from the network or even from the instance.
  • Closed until first boot, and fail closed. MaxKB cannot start before first boot has written its secrets, and refuses to start if they are missing, too short or an upstream default. nginx starts only after the admin password check has passed. If first boot fails, it removes its markers and stops everything.
  • Outbound network closed by default. MaxKB's container can reach nothing outside the instance until you open it (Step 6): one command opens the public internet for a hosted model, or allows a single model server in your VPC. The instance metadata service is blocked for MaxKB, its container, nginx and Docker whatever you set, so a link in a web knowledge base, a tool or a model setting can never read the instance's identity or credentials. The AMI requires IMDSv2.
  • Patched beyond upstream. cloudimg rebuilt upstream's container image with the current security fixes: Python 3.11.17, every pending Debian and PostgreSQL package update (including OpenSSL, glibc and pgvector 0.8.7), and patched versions of the Python packages a vulnerability scan flagged (Step 13 lists what remains). The image is flattened to a single layer without the TLS key pair upstream's own image build generated, so no key shared with other copies of the upstream image ships.
  • Hardened access. Every MaxKB cookie is marked Secure and HttpOnly, nginx passes MaxKB a fixed host name and the real client address, requests for any host name the instance does not serve are dropped, and sign in attempts are rate limited per client address on top of MaxKB's own CAPTCHA and account lock.
  • Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

This is the Community Edition. MaxKB itself limits it to 50 knowledge bases, 5 agents and 2 user accounts (the admin plus one more). The Upgrade button in MaxKB's header points to FIT2CLOUD's commercial Professional Edition, which needs a licence from FIT2CLOUD and is not included; everything this guide describes is part of the open source Community Edition, and no licence key is needed.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
  • A security group that allows TCP 22 (SSH), TCP 443 (the web UI and API) and TCP 80 (redirects to HTTPS) from your own networks only. Never open 8080, 5432 or 6379: MaxKB and its database are not on the network.
  • A language model MaxKB can reach: an API key for a hosted provider, or an OpenAI compatible server in your VPC.

Step 1: Launch the instance

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 and your Region, then 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.

With the AWS CLI (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}]'

Step 2: Connect to your instance

Version SSH user
MaxKB 2.10.8 on Ubuntu 24.04 ubuntu 
ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

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 (two to three minutes on the first start):

systemctl is-active docker maxkb-egress-guard maxkb nginx maxkb-firstboot
sudo test -f /var/lib/cloudimg/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  cloudimg/maxkb:v2.10.8-lts-cloudimg  5432/tcp, 6379/tcp, 127.0.0.1:8080->8080/tcp

Step 4: Get your URL and sign in

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 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 (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 (6 to 20 characters with an upper case letter, a lower case letter, a digit and a special character).

The MaxKB sign in page served over HTTPS by the instance

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

Step 5: Confirm that nothing is open without signing in

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 (or wait ten minutes). From another machine, use MAXKB_URL instead of https://127.0.0.1 (and -k, since the certificate is self signed).

Step 6: Open outbound access for your language model

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:

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.

MaxKB's Model page with an OpenAI compatible model added next to the built in maxkb-embedding model

The screenshots in Steps 6 and 8 come from a test instance with a stand in model endpoint added as Stand-in model (demo); your models and answers are your own.

Step 7: Build a knowledge base

  1. Open Knowledge, select Create, then General Knowledge.
  2. Give it a name and keep maxkb-embedding as the embedding model.
  3. 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.

A MaxKB knowledge base with one document split into segments and indexed

  • Web Knowledge crawls a website instead of uploaded files (it needs outbound access, Step 6).
  • Retrieval Testing in the knowledge base's menu shows 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.

Step 8: Create an agent, publish it and use its API

  1. Open Agent, select Create, then Simple Agent. Give it a name and a description.
  2. Under AI Model, choose the model you added in Step 6.
  3. Next to Related Knowledge, select + and add your knowledge base.
  4. Under Prologue, write the greeting your users see, with suggested questions as list items.
  5. Select Save, then ask a question in Debug Preview. The answer shows the Knowledge Source it used.

A MaxKB agent answering a warranty question in the debug preview and citing 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: 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, which uses your model, so share it as you would share an API key, and keep the security group limited to the people who should reach it.

Step 9: Run the built in check

The image ships an end to end check you can run at any time; first boot runs it too. It reads the credentials file itself and talks to MaxKB over HTTPS through nginx with the instance's certificate pinned: port 80 redirects, 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, and this instance's password signs in with a Secure and HttpOnly cookie:

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

Step 10: Security checks

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=
POSTGRES_INITDB_ARGS=
MAXKB_DB_PASSWORD=
REDIS_PASSWORD=
MAXKB_REDIS_PASSWORD=
MAXKB_SECRET_KEY=
MAXKB_HMAC_SIGNED_SERIALIZER_SECRET_KEY=
MAXKB_DEFAULT_PASSWORD=
MAXKB_LANGUAGE_CODE=
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

MaxKB's 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

Step 11: Your own DNS name and certificate

Point a DNS record at the instance, then set the name 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) and run sudo systemctl reload nginx; running maxkb-set-hostname again replaces it with a self signed one.

Step 12: New admin password, backups and restarts

If the admin password is lost, set a new random one (it is written 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 them up with EBS snapshots, or stop MaxKB for 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: keep it as private as the instance. sudo systemctl restart maxkb restarts the MaxKB container (about a minute until the console answers again).

Step 13: Server components

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: cloudimg/maxkb:v2.10.8-lts-cloudimg = sha256:8913af1051dd1bb074bae47cd805c945c7cdbcdc593e6a3ae047498ebc8b7637, upstream plus the cloudimg 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/cloudimg/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
Component Version Notes
MaxKB Community Edition 2.10.8 LTS container maxkb from image cloudimg/maxkb:v2.10.8-lts-cloudimg, service maxkb, data /var/lib/maxkb, logs sudo docker logs maxkb and /var/lib/maxkb/logs
PostgreSQL + pgvector 17.11 + 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; firewall rules by maxkb-egress-guard
nginx 1.24.0 TLS on 443, redirect on 80, site /etc/nginx/sites-available/cloudimg-maxkb
Ubuntu 24.04 LTS unattended security upgrades on

Known open upstream items. After cloudimg's patches, a vulnerability scan of the container still lists items that have no fixed release yet: diskcache 5.6.3 (unsafe data in its cache directory; the cache directory inside the container is writable by root only), and Debian packages that Debian has not fixed for this release or marks as minor, among them glibc, util-linux, ncurses, perl, Kerberos and SASL client libraries (PostgreSQL uses neither), libxml2 (only PostgreSQL's XML functions, which MaxKB does not use) and Redis's cluster bus (cluster mode is off and Redis listens on the container's loopback). cloudimg publishes a new version when MaxKB or Debian release fixes.

Troubleshooting

  • The browser warns about the certificate: it is self signed. Continue once, or install your own certificate (Step 11). For curl, pass --cacert /etc/ssl/maxkb/maxkb.crt on the instance or -k elsewhere.
  • The connection is closed without a response: the request used a host name the instance does not serve (nginx drops unknown names). Use MAXKB_URL, the instance's IP address, or set your name with maxkb-set-hostname.
  • Adding a model fails with a connection error: outbound access is closed (Step 6). Open it, or allow your model server, then save the model again.
  • 502 Bad Gateway: MaxKB is still starting (after a reboot or restart it takes about a minute). Wait and reload.
  • Sign in asks for a CAPTCHA: a previous attempt failed. Enter the CAPTCHA, or wait ten minutes. HTTP 429: too many attempts from your address; wait a minute.
  • MaxKB does not start: journalctl -u maxkb shows what the preflight check refused.
  • First boot: journalctl -u maxkb-firstboot shows what it did (it never prints a password). If it failed, it closed everything; fix the cause and run sudo systemctl restart maxkb-firstboot.

Security recommendations

  • Restrict the security group to your own networks, and open outbound access only as far as your model needs (prefer maxkb-egress allow for a model server in your VPC).
  • MaxKB sends your questions and the retrieved document text to the model you configure; choose a provider whose data handling suits your documents.
  • Treat published agent links and agent API keys like passwords, and switch off public access for agents that do not need it.
  • Custom Python tools you write in MaxKB run as a separate sandbox user that cannot reach PostgreSQL, Redis or the metadata service; review tools before you enable them.

Support and licensing

cloudimg provides 24/7 technical support by email and live chat: support@cloudimg.co.uk.

MaxKB is licensed under the GNU General Public License v3 (/usr/share/doc/cloudimg/maxkb/LICENSE); the source code is at https://github.com/1Panel-dev/MaxKB. This image contains the Community Edition only. MaxKB is developed by FIT2CLOUD and the 1Panel community; cloudimg is not affiliated with or endorsed by FIT2CLOUD, and the name is used only to identify the software.