builderz-labs/marketing-dashboard: AI Agent Marketing Control Center
Marketing operations for AI agent teams remain fragmented. Most teams stitch together CRMs, outreach tools, content calendars, and analytics platforms—each with separate APIs, authentication flows, and data models. The overhead compounds when agents need to read from and write to multiple systems. builderz-labs/marketing-dashboard addresses this directly: an open-source, local-first control center that unifies CRM, outreach, content operations, analytics, and automation workflows under one interface, powered by OpenClaw and SQLite.
This article examines what the project delivers, how it fits into existing infrastructure, and whether it merits adoption for production AI marketing systems. The focus keyword, builderz-labs/marketing-dashboard, reflects the repository's actual GitHub path—not marketing language, but the identifier developers will use to find and evaluate it.
What is builderz-labs/marketing-dashboard?
builderz-labs/marketing-dashboard is an alpha-stage, MIT-licensed marketing operations dashboard built by Builderz, a development shop with 32+ products across 15 countries. The repository—388 stars, 73 forks, last updated June 21, 2026—targets a specific niche: operator-led AI marketing systems requiring execution visibility and control rather than disconnected point solutions.
The project sits at the intersection of three technical categories: internal tooling/dashboard frameworks, AI agent infrastructure, and local-first application architecture. It is not a generic CRM or a no-code automation platform. Instead, it assumes you are running AI agents (via OpenClaw) and need a centralized surface to manage their marketing functions—lead tracking, outreach sequencing, content scheduling, performance analytics, and deployment status.
The stack choices signal intent. Next.js↗ Bright Coding Blog 16 with the App Router and React↗ Bright Coding Blog 19 provide the UI layer. TypeScript 5 covers type safety. SQLite handles persistence locally, with state stored in ./state—no required external database, no Docker↗ Bright Coding Blog complexity for initial setup. OpenClaw CLI serves as the agent runtime, with filesystem integration for dynamic agent and squad discovery. This architecture prioritizes local development velocity and deployment flexibility over managed-service convenience.
The alpha status matters. The README explicitly warns that APIs, data models, and configuration behavior change between releases. This is honest signaling, not modesty. Teams evaluating builderz-labs/marketing-dashboard should plan for migration work as the surface stabilizes.
Key Features
The dashboard's feature set divides into five operational domains, each with concrete technical capabilities documented in the repository:
CRM and Pipeline Management Leads, pipeline funnels, source tracking, and engagement APIs are implemented. The data model supports funnel stage transitions and source attribution—critical for understanding which agent-driven activities produce qualified leads.
Outreach Operations Sequencing infrastructure includes pause/audit endpoints and suppression workflows. This matters for compliance and for debugging agent behavior: when an agent sends malformed outreach, operators can halt sequences and inspect state without database surgery.
Content Operations Calendar management, content item tracking, and performance APIs. The integration pattern suggests agents can schedule content, retrieve performance data, and feed results back into planning loops.
Analytics and KPI Views Optional connectors for Plausible, GA4, and social platforms. The "optional" qualifier is important—core analytics function without external dependencies, but teams can enrich dashboards with existing measurement infrastructure.
OpenClaw-Native Agent Runtime
Dynamic agent/squad discovery, cron templates with schedule variants (cron, every, at), workspace surfaces, and comms integration. The deploy status endpoint includes OpenClaw config validation preflight, catching misconfigurations before they reach production.
Security Posture
Session auth, API key support, host lock (HERMES_HOST_LOCK=local by default), and writeback controls (HERMES_ALLOW_POLICY_WRITE=false, etc.) are disabled by default. This is a deliberate template-security design: safe defaults that operators explicitly relax when needed.
Use Cases
1. AI Agent Marketing Squad Orchestration A team running multiple OpenClaw agents for lead generation, content creation, and outreach needs visibility. builderz-labs/marketing-dashboard provides the control surface: see which agents are active, what sequences are running, and where leads sit in the funnel. The cron template system schedules agent runs without external job infrastructure.
2. Local-First Marketing Operations for Startups Early-stage teams without budget for HubSpot, Salesforce, or managed marketing clouds can run full CRM and outreach from a single Next.js application. SQLite eliminates database hosting costs. The MIT license removes commercial restrictions.
3. Compliance-Sensitive Outreach Environments The suppression workflows and audit endpoints suit industries where outreach requires documentation: financial services, healthcare-adjacent products, or EU markets under GDPR. Pause capabilities let human operators intervene before agents escalate compliance risk.
4. Agent Development and Staging Developers building new marketing agents need a realistic environment to test interactions with CRM and content systems. The local-first stack spins up quickly; the OpenClaw integration mirrors production agent runtime behavior without cloud dependencies.
5. Embedded Marketing Infrastructure Teams building vertical SaaS with marketing components can fork and extend builderz-labs/marketing-dashboard rather than integrating multiple third-party APIs. The TypeScript/Next.js foundation matches modern full-stack skill sets.
Installation & Setup
The project requires pnpm. Install it globally if absent:
npm install -g pnpm
# Or enable via corepack:
corepack enable
Clone and initialize:
git clone https://github.com/your-org/hermes-dashboard.git
cd hermes-dashboard
pnpm install
pnpm env:bootstrap
pnpm dev
Open http://localhost:3000.
Step-by-step explanation:
git clone— Retrieves the repository. Note: the README currently referencesyour-org/hermes-dashboard.git, though the actual repository is atbuilderz-labs/marketing-dashboard. Use the correct URL:https://github.com/builderz-labs/marketing-dashboard.pnpm install— Installs dependencies. The lockfile ensures reproducible builds.pnpm env:bootstrap— Generates initial environment configuration from.env.example. This step seeds required variables and validates their presence.pnpm dev— Starts the Next.js development server on port 3000.
Initial access: When the users table is empty, admin credentials seed from AUTH_USER and AUTH_PASS environment variables on first run. Change these before any network deployment—the README emphasizes this security consideration.
Required environment variables (see .env.example for complete list):
| Variable | Purpose |
|---|---|
AUTH_USER |
Initial admin username |
AUTH_PASS |
Initial admin password (minimum 10 characters) |
API_KEY |
API authentication key |
AUTH_COOKIE_SECURE |
false for HTTP local dev, true for HTTPS production |
Real Code Examples
The README contains limited executable code samples. The following are reproduced directly with explanatory context.
Development workflow commands:
pnpm dev # Start development server
pnpm build # Production build
pnpm typecheck # TypeScript validation
pnpm lint # ESLint checks
pnpm test # Unit tests
pnpm test:e2e # End-to-end test suite
These commands reflect standard Next.js project hygiene with pnpm prefixes. The test:e2e target is notable: the README states auth and API flows have end-to-end coverage, suggesting the test suite validates critical security paths. Teams extending the dashboard should maintain this coverage for custom authentication or authorization modifications.
Template export and hygiene scripts:
./scripts/template-audit.sh
./scripts/template-export.sh [output_dir]
The template-audit.sh script inspects the repository for sensitive artifacts before sharing. The template-export.sh script produces a clean export excluding .env*, database files, .next build output, and node_modules. This addresses a real operational need: preventing credential leakage when forking or distributing the project. The [output_dir] parameter is positional—replace with your target directory.
Environment configuration for OpenClaw multi-instance:
# Required for OpenClaw integration
HERMES_OPENCLAW_HOME=/path/to/openclaw
HERMES_DEFAULT_INSTANCE=default
# Optional: multiple OpenClaw instances as JSON array
HERMES_OPENCLAW_INSTANCES='[{"name":"prod","path":"/opt/openclaw"},{"name":"staging","path":"/opt/openclaw-staging"}]'
This configuration enables the dashboard to discover and interact with multiple OpenClaw installations. The JSON array format for HERMES_OPENCLAW_INSTANCES requires careful quoting in shell environments—consider using a .env file rather than inline export to avoid parsing errors.
The README does not provide additional API call examples, React component code, or database schema definitions. This reflects the project's alpha status and the README's orientation toward operators rather than developers extending the core. Teams evaluating deep integration should inspect the source directly or contribute documentation improvements.
Advanced Usage & Best Practices
Host lock enforcement: The default HERMES_HOST_LOCK=local restricts access to localhost. Before exposing the dashboard to a network, understand the implications: disabling host lock (HERMES_HOST_LOCK=off) or specifying allowed hosts (HERMES_HOST_LOCK=host1,host2) should accompany HTTPS deployment and AUTH_COOKIE_SECURE=true.
Writeback controls: Three flags govern agent-mediated mutations:
HERMES_ALLOW_POLICY_WRITE=false # Policy/authorization changes
HERMES_ALLOW_CRON_WRITE=false # Cron template modifications
HERMES_ALLOW_WORKSPACE_WRITE=false # Workspace structure changes
Enable selectively. In production, prefer read-only agent access unless specific workflows require mutation rights. The README's secure-by-default posture is sound—deviate intentionally, not accidentally.
1Password integration: For teams using 1Password Secrets Automation, the optional runtime overlay supports HERMES_1PASSWORD_MODE=auto with a specified environment file path. This bridges local development secrets management with production secret distribution without code changes.
Database hygiene: SQLite files in ./state contain application data. Exclude this directory from version control and backups should include it explicitly. The template export scripts already handle this, but manual archive operations may not.
Comparison with Alternatives
| Dimension | builderz-labs/marketing-dashboard | NocoDB/Baserow | Custom Next.js + External APIs |
|---|---|---|---|
| Primary purpose | AI agent marketing operations | General database GUI | Fully custom implementation |
| Agent runtime integration | Native OpenClaw | None | Requires custom build |
| Local-first deployment | SQLite, no external DB required | SQLite/PostgreSQL↗ Bright Coding Blog options | Depends on architecture |
| CRM/outreach features | Built-in, alpha stage | Requires configuration | Build from scratch |
| License | MIT | Various (MIT, AGPL) | N/A |
| Maintenance burden | Medium (alpha, evolving) | Lower (stable projects) | High |
NocoDB/Baserow suit teams needing general database interfaces with marketing data. They lack agent runtime awareness and require manual integration with OpenClaw or similar systems. Custom builds offer maximum flexibility but replicate the CRM, outreach, and analytics foundations that builderz-labs/marketing-dashboard provides. The trade-off is stability: alpha software versus production-hardened alternatives or full ownership of custom code.
For teams already committed to OpenClaw for agent orchestration, builderz-labs/marketing-dashboard reduces integration surface area significantly. For teams without OpenClaw adoption, the value proposition depends on willingness to adopt that runtime.
FAQ
What does "alpha software" mean practically? Expect schema changes, UI shifts, and potential breaking API modifications between releases. Pin versions and review changelogs before updating.
Can I use this without OpenClaw? The CRM, outreach, content, and analytics features function independently, but agent discovery and cron templates assume OpenClaw runtime. Core value diminishes without it.
What Node.js version is required? The README specifies Next.js 16 and React 19. Verify your Node.js version supports this Next.js release—typically Node.js 18.17 or later for Next.js 16.
Is there a hosted version? No. The project is self-hosted, local-first by design. Builderz offers custom development services but no managed SaaS.
How do I report security issues?
See SECURITY.md in the repository. The README references this file but does not detail the reporting process.
Can I migrate from SQLite to PostgreSQL? The README does not document this path. SQLite is architecturally assumed; migration would require adapter modifications.
What does the MIT license permit?
Commercial use, modification, distribution, and private use, with attribution. The LICENSE file contains full terms.
Conclusion
builderz-labs/marketing-dashboard occupies a specific niche: teams running OpenClaw-based AI agents for marketing who need unified operational visibility. It is not a general-purpose CRM replacement, nor a no-code platform for non-technical users. The local-first architecture, SQLite persistence, and security-conscious defaults make it particularly suitable for development environments, cost-sensitive startups, and compliance-cautious operations.
The alpha status demands realistic expectations. APIs will shift. Documentation gaps exist—particularly around code examples and migration paths. Yet the 388 stars and active development (last commit June 2026) indicate genuine community interest and maintainer engagement.
For teams aligned with its architecture—Next.js/TypeScript familiarity, OpenClaw adoption, willingness to self-host—builderz-labs/marketing-dashboard offers substantial integration savings over assembling equivalent capabilities from separate tools. For others, the evaluation should center on whether OpenClaw adoption is already planned or whether the local-first model fits operational constraints.
Explore the repository, review the open issues, and test the local setup. If the fit is right, contribute back: the project explicitly welcomes contributions via CONTRIBUTING.md.
