Openclaw Dashboard and Web UI Guide: Gateway Run, Status, Access
Use the Openclaw dashboard Web UI and Gateway in the right order before debugging setup: what each does, when to use gateway run, and how to keep admin access scoped.
The dashboard depends on the Gateway
If you are searching for the Openclaw dashboard or Openclaw Web UI, the fastest way to debug setup is to separate two things:
- the Gateway is the runtime server that handles channels, sessions, hooks, and related Openclaw work
- the dashboard is the browser Control UI served by the Gateway
When the dashboard does not load, the failure is often earlier in the chain. The Gateway may not be configured, running, reachable, or authenticated correctly.
First prove the Gateway path
After onboarding, check the Gateway before adding channel setup complexity.
openclaw gateway status
If you need a foreground run while you inspect startup behavior, the Gateway CLI supports:
openclaw gateway
openclaw gateway run
The official docs note that the Gateway expects local mode configuration for normal local startup. If configuration is missing or clobbered, repair the setup instead of assuming the dashboard alone is broken.
Then open the dashboard
For a configured local Gateway, use:
openclaw dashboard
The dashboard command opens or prints the Control UI path using the current auth context. The local dashboard usually lives on the local Gateway address.
If you are on a headless or remote host, the useful question is not only "what URL exists?" It is "how should the admin surface be reached safely?"
The dashboard is an admin surface
The Openclaw docs describe the dashboard as a Control UI with chat, config, and execution approval context.
That makes it different from a public landing page.
Good defaults:
- keep local dashboard access local when possible
- use controlled remote access paths rather than public exposure
- protect Gateway auth tokens and passwords
- do not paste secrets into public logs or screenshots
If you are debugging a remote dashboard, treat auth and network exposure as part of the issue.
Dashboard commands people confuse
| Command | Purpose |
|---|---|
openclaw gateway status | check Gateway service state |
openclaw gateway run | run the Gateway in the foreground |
openclaw dashboard | open or print the dashboard path |
openclaw dashboard --no-open | print the dashboard path without launching a browser |
The dashboard command is not a substitute for onboarding and Gateway configuration.
If the dashboard changed after an upgrade, verify the release and runtime path with the Openclaw update guide before you treat it as a Web UI-only bug.
Local troubleshooting order
Use this order:
- run onboarding or setup
- check Gateway status
- run the Gateway in the foreground if startup errors need inspection
- open the dashboard
- add one channel only after the base runtime behaves
That keeps provider credentials, Gateway configuration, dashboard auth, and channel setup from getting mixed into one unclear failure.
When a managed runtime helps
The dashboard and Gateway concepts still matter when you use hosted Openclaw.
The difference is operational ownership. A hosted path reduces the amount of machine setup, daemon management, and exposure work you have to solve before the workflow itself becomes useful.
Use Openclaw hosting when the goal is a reliable hosted runtime. Use the local Openclaw install guide when the goal is learning the commands on your own machine.
FAQ
What is the Openclaw dashboard?
It is the browser Control UI served by the Gateway for configured Openclaw access and management.
Is the dashboard the Openclaw Web UI?
Yes. When users search for the Web UI, the dashboard is the browser Control UI path to check after the Gateway works.
What does openclaw gateway run do?
It runs a local Gateway process in the foreground so you can observe runtime behavior directly.
Should I expose the dashboard publicly?
Treat the dashboard as an admin surface. Use a controlled access path and follow the official security guidance for remote exposure.