Extend OpenClaw for a local-first AI assistant across Arm platforms
Introduction
Understand the architecture and local data boundaries
Prepare the DGX Spark host and local services
Configure and start the OpenClaw runtime on DGX Spark
Validate memory persistence and routing with Telegram and Qdrant
Validate document RAG, web search, and proactive tasks
(Optional) Port the app to a CPU-only Armv9 system
Next Steps
Extend OpenClaw for a local-first AI assistant across Arm platforms
Introduction
Understand the architecture and local data boundaries
Prepare the DGX Spark host and local services
Configure and start the OpenClaw runtime on DGX Spark
Validate memory persistence and routing with Telegram and Qdrant
Validate document RAG, web search, and proactive tasks
(Optional) Port the app to a CPU-only Armv9 system
Next Steps
Who is this for?
This is an advanced topic for developers who want to extend OpenClaw into a customizable local-first assistant with persistent memory, document RAG, explicit browser search, deterministic routing, and proactive scheduling.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- Explain the local and external data boundaries of an OpenClaw-based runtime.
- Deploy and validate the reference runtime with local vLLM inference on NVIDIA DGX Spark.
- Verify persistent memory, document RAG, explicit browser search, deterministic routing, and proactive scheduling with Telegram and Qdrant.
- Optionally move the same application workflows to a CPU-only Armv9 system through an OpenAI-compatible llama.cpp endpoint.
Prerequisites
Before starting, you will need the following:
- An NVIDIA DGX Spark system with NVIDIA drivers, Docker and NVIDIA Container Toolkit
- Administrative access on DGX Spark
- Access to Telegram through a mobile, desktop, or web client
- Familiarity with Linux, Docker Compose, and command-line tools
- (Optional) A Radxa Orion O6 or comparable CPU-only Armv9 system running Debian 12, Docker, and at least 30 GB of memory
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
uname -m and confirm the architecture is aarch64. Use nvidia-smi to verify GPU visibility, then run docker run --rm --gpus all ubuntu nvidia-smi to confirm GPU access from containers./newbot, and copy the HTTP API token it returns. Send a test message to your new bot, call curl "https://api.telegram.org/bot<your-telegram-bot-token>/getUpdates", and copy message.chat.id. Set both values in .env before starting the services./mem #home The boiler should be inspected every October. in Telegram, then ask /rag memory: When should the boiler be inspected?. You should see October in the response. Confirm the record directly in the personal_tracker_memory Qdrant collection with the documented payload query./knowledge caption. Copy the returned filename, wait for indexing, and ask /rag <returned-file-name> a question about the file. Check the personal_knowledge_base Qdrant payload for that filename to confirm ingestion./cron add, confirm it’s enabled with /cron list, and wait for the configured time. Check Telegram for the notification and inspect docker logs --tail 30 openclaw-cron for the [cron] dynamic job sent entry. You can use /cron run <job-id> to test the job without waiting.