Mem0 on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and operation of Mem0 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Mem0 is an open source, Apache 2.0 licensed memory layer for AI applications. Your chatbot, copilot or agent sends Mem0 the messages of a conversation; Mem0 uses a language model to pick out the facts worth keeping (preferences, names, dates, decisions) and stores them with embeddings. Later, a search for a user, agent or session returns the most relevant memories, so your application can remember people across sessions without replaying every past message.

The image runs the whole Mem0 self-hosted server on one VM:

• The Mem0 REST API (FastAPI) adds, searches, updates and deletes memories, and the Mem0 dashboard (Next.js) lets you browse memories, entities, request logs and API keys. Both are built from the Mem0 source at a pinned commit
• PostgreSQL with pgvector stores the memories, their embeddings, the dashboard accounts and API keys
• Ollama serves two small local models on the VM's CPU: Qwen2.5 1.5B Instruct extracts the memories and mxbai-embed-large embeds them. Both are already Mem0's defaults, so memories work the moment the VM is up, with no API key
• nginx terminates HTTPS with a certificate generated for this VM and serves the dashboard at / and the REST API at /mem0/

Component	Version	Licence
Mem0 server (REST API and dashboard)	mem0ai 2.2.1, server/ at commit 0724291	Apache 2.0
PostgreSQL with pgvector	17.11, pgvector 0.8.7	PostgreSQL Licence
Ollama (CPU)	0.40.5	MIT
Qwen2.5 1.5B Instruct (qwen2.5:1.5b, Q4_K_M)	Ollama manifest f2b0a490	Apache 2.0
mxbai-embed-large v1 (mxbai-embed-large, 1024 dimensions)	Ollama manifest 7544e119	Apache 2.0
Docker Engine	29.9.1	Apache 2.0

Your memories stay on this VM. Upstream Mem0 sends anonymous usage events to PostHog and uses OpenAI for extraction and embeddings by default. In this image telemetry is switched off in the server, the mem0 library and the dashboard, and the bundled local models do the work. While building the image we watched the network during a full session (signing in, adding, searching, updating and deleting memories): no request left the VM. If you want a cloud model, you connect it deliberately (Step 10).

About the local models. Qwen2.5 1.5B is small enough to run on a CPU, which is what makes this image work out of the box, but it is a small model. Adding a memory runs it once over Mem0's long extraction instructions plus your conversation. On the recommended Standard_D4s_v4 an add takes about 15 to 25 seconds (measured: 14, 15 and 22 seconds for three one-sentence messages) and longer conversations take longer; searches do not use the language model and answer in well under a second. The model handles one add at a time, and it can occasionally drop or restate a detail (we saw "turns seven on 14 March" stored as "is seven years old" once in several runs), so review important memories in the dashboard. For faster and stronger extraction, connect a cloud model such as OpenAI (Step 10).

No password, key or certificate is baked into the image. First boot generates, for this VM only, the administrator password, the admin API key, the PostgreSQL password, Mem0's token signing secret, the key Mem0 uses to reach the local models, and the TLS certificate. It creates the administrator account itself, so the setup wizard that would make the first visitor the administrator is closed. Nothing answers on the network until first boot has done this. Backed by 24/7 cloudimg support.

Mem0 is a trademark of Embedchain, Inc. Mem0 is developed by Mem0 (Embedchain, Inc.) under the Apache 2.0 licence. Ollama is developed by Ollama Inc. under the MIT licence, Qwen2.5 by the Qwen team at Alibaba Cloud and mxbai-embed-large by Mixedbread, both under the Apache 2.0 licence. This image is produced by cloudimg and is not affiliated with, endorsed by, or sponsored by Embedchain, Inc., the Mem0 project, Ollama, Alibaba Cloud or Mixedbread. The names are used here solely to identify the software this image contains.

What is included:

• The Mem0 2.2.1 REST API and dashboard, built from the Mem0 source at a pinned commit with every Python and JavaScript dependency locked, published on 127.0.0.1 only
• PostgreSQL 17 with pgvector on a private Docker network only, protected by a per-VM password
• Ollama with Qwen2.5 1.5B Instruct and mxbai-embed-large already downloaded, verified and kept loaded in memory. Ollama listens on the VM's loopback address; Mem0 reaches it through a small model gateway that requires a per-VM key and that only the Mem0 API container can reach
• nginx terminating HTTPS on 443 with a per-VM certificate, and redirecting 80 to HTTPS
• A firewall that stops the Mem0 containers from reaching the Azure Instance Metadata Service, the Azure wire server, your private network and the VM itself, so a crafted model URL cannot be used to read the VM's identity or to probe your network
• Unattended security upgrades left on for the operating system

Prerequisites

• An Azure subscription with permission to create VMs
• A Standard_D4s_v4 VM (4 vCPU, 16 GiB) or larger is recommended. Mem0, its database and the two loaded models use about 4 GiB of memory, and every memory add uses all the CPU it can get
• About burstable sizes: do not use a B-series (burstable) size for real work. We measured it while building this image: a new Standard_B4ms started with about 120 CPU credits and had used them all after about 90 minutes of steady work, after which a single memory add took 5 to 7 minutes instead of about 20 seconds. On two vCPUs (Standard_B2ms) Mem0's extraction instructions alone took about 9 minutes to process the first time. Choose a non-burstable size such as Standard_D4s_v4
• Inbound TCP 443 (and 80 for the redirect) open only to the networks you connect from, plus 22 for SSH administration
• An SSH key pair for administrative access
• Optional: an OpenAI API key if you want faster, stronger memory extraction than the local model

Step 1: Deploy from the Azure Portal

1. In the Azure Portal, search the Marketplace for Mem0 and select the cloudimg offer, then Create.
2. Choose your subscription, resource group and region.
3. Set the VM size to Standard_D4s_v4 or larger.
4. Under Administrator account, select SSH public key and supply your own key.
5. Under Inbound port rules, allow HTTPS (443), HTTP (80) and SSH (22), then restrict all three to your own address ranges on the networking blade.
6. Review and create.

Step 2: Deploy from the Azure CLI

az vm image terms accept --urn cloudimg1647283583153:mem0-ubuntu-24-04:default:latest

az vm create \
  --resource-group my-resource-group \
  --name my-mem0 \
  --image cloudimg1647283583153:mem0-ubuntu-24-04:default:latest \
  --size Standard_D4s_v4 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

# Open HTTPS (and the HTTP redirect) to YOUR network only.
MY_CIDR="203.0.113.0/24"   # replace with your own range
az network nsg rule create \
  --resource-group my-resource-group \
  --nsg-name my-mem0NSG \
  --name allow-https-from-office --priority 1010 \
  --source-address-prefixes "${MY_CIDR}" \
  --destination-port-ranges 80 443 --protocol Tcp --access Allow

Step 3: Connect to your VM

ssh azureuser@<vm-ip>

Step 4: Confirm the services are running

First boot takes about 4 minutes on a Standard_D4s_v4: it generates this VM's secrets and certificate, loads the two models and has the language model read Mem0's extraction instructions once (so your first memory add does not have to), initialises the database, creates the administrator account and proves the access gate before it finishes. After any later reboot Mem0 is back in about 3 minutes for the same reason.

# Every unit reports "active".
systemctl is-active docker ollama mem0 mem0-model-gateway nginx
test -f /var/lib/cloudimg/mem0-firstboot.done && echo "first boot complete"

# Only SSH (22) and nginx (80, 443) listen publicly. The Mem0 API listens on 127.0.0.1:8888,
# the dashboard on 127.0.0.1:3000, Ollama on 127.0.0.1:11434, the model gateway on the private
# Docker bridge address 172.30.248.1:11435, and port 53 is the operating system's local DNS resolver.
sudo ss -lntpH | grep -v llama-server | awk '{print $4}' | sort -u

Expected output:

active
active
active
active
active
first boot complete
0.0.0.0:22
0.0.0.0:443
0.0.0.0:80
127.0.0.1:11434
127.0.0.1:3000
127.0.0.1:8888
127.0.0.53%lo:53
127.0.0.54:53
172.30.248.1:11435
[::]:22
[::]:443
[::]:80

While the models are loaded, Ollama's model runners also listen on random high ports of 127.0.0.1 (the command above hides them); they are loopback only. Mem0 runs as three containers:

sudo docker compose -f /etc/mem0/compose.yaml ps --format 'table {{.Service}}\t{{.State}}\t{{.Ports}}'

SERVICE     STATE     PORTS
api         running   127.0.0.1:8888->8000/tcp
dashboard   running   127.0.0.1:3000->3000/tcp
postgres    running   5432/tcp

5432/tcp is inside the private Docker network. It is not published to the VM or the network.

Step 5: Read this VM's sign in details

Everything in this file was generated on this VM at first boot.

sudo cat /root/mem0-credentials.txt

# Mem0 - per-VM credentials generated on first boot (...). Keep this file private.
# Dashboard: open MEM0_URL and sign in with MEM0_EMAIL / MEM0_PASSWORD (change both in Settings).
# REST API:  MEM0_API_URL, header "X-API-Key: <MEM0_ADMIN_API_KEY>" (or a per-user key from API Keys).
MEM0_URL=https://<vm-ip>/
MEM0_EMAIL=admin@example.com
MEM0_PASSWORD=<MEM0_PASSWORD>
MEM0_API_URL=https://<vm-ip>/mem0
MEM0_ADMIN_API_KEY=<MEM0_ADMIN_API_KEY>
# Bundled local models (CPU, via Ollama): qwen2.5:1.5b extracts memories, mxbai-embed-large embeds them.

Step 6: Sign in to the dashboard

1. Open MEM0_URL from the credentials file in your browser. The certificate is self-signed and generated for this VM, so your browser warns you the first time. Accept it for this address, or follow Step 12 to use your own domain and a trusted certificate.
2. Sign in with MEM0_EMAIL and MEM0_PASSWORD.
3. Open Settings and change the email address to your own and the password to one you choose. The dashboard keeps you signed in with a secure, HTTP only cookie that is sent to this site only.

The dashboard's Configuration page shows the two local models as Mem0's defaults:

There is no setup wizard to complete: first boot already created the administrator account, and the wizard's registration step is closed so nobody else can claim the server (Step 9).

Step 7: Add memories

Your application talks to the REST API at MEM0_API_URL and authenticates with an API key in the X-API-Key header. The admin key from the credentials file works for everything; for applications, create a separate key per application under API Keys in the dashboard so you can revoke it on its own. Keep the key in a private curl configuration file rather than on the command line:

KEY=$(sudo sed -n 's/^MEM0_ADMIN_API_KEY=//p' /root/mem0-credentials.txt)
( umask 077; printf 'header = "X-API-Key: %s"\n' "$KEY" > ~/.mem0-api.curl )
curl -sk -K ~/.mem0-api.curl https://127.0.0.1/mem0/configure | jq -c '{llm: .llm.config.model, embedder: .embedder.config.model, dims: .vector_store.config.embedding_model_dims, api_key: .llm.config.api_key}'

{"llm":"qwen2.5:1.5b","embedder":"mxbai-embed-large","dims":1024,"api_key":"[redacted]"}

Send a conversation for a user. Mem0 extracts the facts and stores each one as a memory (this is the step that takes 15 to 25 seconds on the local model):

curl -sk -K ~/.mem0-api.curl -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"I am Sam. I cycle to work every day and I am allergic to shellfish."}],"user_id":"sam"}' \
  https://127.0.0.1/mem0/memories | jq -r '.results[] | "\(.event)  \(.memory)"'

Example output (the memories are written by the model, so your wording will differ):

ADD  User's name is Sam and they cycle to work every day
ADD  User is allergic to shellfish

Send conversations turn by turn as they happen rather than as one long transcript: the local model can miss a detail buried in a long message (in our test it kept the job from a 1,400 word message but missed an allergy mentioned in its last sentence), and a long message takes longer (72 seconds for that one).

Besides user_id, a memory can belong to an agent_id or a run_id, and you can attach your own metadata. Send "infer": false to store the messages exactly as given, without the language model (instant, but no fact extraction).

Step 8: Recall memories

Search a user's memories with a question in plain language. Search uses only the embedding model, so it answers in well under a second:

curl -sk -K ~/.mem0-api.curl -H 'Content-Type: application/json' \
  -d '{"query":"Does Sam have any food allergies?","filters":{"user_id":"sam"},"top_k":1}' \
  https://127.0.0.1/mem0/search | jq -r '.results[0].memory'

User is allergic to shellfish

Your application puts the returned memories into its own prompt, so its model knows what it learnt about this user before. List, update and delete memories the same way:

curl -sk -K ~/.mem0-api.curl "https://127.0.0.1/mem0/memories?user_id=sam" | jq -r '.results[].memory'

User's name is Sam and they cycle to work every day
User is allergic to shellfish

PUT /mem0/memories/<id> changes a memory's text, GET /mem0/memories/<id>/history shows how it changed, DELETE /mem0/memories/<id> deletes one memory and DELETE /mem0/memories?user_id=sam deletes all of a user's memories. The full API reference is at docs.mem0.ai; on this VM every path is under /mem0/ and every call needs an API key or a dashboard sign in.

In the dashboard, Memories lists what Mem0 has stored (filter by user), Entities lists the users, agents and runs that own memories, and Requests shows every API call with its status and time:

Step 9: Understand the access model

• API keys and sign in. Every REST API route needs an API key (X-API-Key) or a dashboard session token (Authorization: Bearer). Requests without one, with a wrong key or with a forged token are refused with 401. Keys are stored only as hashes.
• No setup wizard. Upstream Mem0 makes the first visitor to /setup the administrator. On this VM first boot creates the administrator, so /setup redirects to the sign in page and registration is refused with 403, both at nginx and by Mem0 itself.
• Cross-site requests are refused. The dashboard keeps its session in a cookie, so another website you visit could otherwise make your browser act on Mem0. nginx refuses, with 403, any change (POST, PUT, PATCH, DELETE) whose Origin or Referer is another site, and any request another site's page makes in the background. Following a link to the dashboard from elsewhere still opens it, and API clients such as curl or your application, which send no Origin, work normally. Mem0's CORS headers are removed, so no other website can read its responses. The session cookie is Secure, HttpOnly and SameSite=Strict.
• Network. nginx is the only public listener: it serves Mem0 on port 443 with a certificate generated for this VM, and port 80 only redirects to HTTPS. The API and dashboard listen on 127.0.0.1. PostgreSQL is on a private Docker network and requires its per-VM password. The interactive API documentation (/docs) is not served, because it loads its scripts from a third-party CDN.
• The local models. Ollama has no login of its own, so it listens only on the VM's loopback address. The Mem0 API container reaches it through the model gateway on 172.30.248.1:11435, which needs a per-VM key and passes only the OpenAI style /v1/ API (so nothing can pull or delete models through it). A firewall rule lets only the Mem0 API container reach the gateway.
• Fail closed. Mem0, Ollama and the gateway start only after first boot has written this VM's secrets, and nginx only after first boot has created the administrator and proven the access gate. If first boot fails, it removes its markers and stops everything, so nothing serves a half-configured VM. Before every start, Mem0's unit also refuses to run if a secret is missing or a default, if authentication was turned off, or if telemetry was turned on without an explicit opt-in.

You can check the gate yourself:

code() { curl -sk -o /dev/null -w '%{http_code}' "$@"; }
echo "anonymous list         : $(code 'https://127.0.0.1/mem0/memories?user_id=sam')"
echo "anonymous search       : $(code -X POST -H 'Content-Type: application/json' -d '{}' https://127.0.0.1/mem0/search)"
echo "with this VM's key     : $(code -K ~/.mem0-api.curl 'https://127.0.0.1/mem0/memories?user_id=sam')"
echo "setup wizard           : $(code https://127.0.0.1/setup)"
echo "registration           : $(code -X POST -H 'Content-Type: application/json' -d '{}' https://127.0.0.1/mem0/auth/register)"
echo "plain HTTP             : $(code http://127.0.0.1/)"
echo "cross-site POST        : $(code -K ~/.mem0-api.curl -X POST -H 'Origin: https://other-site.example' -H 'Content-Type: application/json' -d '{}' https://127.0.0.1/mem0/search)"

Expected output:

anonymous list         : 401
anonymous search       : 401
with this VM's key     : 200
setup wizard           : 302
registration           : 403
plain HTTP             : 301
cross-site POST        : 403

Outbound requests (SSRF protection). Mem0 calls the language model and embedding endpoints it is configured with, and an administrator can change those URLs. A firewall rule applied before any container starts stops the Mem0 containers from reaching the Azure Instance Metadata Service (169.254.169.254), the Azure wire server (168.63.129.16), loopback, your private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10), link-local and other reserved ranges, and every service on the VM except the model gateway. Between the containers only the connections the application needs are allowed (the API to PostgreSQL, the dashboard to the API), and the dashboard and PostgreSQL cannot leave the private network at all. Because the check is on the network packets, it also holds when a URL redirects or when a host name resolves to one of those addresses. Check it from inside the API container, the process that calls model URLs:

sudo docker exec -i mem0-api-1 python - <<'EOF'
import socket
def reach(host, port):
    try:
        socket.create_connection((host, port), timeout=5).close()
        return "open"
    except OSError:
        return "blocked"
for name, host, port in [("Azure IMDS      ", "169.254.169.254", 80),
                         ("Azure WireServer", "168.63.129.16", 80),
                         ("private network ", "10.0.0.1", 80),
                         ("model gateway   ", "172.30.248.1", 11435),
                         ("internet        ", "www.example.com", 443)]:
    print(name, reach(host, port))
EOF

Expected output:

Azure IMDS       blocked
Azure WireServer blocked
private network  blocked
model gateway    open
internet         open

Reaching a private address on purpose. If you want Mem0 to use a model behind a private endpoint on your network (for example Azure OpenAI with a private endpoint), add that address to /etc/mem0/egress-allow (one entry per line, optionally limited to a TCP port) and restart Docker. The metadata service, the wire server and loopback can never be allowed:

echo "10.20.30.40 tcp 443" | sudo tee -a /etc/mem0/egress-allow
sudo systemctl restart docker mem0

Step 10: What leaves the VM, and connecting a cloud model

By default nothing does. These settings in /etc/mem0/mem0.env (readable by root only) keep it that way:

sudo grep -E '^(OPENAI_BASE_URL|MEM0_DEFAULT_LLM_MODEL|MEM0_DEFAULT_EMBEDDER_MODEL|MEM0_TELEMETRY|AUTH_DISABLED)=' /etc/mem0/mem0.env

AUTH_DISABLED=false
OPENAI_BASE_URL=http://172.30.248.1:11435/v1
MEM0_DEFAULT_LLM_MODEL=qwen2.5:1.5b
MEM0_DEFAULT_EMBEDDER_MODEL=mxbai-embed-large
MEM0_TELEMETRY=false

• OPENAI_BASE_URL points Mem0's OpenAI client at the bundled models through the model gateway, so the default "openai" provider in the dashboard is in fact the local models
• MEM0_TELEMETRY=false stops both the Mem0 server and the mem0 library from sending anonymous usage events to PostHog. As a second layer, PostHog's hosts resolve to loopback inside the API container, and the dashboard's Next.js telemetry is off
• AUTH_DISABLED=false keeps authentication on; Mem0 refuses to start on this VM if it is changed

Switching to OpenAI. OpenAI's models extract memories faster and more reliably than the local model. Your conversations and memories are then sent to OpenAI. Edit /etc/mem0/mem0.env as root: set OPENAI_API_KEY to your key, delete the OPENAI_BASE_URL and OPENAI_API_BASE lines, and choose the models:

OPENAI_API_KEY=sk-YOUR_OPENAI_KEY
MEM0_DEFAULT_LLM_MODEL=gpt-5-mini
MEM0_DEFAULT_EMBEDDER_MODEL=text-embedding-3-small

OpenAI's embeddings have 1536 dimensions instead of the local model's 1024, so tell Mem0 to keep them in a new collection, then restart Mem0:

sudo systemctl restart mem0
curl -sk -K ~/.mem0-api.curl -H 'Content-Type: application/json' \
  -d '{"vector_store":{"config":{"embedding_model_dims":1536,"collection_name":"memories_openai"}},"embedder":{"config":{"embedding_dims":1536}}}' \
  https://127.0.0.1/mem0/configure

Memories stored with the local models stay in the original memories collection and are not searched by the new one; add them again if you need them. The local models keep running (they use no CPU while idle); to stop them, sudo systemctl disable --now ollama mem0-model-gateway. Anthropic and Google Gemini are also bundled providers: choose them on the dashboard's Configuration page with your key.

Step 11: The local models

Both models stay loaded in memory so a memory add never waits for them:

curl -s http://127.0.0.1:11434/api/ps | jq -r '.models[] | "\(.name)  \(.details.parameter_size)  \(.details.quantization_level)"' | sort

mxbai-embed-large:latest  334M  F16
qwen2.5:1.5b  1.5B  Q4_K_M

Ollama runs on the CPU only (no GPU libraries are installed) and keeps the language model's reading of Mem0's extraction instructions cached, which is why an add takes seconds rather than minutes. Larger local models extract better but are much slower on a CPU; if extraction quality matters more than privacy for your use, connect a cloud model (Step 10).

Step 12: Use your own domain and a trusted certificate

Point a DNS record at the VM's public IP, open port 80 to the internet for the certificate check, then replace the self-signed certificate with one from Let's Encrypt:

sudo apt-get install -y certbot
sudo certbot certonly --webroot -w /var/www/html -d memory.example.com
sudo sed -i \
  -e 's#/etc/mem0/tls/server.crt#/etc/letsencrypt/live/memory.example.com/fullchain.pem#' \
  -e 's#/etc/mem0/tls/server.key#/etc/letsencrypt/live/memory.example.com/privkey.pem#' \
  /etc/nginx/sites-available/mem0
sudo nginx -t && sudo systemctl reload nginx

Certbot renews the certificate automatically; add --deploy-hook "systemctl reload nginx" to the certonly command so nginx picks up each renewal.

Step 13: Day-2 operations

Logs and status.

sudo tail -n 4 /var/log/mem0-firstboot.log | cut -c28-
sudo docker compose -f /etc/mem0/compose.yaml logs --tail 3 api

The first boot log never contains a password or key.

Restart. sudo systemctl restart mem0 restarts the Mem0 containers (about 30 seconds until the dashboard answers again). sudo systemctl restart ollama restarts the model server; it reloads both models and re-reads the extraction instructions, which takes about 3 minutes on a Standard_D4s_v4.

Back up. Everything Mem0 stores (memories, embeddings, accounts, API keys, history) is under /var/lib/mem0, and its settings and secrets are in /etc/mem0. Stop Mem0 for a consistent copy:

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

Copy the archive off the VM. It contains your secrets and memories, so keep it as private as the VM itself. You can also snapshot the VM's OS disk in Azure.

Clean up old request logs. The Requests log grows with every API call. Delete entries older than 30 days (run it from cron weekly if your applications are busy):

sudo docker exec -e REQUEST_LOG_RETENTION_DAYS=30 -e PYTHONPATH=/app mem0-api-1 python scripts/prune_request_logs.py

Updates. Ubuntu security updates install automatically. The Mem0 images were built from a pinned source commit and PostgreSQL is pinned to an image digest in /etc/mem0/compose.yaml, for a repeatable deployment. cloudimg publishes new image versions with newer Mem0 releases; to move to one, back up /var/lib/mem0 and /etc/mem0, deploy the new image and restore them.

Troubleshooting.

• The browser shows 502 Bad Gateway. Mem0 is still starting (after a reboot it waits about 3 minutes for the models). Wait and reload.
• A memory add is slow or times out. The local model runs on the CPU. Use a non-burstable VM size, keep conversations short, or connect a cloud model (Step 10). On a B-series VM, check the CPU credits in the Azure Portal under the VM's Metrics.
• You forgot the dashboard password. If you never changed it, it is in /root/mem0-credentials.txt. Otherwise set a new one (the password is passed on standard input, never on a command line; use the email address you sign in with):

text read -rs -p 'New password: ' NEWPW; echo printf '%s\n' "$NEWPW" | sudo docker exec -i -e EMAIL=admin@example.com -e PYTHONPATH=/app mem0-api-1 \ sh -c 'read -r PASSWORD; export PASSWORD; exec python scripts/reset_admin_password.py' unset NEWPW - Mem0 does not start after you edited mem0.env. Run sudo /usr/local/sbin/mem0-preflight: it prints the setting it refuses and why. - First boot did not finish. Read /var/log/mem0-firstboot.log.

Support

cloudimg provides 24/7 support for this image. Contact support@cloudimg.co.uk with your VM's region and the output of sudo tail -n 50 /var/log/mem0-firstboot.log.