OC
OpenClaw
Dashboard

2026-04-14-0052.md

/home/ubuntu/.openclaw/workspace/memory/2026-04-14-0052.md
Back

Session: 2026-04-14 00:52:17 UTC

  • Session Key: agent:main:main
  • Session ID: 596166ae-a1db-4548-ab08-54639f075819
  • Source: webchat

Conversation Summary

assistant: Yes — set EC2_HOST to:

ec2-13-218-85-126.compute-1.amazonaws.com

That’s the hostname portion of ubuntu@… (no ubuntu@ prefix).

Also set:

  • EC2_USER = ubuntu
  • EC2_SSH_KEY = the private key contents (the PEM), e.g. starts with -----BEGIN ... PRIVATE KEY-----

Tip: make sure GitHub Actions can SSH to that host (security group allows inbound TCP 22 from GitHub Actions IPs or from anywhere, depending on how you’ve locked it down). user: i did that, can you check if it's working now? there should be a push just now [message_id: f8c40aa1-93dd-4068-803f-32d5f9b3d8d3] assistant: Yep — it’s working now.

  • The latest Deploy (EC2) run 24373699182 finished successfully:
    https://github.com/elite-flacco/openclaw-dashboard/actions/runs/24373699182

  • EC2 confirms it deployed that exact commit:

    • /opt/openclaw-dashboard/current/BUILD_INFO shows commit=4669348f63ea865eac98530a053bc37e6d269311
    • current symlink points to /opt/openclaw-dashboard/releases/4669348f63ea865eac98530a053bc37e6d269311

  • openclaw-dashboard.service restarted and is active (running), serving on 127.0.0.1:3579. user: System: [2026-04-14 00:12:42 UTC] Exec completed (crisp-co, code 0) :: {"conclusion":"","status":"in_progress","updatedAt":"2026-04-14T00:11:46Z","url":"https://github.com/elite-flacco/openclaw-dashboard/actions/runs/24373663567"} run 24373663567 is still in progress; logs will be available when it is complete System: [2026-04-14 00:13:06 UTC] Exec completed (quiet-re, code 0) :: ODE24=true environment variable on the runner or in your workflow file. Once Node.js 24 becomes the default, you can temporarily opt out by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/ build-and-deploy: .github#3 X The operation was canceled. build-and-deploy: .github#63 System: [2026-04-14 00:14:34 UTC] Exec completed (briny-re, code 0) :: 99182 Triggered via push about 1 minute ago JOBS ✓ build-and-deploy in 46s (ID 71182584612) ✓ Set up job ✓ Checkout ✓ Setup Node ✓ Install ✓ Build + package (standalone) ✓ Upload build artifact ✓ Add SSH key ✓ Add EC2 host to known_hosts ✓ Copy artifact to EC2 ✓ Deploy on EC2 (untar + restart systemd) ✓ Post Add SSH key ✓ Post Setup Node ✓ Post Checkout ✓ Complete job System: [2026-04-14 00:15:13 UTC] Cron: Dashboard Activity Sync: ran npm run sync:activity on main after git pull --ff-only.

  • sync result: added=0, total=1115, ok=true

  • git status: clean (no changes to data/activity.json or data/activity-state.json)

No commit/push needed.

it's not clear to me from the doc you just wrote how the service works... how does it detect a new change and restart the service? [message_id: 13100b42-5999-44f8-b9d2-ac81c9107ea6] assistant: It doesn’t “detect changes” on the EC2 box anymore.

What triggers a restart now

GitHub Actions is the thing that notices changes:

  1. You push to main (remote).
  2. GitHub Actions workflow .github/workflows/deploy-ec2.yml runs automatically on that push.
  3. At the end of the workflow, it SSHes into the EC2 box and explicitly runs:
    • untar into /opt/openclaw-dashboard/releases/<sha>
    • update /opt/openclaw-dashboard/current symlink
    • sudo systemctl restart openclaw-dashboard.service

So the “detection” is: GitHub sees a push event, not the server polling git.

What systemd is doing

openclaw-dashboard.service just runs whatever the current symlink points at:

  • ExecStart = node /opt/openclaw-dashboard/current/server.js

When the workflow restarts the service, systemd stops the old process and starts a new one, which then reads the new server.js from the updated current symlink.

Why the old behavior was confusing

Previously the openclaw-dashboard-update.timer on EC2 would:

  • pull from git every ~5 min
  • rebuild on EC2
  • restart

That was the “server detects changes” model. We disabled that timer, so only CI deploys cause restarts.

If you want, I can tweak the doc to add a short “Trigger flow” section right at the top that spells this out in 3 bullets. user: yes pls. and maybe we should also update the old doc openclaw-dashboard-auto-deploy.md so that you don't get confused abt how it's working now [message_id: c6babfbf-c677-467a-b08a-d27668a44157] assistant: Updated both docs and pushed.

  • docs/openclaw-dashboard-deploy.md now has an explicit section up top: “How it detects changes (trigger) + restarts” — i.e. GitHub push event triggers Actions; Actions SSHes to EC2 and runs systemctl restart; EC2 does no polling.

  • docs/openclaw-dashboard-auto-deploy.md now starts with a bold warning that it’s deprecated + currently disabled, and points to the new doc so nobody (including me) misreads it later. user: System: [2026-04-14 00:30:10 UTC] Cron: Sync ran cleanly.

  • npm run sync:activity → added: 0, total: 1115

  • git status → no changes (nothing to commit/push) System: [2026-04-14 00:45:09 UTC] Cron: Ran the Dashboard Activity Sync worker:

  • git checkout main ✅

  • git pull --ff-only ✅ (pulled latest changes)

  • npm run sync:activity ✅ → added: 0, total: 1115

git status shows no changes, so there was nothing to commit/push.

i also need to add a GITHUB_TOKEN for this process that runs this dashboard. what do we do [message_id: adf956f9-e411-4277-a568-99309e19e67b] assistant: You’ve got two different “GitHub tokens” in play here, so first we pick which you mean:

1) Token for GitHub Actions deploy (CI → EC2)

You do not need a GITHUB_TOKEN secret for that.

  • GitHub automatically provides GITHUB_TOKEN to workflows.
  • Our workflow uses checkout, npm ci, and scp/ssh with your EC2_SSH_KEY. No extra token required.

2) Token for the dashboard app running on EC2 (so the UI can call GitHub)

If you want the running dashboard to access GitHub (e.g. list repos/PRs, read workflow runs, etc.), then yes: you need a token available as an environment variable for the openclaw-dashboard.service.

What we should do (recommended)

Use a GitHub Fine-grained Personal Access Token (PAT), not classic.

  1. Create a fine‑grained PAT in GitHub:
  • Settings → Developer settings → Personal access tokens → Fine‑grained
  • Scope it to the repos you need (likely openclaw-dashboard + anything the dashboard reads)
  • Permissions (minimum): usually Contents: Read, plus whatever else you actually call (Pull requests: Read, Actions: Read, etc.)
  1. Put it on EC2 in a root-owned env file (so it’s not in the unit file or repo):
  • Create: /etc/openclaw-dashboard.env
  • Contents: 
    GITHUB_TOKEN=ghp_...
  • Permissions: chmod 600 and owned by root.
  1. Tell systemd to load it:
  • Add to /etc/systemd/system/openclaw-dashboard.service: 
    EnvironmentFile=/etc/openclaw-dashboard.env
  • Then:
    • sudo systemctl daemon-reload
    • sudo systemctl restart openclaw-dashboard.service

That’s it — the running Node process will have process.env.GITHUB_TOKEN.

One clarifying question

Do you want the token to access:

  • just public data, or
  • private repos/org data too?

If you tell me which GitHub endpoints/features the dashboard needs (repos list, PRs, checks, Actions runs, etc.), I’ll tell you the exact minimal fine‑grained permissions so we don’t over-scope it. user: i created the token already [message_id: 4da010c6-4908-4504-b0f9-c7285ca67ada] assistant: Cool — don’t paste it here.

To wire it into the running dashboard service safely, do this on the EC2 box:

1) Create an env file (root-only)

sudo sh -c 'umask 077 && cat > /etc/openclaw-dashboard.env'

Now it’ll wait for input. Paste one line:

GITHUB_TOKEN=github_pat_...

Then press Ctrl+D to save.

Verify perms:

sudo ls -la /etc/openclaw-dashboard.env

You want -rw------- (600) and owned by root.

2) Tell systemd to load it

Edit the unit:

sudo systemctl edit openclaw-dashboard.service

Add:

[Service]
EnvironmentFile=/etc/openclaw-dashboard.env

Save/exit.

3) Reload + restart

sudo systemctl daemon-reload
sudo systemctl restart openclaw-dashboard.service
sudo systemctl status openclaw-dashboard.service

4) (Optional) confirm the process sees it

If the app has an endpoint/page that uses GitHub, just load that and confirm it works. If you want a purely-server-side check without printing the token, I can add a tiny “token present?” health check endpoint in the dashboard code.

If you want me to update the deploy doc to include this “runtime GitHub token” step (so future-you doesn’t forget), say so and I’ll patch it. user: can i just do 1 and you can help with rest? and yes we should also update the doc [message_id: 9b3c4dc0-12b8-4d4a-98ee-95d4993affd7] assistant: Yep — do (1) and then tell me “done” (don’t paste the token).

As soon as you confirm the file exists, I’ll do the rest on the EC2 host:

  • add EnvironmentFile=/etc/openclaw-dashboard.env to openclaw-dashboard.service
  • daemon-reload + restart the service
  • verify the service is healthy

Also: I updated the deploy doc to include this token setup and pushed it (docs/openclaw-dashboard-deploy.md). user: done [message_id: 7bcd28fb-2410-4bc7-b3e6-5a93a6da74c2] assistant: Nice — I see /etc/openclaw-dashboard.env exists with correct permissions (600, root-owned).

I couldn’t use systemctl edit non-interactively (TTY limitation), so I set it up via a systemd drop-in instead:

  • Created: /etc/systemd/system/openclaw-dashboard.service.d/env.conf 
    [Service]
EnvironmentFile=/etc/openclaw-dashboard.env
  • Ran systemctl daemon-reload
  • Restarted openclaw-dashboard.service

Status now:

  • service is active (running)
  • dashboard responds on http://127.0.0.1:3579 ✅
  • systemctl cat openclaw-dashboard.service shows the env drop-in loaded ✅

If you tell me which page/feature in the dashboard should hit GitHub, I can sanity-check that it’s actually authenticating (without ever printing the token).