/
Published on 19.03.2026
TLDR: OpenClaw v2026.3.8 and v2026.3.13 landed a wave of UI improvements across the dashboard, mobile apps, and terminal, all driven by community contributors. None of them are headline features, but together they make the product feel significantly more finished.
I opened the OpenClaw dashboard Monday and something felt different. Similar layout and structure, but everything just worked better. Smoother transitions on mobile. Fewer weird rendering glitches. Settings that made sense on first glance. Then I checked the release notes. It turns out v2026.3.8 and v2026.3.13 landed a bunch of UI changes across the dashboard, mobile apps, and terminal. None of them are headline feature material. But taken together, they make OpenClaw feel more finished.
The most significant change is the new mobile navigation drawer. On screens at or below 1100px, the sidebar now slides over as a drawer instead of just disappearing. There was also a gap in the old design between 769px and 1100px where the toggle visibility broke. That is fixed now. Beyond the drawer, contributor BunsDev restructured the top nav and sidebar with a brand eyebrow, a persistent branding strip above the navigation. The chat model selection also got a proper picker with optimistic caching and rollback, so switching models mid-conversation feels snappy instead of janky.
A few other dashboard fixes are worth calling out. The chat history reload storm was fixed. If you have had the dashboard freeze up during tool-heavy agent runs, this was why. Every live tool result was triggering a full chat history reload. Now it only refreshes persisted history on the final event. Oversized replies are readable again. Long plain-text replies used to get crammed into capped gray code blocks. They render as normal paragraphs now. The new messages pill stopped being giant. A CSS class got dropped, causing the scroll pill to render as a full-screen SVG overlay. Subtle bug, visible consequence. Control UI auth works on plain HTTP now. Shared token and password auth on LAN or reverse-proxy setups was silently dropping before the WebSocket handshake.
The Android app got a redesigned chat settings sheet from obviyus. Endpoint and status merged into one grouped card with icons, context-aware connect and disconnect buttons, role labels renamed to You, OpenClaw, and System instead of the old generic names, and streaming labeled as OpenClaw Live. The old settings view had nine sections. The new one has six. Node info lives in a single Device card, permissions are grouped into Media, Notifications, and Data Access cards, and Screen plus Debug got combined into Preferences. They also swapped the QR scanner to Google Code Scanner for onboarding.
New iOS users used to get dumped straight into the QR scanner the moment they opened the app. The new welcome pager by ngutman adds a first-run flow before gateway setup. It stops auto-opening the scanner and shows pairing instructions on the connect step. Small change, but it means people actually know what they are looking at before being asked to point their camera at something.
For light theme holdouts, the TUI previously assumed dark backgrounds, and its colors were nearly invisible on terminals with light themes. A pull request by ademczuk added auto-detection of light terminal backgrounds via COLORFGBG, with proper sRGB linearization and WCAG 2.1 contrast ratio calculations. It picks whichever text palette, dark or light, has higher contrast against the detected background. If auto-detection does not work for your setup, there is a manual override.
The v2026.3.13 release alone had 22 new contributors making their first PRs. People are not just filing issues. They are shipping interface improvements. Individually, these are all small fixes. Together, they add up to a version of OpenClaw that just feels more finished.
TLDR: OpenClaw is a self-hosted AI assistant that runs under your control instead of inside a hosted SaaS platform. This guide covers local installation, cloud deployment via Docker and Sevalla, and the security tradeoffs you need to understand before going live.
OpenClaw is a self-hosted AI assistant designed to run under your control instead of inside a hosted SaaS platform. It can connect to messaging interfaces, local tools, and model providers while keeping execution and data closer to your own infrastructure. The project is actively developed, and the current ecosystem revolves around a CLI-driven setup flow, onboarding wizard, and multiple deployment paths ranging from local installs to containerized or cloud-hosted setups.
Before touching installation commands, it helps to understand the runtime model. OpenClaw is essentially a local-first AI assistant that runs as a service and exposes interaction through chat interfaces and a gateway architecture. The gateway acts as the operational core, handling communication between messaging platforms, models, and local capabilities. In practical terms, deploying OpenClaw means deploying three layers: the CLI and runtime that launches and manages the assistant, the configuration and onboarding where you select model providers and integrations, and the persistence and execution context that determines whether OpenClaw runs on your laptop, a VPS, or inside a container.
Because OpenClaw runs with access to local resources, deployment decisions are not only about convenience but also about security boundaries. Treat it as an administrative system, not just a chatbot.
The simplest route is to install it directly on a local machine. This is ideal for experimentation, private workflows, or development because onboarding is fast and maintenance is minimal. The installer script handles environment detection, dependency setup, and launching the onboarding wizard. If you already maintain a Node environment, you can install it directly using npm and then run the onboarding process. The CLI is then used to run onboarding and optionally install a daemon for persistent background execution.
For cloud deployment, a practical approach is containerized deployment using Docker. This provides reproducibility and cleaner dependency isolation. Docker setups are particularly useful if you want predictable upgrades or easy migration between machines. The article walks through deploying on Sevalla, a developer-friendly PaaS provider, by creating a Docker image application, adding your API key as an environment variable, and deploying. Once successful, you interact with the UI through the provided URL.
There are many ways to interact with the agent once it is set up. You can configure a Telegram bot to interact with your agent. The agent will try to do tasks similar to a human assistant. Its capabilities depend on how much access you provide. You can ask it to clean your inbox, watch a website for new articles, and perform many other tasks. But providing OpenClaw access to your critical apps or files is not ideal or secure. This is still a system in its early stages, and the risk of it making a mistake or exposing your private information is high.
Security considerations matter because OpenClaw can execute tasks and access system resources. The safest baseline is to bind services to localhost and access them through secure tunnels when remote control is required. When deploying on a VPS, harden the host like any administrative service. Use non-root users, keep packages updated, restrict inbound ports, and monitor logs. If you are integrating messaging channels, treat tokens and API keys as sensitive secrets and avoid storing them in plaintext configuration.
Deploying your own OpenClaw agent is ultimately about taking control of how your AI assistant works, where it runs, and how it fits into your daily workflows. While the setup process is straightforward, the real value comes from understanding the choices you make along the way.
OpenClaw's UI Just Got a Quiet Overhaul | How to Deploy Your Own 24/7 AI Agent with OpenClaw