Launch and connect
Recommended: t3.large · 8 GiB RAM · 24 GiB encrypted gp3 storage. The supported minimum is t3.medium with 4 GiB RAM. Choose Ubuntu 24.04 x86_64 in us-east-1.
Use an instance profile with Session Manager permissions and outbound access to its endpoints. The application needs no public inbound port. A Session Manager session starts as ssm-user; switch to the application user before the commands below:
sudo -iu ubuntu
sushi-mem0-api GET /health
less /opt/sushi/docs/README.mdThe API requires authentication and listens only on https://127.0.0.1:8443. There is no browser dashboard. A healthy but unconfigured provider is expected until you complete provider setup.
Store application memories on your own EC2 instance, retrieve exact facts by ID, and search them using embeddings. This image packages the Apache-2.0 Mem0 OSS Python library with a Software Sushi authentication and service adapter. Each API user has a separate local Qdrant store and SQLite history under /var/lib/mem0/users. The default add operation stores your text exactly. Optional infer: true asks your configured chat provider to extract facts before storage.
This is paid repackaged open-source software. Additional charges apply for the Software Sushi packaging and maintenance. EC2, EBS and your model provider are billed separately. This image is independent of Mem0's hosted service and does not include its hosted dashboard, enterprise control plane, graph memory or managed-service subscription. No model weights or provider keys are included.
Use Ubuntu 24.04 x86_64 on t3.medium or larger, with at least 4 GiB RAM and 24 GiB EBS. The service processes one operation at a time, supports up to 100 configured users, and is intended for a single instance. It provides no cluster replication or automatic backups. Size memory, disk and backups for your workload.
Connect and check startup
Connect with AWS Systems Manager Session Manager, or SSH as ubuntu through your approved administrative network. An instance profile with Session Manager access and network access to the SSM endpoints is required for that connection method. No public application port is required.
sushi-mem0-api GET /healthThe API listens on HTTPS 127.0.0.1:8443 and requires authentication for every route, including health. It has no browser dashboard. The client trusts the per-instance certificate and reads its credentials from ~/.config/sushi/mem0/access.json; it never puts them in command arguments. provider_configured: false means the server is running and awaits provider setup. Do not print or share access files or the TLS key.
Configure your model provider
Use an OpenAI-compatible endpoint supporting /embeddings and, for optional extraction, /chat/completions with JSON output. The provider must accept the configured embedding dimensions. HTTPS is required for remote providers; HTTP is accepted only for localhost. A local provider must already be installed and listening on this instance. The image does not install one.
Run the interactive helper as ubuntu. Enter your actual provider base URL, embedding model and dimension, chat model, and API key. The key prompt is hidden. The output file must not already exist.
python3 /opt/mem0/provider-setup.py --output "$HOME/.config/sushi/mem0/provider.json"
sudo systemctl stop sushi-mem0-api.service
sudo sushi-mem0-admin configure --file "$HOME/.config/sushi/mem0/provider.json"
sudo systemctl start sushi-mem0-api.service
sushi-mem0-api GET /healthThe service copy is /etc/mem0/provider.json, readable only by root and the service group. Your original provider file stays under your control. Keep it protected or remove your copy after applying it. Memory text and queries are sent to the configured provider for embedding; infer: true also sends text to its chat model. Review that provider's data handling and charges before using real information. Upstream Mem0 telemetry is disabled.
Once vectors exist, keep the same provider URL, embedding model and dimensions. The adapter refuses an incompatible change. Rotating the API key or changing the chat model is supported: collect a new file, stop the service, apply it and start the service. It does not migrate existing vectors between embedding models.
Store, retrieve and search
Create a synthetic request file and call the API:
mkdir -p "$HOME/mem0-results"
umask 077
printf '%s\n' '{"text":"My synthetic order contains 3 boxes at 14 dollars, total 42 dollars.","infer":false}' \
> "$HOME/mem0-results/add.json"
sushi-mem0-api POST /memories --input "$HOME/mem0-results/add.json"
sushi-mem0-api GET /memories
printf '%s\n' '{"query":"synthetic order","limit":5}' > "$HOME/mem0-results/search.json"
sushi-mem0-api POST /search --input "$HOME/mem0-results/search.json"POST /memories accepts text (1–8000 characters) and optional boolean infer (default false). POST /search accepts query and optional limit (1–100). GET /memories lists up to 100 memories. Use the ID returned in results with GET /memories/<id> or DELETE /memories/<id>. Search returns similarity results; an ID lookup returns the exact stored text. The API user always comes from authentication. Request-supplied tenant selectors and arbitrary filters are rejected.
Run the complete synthetic customer walkthrough:
sudo -iu ubuntu bash /opt/sushi/docs/demo.shIt stores an exact fact, searches it, retrieves it, checks another user's lack of access, saves request/response JSON and hashes under ~/mem0-results, and rereads the files independently. It prints SUSHI_CUSTOMER_DEMO_PASSED only after those checks succeed. A real configured embedding provider is required and may charge for the requests. The separate isolation-check account is solely for synthetic access checks; its credential is ~/.config/sushi/mem0/isolation.json.
Add an API user
An administrator can generate another credential export. Run with a new user name and a new output file, then restart to load it:
sudo systemctl stop sushi-mem0-api.service
sudo sushi-mem0-admin add-user --user application-a --output /root/mem0-application-a.json
sudo systemctl start sushi-mem0-api.serviceDeliver that mode-0600 file and the instance's public certificate to the intended application through your secure credential channel. The client accepts an owned credential file using --profile. The service's root-managed user mapping is /etc/mem0/identity/users.json; clients never choose their own scope. There is no self-service signup. Root administrators control all users and data.
Persistence, backup and recovery
Memories and SQLite history survive sudo systemctl restart sushi-mem0-api.service and instance reboots on the same EBS volume. EC2 termination and EBS deletion can destroy them. Back up /var/lib/mem0 and /etc/mem0 together while the service is stopped; protect backups as credentials and application data. Restore only to a compatible installation and preserve the embedding identity. Do not run two processes against the same embedded Qdrant directory.
sudo systemctl status sushi-mem0-firstboot.service sushi-mem0-api.service
sudo journalctl -u sushi-mem0-firstboot.service -u sushi-mem0-api.service --boot --no-pagerHTTP 401 indicates credentials failed; 400 indicates invalid input; 404 indicates an unavailable memory or route; 429 means another operation is running; 503 means the provider is unconfigured; 502 means a provider or storage operation failed. Check provider URL, credentials, model support, quotas and free disk space before retrying. Failed adds can have partially persisted upstream work: list memories before retrying to avoid duplicates. No request body or provider error body is written to the service journal. Requests are not retried automatically by the adapter's provider clients.
First boot generates the TLS identity and two access credentials. A partial /etc/mem0/identity.partial is retained for diagnosis and is never silently overwritten. Preserve it and any existing data before recovery; do not delete identity directories to repair a running installation. Restore matching identity and customer credential files from your backup. The generated certificate lasts 365 days; renew it before expiry, keeping SANs for localhost and 127.0.0.1, then update the trusted public certificate in ~/.config/sushi/mem0/server.crt and restart the API. Keep server.key root:mem0 mode 0640.
Original upstream source archives and exact dependency sources are retained in /opt/mem0/sources; wheel payloads in /opt/mem0/wheels; licenses and notices in /usr/share/doc/mem0. Upstream documentation is available at Mem0 upstream source and documentation. Software Sushi provides the packaging; upstream project names and trademarks remain with their respective owners.
