# builderz-labs/marketing-dashboard: a self-hosted marketing ops control center for human and agent workflows

> A local-first Next.js and SQLite dashboard that puts CRM, outreach, content, analytics, approvals and OpenClaw agent activity behind one operator-led interface. It is alpha software with writeback disabled by default, so the question is whether you want a control plane or a reporting layer.

**builderz-labs/marketing-dashboard** — Local-first marketing operations control center for CRM, outreach, content, analytics, approvals, automations, and agent workflows.

- Repository: https://github.com/builderz-labs/marketing-dashboard
- Website: https://www.nyk.dev/oss/marketing-dashboard
- Stars: 469 · Forks: 17
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/builderz-labs-marketing-dashboard

## The gap marketing-dashboard is trying to close

Most marketing stacks are a spreadsheet for the pipeline, a sequence tool for outreach, a CMS for content, a separate analytics tab, and a chat thread where approvals happen. Nothing shares an identifier. Marketing Dashboard's pitch is that all of those surfaces live in one self-hosted application backed by a single SQLite file, and that agent activity sits alongside human activity rather than in a separate console. The README describes it as "a local-first marketing operations control center for teams running human and agent workflows," and the topic list (crm, outreach, analytics, ai-agents, openclaw) matches that framing.

The audience is narrower than the word marketing suggests. This is for a small team or a solo operator who is already comfortable running a Node process on a private host, who wants to see what an agent squad is doing before it does it, and who would rather read a SQLite file than trust a vendor's export. It is not aimed at a marketing department that wants a login and a support contract. The dashboard is explicitly operator-led: the README says approval, pause, writeback and host-access controls "remain visible instead of being hidden behind autonomous execution." That is a design stance, and it costs you clicks.

## Next.js, SQLite and the OpenClaw discovery path

The architecture table in the README is short and specific. Application: Next.js 16 App Router, React 19, TypeScript. Interface: Tailwind CSS 4, Recharts, Zustand. State: SQLite through better-sqlite3. Authentication: session cookie, API key, optional Google OAuth. Agent connection: OpenClaw CLI and filesystem discovery. Deployment: local process, standalone build, or private HTTPS host.

The data flow follows from that. There is no application server to provision and no managed database. State lives under HERMES_STATE_DIR, which defaults to ./state, and the database path can be overridden with HERMES_DB_PATH (the .env.example shows ./state/hermes.db as the default). Provider connectors are optional and read credentials from server-side environment variables, so Plausible, GA4, Gmail, Mailchimp, Sanity, Helius, X and LinkedIn are all things you switch on rather than things the app assumes.

The agent side is the part worth understanding before you install. Marketing Dashboard does not embed an agent runtime. It discovers OpenClaw instances on the filesystem. HERMES_OPENCLAW_HOME defaults to ~/.openclaw and HERMES_DEFAULT_INSTANCE defaults to default. For more than one instance you supply HERMES_OPENCLAW_INSTANCES as a JSON array, and the example in .env.example shows entries with id, label, openclawHome and an optional cronUser. That means the dashboard's agent view is only as good as the directory layout it is pointed at. If your agents do not write into an OpenClaw home the dashboard can read, the Agents section has nothing to show.

One detail worth flagging: environment variables retain the HERMES_* prefix for backward compatibility, and the package name in package.json is hermes-dashboard at version 0.2.0. The public project name changed; the identifiers did not. Anyone writing deployment tooling should expect both names in the same repository.

## Installing it and getting to the first screen

The README lists Node.js 20 and pnpm 10 as requirements, plus a local machine or private host that can persist SQLite state. The quick start clones the repository, enables corepack, installs from the frozen lockfile, bootstraps the environment file, and starts the dev server.

```bash
git clone https://github.com/builderz-labs/marketing-dashboard.git
cd marketing-dashboard
corepack enable
pnpm install --frozen-lockfile
pnpm env:bootstrap
pnpm dev
```

After pnpm dev finishes compiling, the dashboard is served at http://localhost:3000. The bootstrap step is what copies .env.example to .env.local; the README tells you to change the example credentials before starting the application, so open .env.local and set the four required values.

```bash
AUTH_USER=admin
AUTH_PASS=change-me-to-a-long-password
API_KEY=change-me-to-a-random-secret
AUTH_COOKIE_SECURE=false
```

AUTH_PASS has a minimum length of 10 characters. API_KEY authenticates API and webhook paths, including the Telegram webhook, so it is not a value to leave at the example string. AUTH_COOKIE_SECURE stays false for plain HTTP and becomes true on HTTPS deployments.

The first login is seeded from AUTH_USER and AUTH_PASS when the users table is empty. That is a one-time event: once a row exists, changing the environment variables will not reset the account. If you start the app before editing .env.local, you have seeded the example credentials and will need to deal with the database rather than the file.

The writeback flags are a separate decision. HERMES_ALLOW_POLICY_WRITE, HERMES_ALLOW_CRON_WRITE and HERMES_ALLOW_WORKSPACE_WRITE all default to false in .env.example, with the comment "disabled by default for template safety." Leave them there for the first run. HERMES_HOST_LOCK defaults to local, which the .env.example describes as localhost, 127.0.0.1, *.ts.net and 100.* Tailscale hosts. If your team reaches the dashboard over a LAN address or a custom domain, the default lock will reject the request, and the fix is either an explicit comma-separated allowlist or off.

## Alpha status, the writeback boundary, and where it breaks

The README opens with a status block: "alpha. The working surface is broad, but APIs, schemas, and configuration may change between releases." There are no retrieved releases to pin against, and the version in package.json is 0.2.0. Treat any integration you build against the HTTP surface as something you will re-test after an upgrade, not something you can freeze.

The second limitation is structural. SQLite through better-sqlite3 means a single writer on a single host. That is a good fit for a private deployment and a bad fit for a team that wants several people editing the same pipeline from different machines with any expectation of concurrency. The README's deployment options are local process, standalone build, or private HTTPS host. There is no mention of replication, a hosted tier, or per-user data isolation. Authentication covers session cookies, API keys and optional Google OAuth, and the .env.example shows optional GOOGLE_AUTH_ALLOWED_EMAILS and GOOGLE_AUTH_ALLOWED_DOMAINS restrictions, but the README does not describe role separation between users.

The third limitation is the one that will bite in practice: the writeback flags are off, and turning one on grants the dashboard the ability to modify files on your host. HERMES_ALLOW_POLICY_WRITE, HERMES_ALLOW_CRON_WRITE and HERMES_ALLOW_WORKSPACE_WRITE each open a different write path, and the README's own guidance is to leave them disabled until the write paths are required and reviewed. A dashboard that can rewrite cron files is a dashboard that can schedule work you did not intend. This is the correct default, but it means the first version you run is read-mostly, and anyone expecting the app to manage campaigns end to end on day one will be disappointed.

Finally, the project is the wrong tool if you want a reporting layer over data you already have. There is no documented bulk import path in the README, and the CRM surface is leads, sources, pipeline stages, lead quality and record details. If your pipeline lives in a SaaS CRM, you are looking at a second place to keep it.

## How it differs from BI dashboards and hosted marketing suites

The related searches around this project mix it up with Power BI, Tableau and Excel templates, which is a category error worth correcting. A Power BI or Tableau dashboard is a read-only presentation layer: you point it at a warehouse, model the data, and publish charts. It does not store leads, it does not run sequences, and it does not have an approvals queue. Marketing Dashboard stores its own state in SQLite and lets you act on it. The overlap is the analytics tab, which is one of six areas in the README's table.

Against a hosted marketing suite, the difference is where the data lives and who can change it. A hosted suite owns the database, ships a stable API, and handles upgrades for you. Marketing Dashboard keeps state on your host, exposes the SQLite file, and asks you to review each write path before enabling it. The trade is operational burden for control: you get to read the database, and you also get to back it up.

Against a plain spreadsheet, the honest comparison is the agent surface. If you are not running OpenClaw agents, the CRM and content calendar here are competing with a well-structured sheet, and the sheet wins on setup time. The reason to run this instead is the OpenClaw instance discovery, squads, workspaces, sessions and communications view, plus the cron and template automations that sit next to it. That is the part a spreadsheet cannot do.

## Licence, upgrades and what maintenance actually costs

The licence is MIT, and the repository ships a THIRD_PARTY_NOTICES.md that records dependency notices. MIT is permissive, so the practical implication is that you can modify and redistribute the code, including as part of a derived template, provided you keep the notice. That is not legal advice; if you plan to redistribute a modified version commercially, read the licence text and the third-party notices yourself.

The repository has a template export path for exactly that case. scripts/template-audit.sh runs before sharing, and scripts/template-export.sh writes to a target directory. The README states the export excludes environment files, databases, build output, dependency directories, test artifacts and runtime state. That is a useful guard, but it also tells you what not to commit: your .env.local and your state directory.

Upgrade cost is the real ongoing expense. The README's development block runs pnpm lint, pnpm typecheck, pnpm test, pnpm build, pnpm test:e2e and the template audit, and CI runs the same set. Standalone deployment is pnpm build:standalone followed by pnpm start, with systemd and 1Password examples under ops/. There is no migration tooling described, so a schema change between alpha releases is something you discover by running the build and the tests against your own state directory. The last push to the repository was on 2026-08-25, and the repository is not archived.

## Conclusion

Adopt it if you already run OpenClaw agents or have outgrown spreadsheets and want CRM, outreach, content and approvals in one self-hosted surface you can read before you write. Do not adopt it if you need a stable API contract, a hosted product, or per-user data isolation, because the README labels the project alpha and warns that APIs, schemas and configuration may change between releases. Before you commit, verify three things on your own machine: that pnpm env:bootstrap produces a .env.local with the AUTH_PASS you actually want, that HERMES_HOST_LOCK=local still lets you reach the dashboard from wherever your team works, and that the OpenClaw instance you point HERMES_OPENCLAW_HOME at is the one you intend to expose. The writeback flags stay false until you have walked each write path yourself.

## FAQ

### What is builderz-labs/marketing-dashboard?

It is a local-first marketing operations control center that brings CRM, outreach, content planning, analytics, approvals, automation schedules and agent activity into one self-hosted interface. The README describes it as running on Next.js and SQLite without required hosted infrastructure.

### How do I install builderz-labs/marketing-dashboard?

The README requires Node.js 20 and pnpm 10, then clones the repository, runs corepack enable, pnpm install --frozen-lockfile, pnpm env:bootstrap and pnpm dev. The dashboard is then served at http://localhost:3000, and the example credentials in .env.local should be changed before starting.

### What is builderz-labs/marketing-dashboard used for?

The README lists six areas: CRM records and pipeline stages, outreach sequences and suppression, content calendar and approval queues, KPI views with optional analytics connectors, OpenClaw agent discovery and sessions, and cron-based automations with approvals and deployment status.

## Sources

- [builderz-labs/marketing-dashboard on GitHub](https://github.com/builderz-labs/marketing-dashboard)
- [Issues](https://github.com/builderz-labs/marketing-dashboard/issues)
- [License: MIT](https://github.com/builderz-labs/marketing-dashboard/blob/main/LICENSE)
- [Project website](https://www.nyk.dev/oss/marketing-dashboard)
- [README](https://github.com/builderz-labs/marketing-dashboard/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/builderz-labs-marketing-dashboard