Marketing Dashboard: A Self-Hosted Control Center for CRM, Outreach and Agent Workflows

The problem is tool sprawl across human and agent work, not missing features

Marketing operations for a small team usually ends up spread over a CRM, a sequence tool, a content calendar, an analytics tab and a scheduler. When agents enter the picture, their sessions and workspaces become a sixth surface that nobody is watching. The README frames the project as "a local-first marketing operations control center for teams running human and agent workflows," and the table of surfaces backs that up: CRM, outreach, content, analytics, agents and automations all sit behind one interface. The intended user is an operator, not a growth team buying seats. The README states the dashboard is operator-led and that approval, pause, writeback and host-access controls stay visible rather than being hidden behind autonomous execution. That is a deliberate stance. If you want a tool that acts on your behalf without asking, this is pointed the wrong way for you. If you want one screen where a lead, the sequence that touched it, the content it relates to and the agent session that produced it are all inspectable, that is the gap being filled.

Next.js 16 and better-sqlite3 keep application state on the machine you run it on

The architecture is stated plainly in the README's layer table. The application is Next.js 16 App Router with React 19 and TypeScript. The interface is Tailwind CSS 4, Recharts and Zustand. State is SQLite through better-sqlite3. Authentication is a session cookie, an API key, or optional Google OAuth. Agent connection happens through OpenClaw CLI and filesystem discovery. Deployment is a local process, a standalone build, or a private HTTPS host. The data flow follows from that: the application, authentication and SQLite state run locally, and provider connectors are optional and receive credentials from server-side environment variables. Nothing in the described path requires a hosted backend. That matters for two reasons. First, the operational data (leads, sequences, approvals) does not leave your host unless you configure a connector. Second, your backup story is a file, not an export job. The cost is that SQLite through better-sqlite3 is a single-process embedded database, and the README does not describe a replication or multi-writer story. Treat the state directory as a single-host asset until the repository says otherwise.

Getting it running takes five commands and one credential change you must not skip

The README's quick start requires Node.js 20, pnpm 10, and a local machine or private host that can persist SQLite state. The commands are: git clone https://github.com/builderz-labs/marketing-dashboard.git, cd marketing-dashboard, corepack enable, pnpm install --frozen-lockfile, pnpm env:bootstrap, pnpm dev. The app then listens on http://localhost:3000. The first login is seeded from AUTH_USER and AUTH_PASS when the users table is empty, and the README is explicit that the example credentials in .env.local should be changed before starting the application. Configuration is split into required variables and host boundaries. Required: AUTH_USER, AUTH_PASS (minimum 10 characters), API_KEY, and AUTH_COOKIE_SECURE, which should be true on HTTPS deployments. Host boundaries: HERMES_STATE_DIR defaults to ./state and holds SQLite and runtime state; HERMES_OPENCLAW_HOME defaults to ~/.openclaw; HERMES_HOST_LOCK defaults to local; and three write flags (HERMES_ALLOW_POLICY_WRITE, HERMES_ALLOW_CRON_WRITE, HERMES_ALLOW_WORKSPACE_WRITE) all default to false. Multi-instance discovery uses HERMES_OPENCLAW_INSTANCES, a JSON array documented in .env.example. Note the naming: the environment variables keep the HERMES_* prefix for backward compatibility with existing deployments, while the public project name is Marketing Dashboard. If you are reading old notes or an old deployment, that mismatch will confuse you once.

The HERMES_ALLOW_*_WRITE flags are the real security boundary

Most self-hosted dashboards ship with everything enabled and expect you to lock it down. This one inverts that. Policy files, cron files and agent workspaces are all off-limits until you flip a specific flag, and the README's deployment safety section says to leave all HERMES_ALLOW_*_WRITE variables disabled until their write paths are required and reviewed, then return to read-only mode by disabling the flags. HERMES_HOST_LOCK defaults to local and should stay there unless you have an explicit host allowlist. Outside local development the README calls for HTTPS plus AUTH_COOKIE_SECURE=true, and for loading production secrets from a secret manager or runtime environment. Read that as a statement about blast radius. A read-only install that leaks is a data exposure problem. A write-enabled install that leaks can alter cron schedules and agent workspaces on the host, which is a different class of incident. The design is honest about this, and the flags are the mechanism. What the README does not give is a per-flag description of what each write path touches or what a rejected write looks like in the interface. That is the documentation gap I would want closed before enabling any of them.

Alpha status, no releases, and a schema that may move under you

The README labels the project alpha and says the working surface is broad but APIs, schemas and configuration may change between releases. The repository metadata shows no releases retrieved, so there is no tagged version to pin to and no changelog to diff against. In practice that means upgrading is a git pull plus whatever migration the schema change implies, and you carry the risk of that migration yourself. The CI workflow runs the template audit, lint, typecheck, unit tests, production build and Playwright tests, and the development commands are pnpm lint, pnpm typecheck, pnpm test, pnpm build, pnpm test:e2e, plus bash ./scripts/template-audit.sh. Those are checks the maintainers run, not a compatibility guarantee for your deployment. Two more constraints are worth naming. First, the optional integration list is long (Google OAuth, Plausible, GA4, Gmail, Mailchimp, Sanity, Helius, X, LinkedIn, 1Password runtime overlays, Ollama model-health checks), and every one of them is a credential you have to store and rotate. The README's own advice is to keep unused credentials unset, which is the right default but also means the integration surface is your responsibility. Second, the agent side depends on OpenClaw CLI and filesystem discovery. If your agents do not run under OpenClaw, the agents tab is not useful to you, and the rest of the dashboard is a CRM and content tool with a scheduler.

Against a hosted marketing suite, the trade is control for operational load

The obvious alternative is a hosted marketing platform that bundles CRM, sequences, a content calendar and analytics behind a subscription, with connectors maintained by the vendor. The difference in approach is not feature parity, it is where state lives and who runs the upgrade. A hosted suite gives you a managed schema, a support channel and someone else's on-call rotation. Marketing Dashboard gives you the SQLite file, the environment variables and the upgrade decision. You also get the approval and suppression surfaces in the same place as the agent activity, which hosted suites generally do not model at all. The cost is real: you provision the host, you set AUTH_COOKIE_SECURE, you decide whether HERMES_HOST_LOCK stays at local, and you own the backup of HERMES_STATE_DIR. There is also a narrower alternative worth naming for teams that only want the agent oversight piece: run OpenClaw directly and skip the dashboard. The dashboard's value is the consolidation, and if you are not consolidating, you are paying the install and schema-churn cost for a UI you do not need.

Maintenance cost and what the MIT licence does and does not cover

The licence is MIT, per the repository metadata and the LICENSE file referenced in the README. MIT is permissive: you can modify and redistribute, including in commercial settings, provided the copyright notice and permission notice are preserved. It ships with no warranty, and it says nothing about the third-party dependencies you will pull in through pnpm install. THIRD_PARTY_NOTICES.md records dependency notices, and that file is where you check what the transitive tree actually obligates you to. I am not giving legal advice; if you plan to redistribute a derived template, read THIRD_PARTY_NOTICES.md and your own counsel's view of it. On maintenance: the repository has a CONTRIBUTING.md describing development and PR evidence, a SECURITY.md defining private vulnerability reporting and a supported-version policy, and a CODE_OF_CONDUCT.md. The supported-version policy in SECURITY.md is the document to read before you commit, because with no tagged releases the question of what counts as supported is answered there or nowhere. The template export path (bash ./scripts/template-audit.sh then bash ./scripts/template-export.sh ./export) excludes environment files, databases, build output, dependency directories, test artifacts and runtime state, which is the right list for anyone publishing a derived template and a reminder that your SQLite state is the thing you must never ship.

Editorial conclusion

Adopt it if you want CRM, outreach, content approval and agent activity in one interface that you host yourself, and if you are comfortable reading an alpha schema that the README says may change between releases. Do not adopt it if you need a supported release channel, a hosted control plane, or write paths that are on by default; this project ships no releases and starts in read-only mode. Before you point it at real data, verify three things in your own copy: that pnpm env:bootstrap produced a .env.local with changed AUTH_USER, AUTH_PASS and API_KEY values, that HERMES_STATE_DIR points at a path you actually back up, and that the HERMES_ALLOW_POLICY_WRITE, HERMES_ALLOW_CRON_WRITE and HERMES_ALLOW_WORKSPACE_WRITE flags are still false until you have read the write path you intend to open.

Official sources

1. builderz-labs/marketing-dashboard on GitHub
2. Issues
3. License: MIT
4. Project website
5. README