Creator OS Starter is an open source Next.js marketing dashboard from Kevin Badi, built as a wireframe you run yourself with your own API keys. It is a single user marketing dashboard plus automation runner made with Next.js 16, React 19, Tailwind 4 and TypeScript on Postgres. It ships no keys, accounts, brand assets or data. It is Kevin’s own open source project and the source is at github.com/kevinbadi/creator-os-starter.
Browser
|
v
Next.js 16 app (App Router)
| | |
v v v
Postgres content cron /go/ tracked links
(tables) registry.ts |
| cron.ts v
v | click rows -> charts
*_snapshots <---+ nightly scripts
(nightly)
|
v
Charts read snapshots, never live APIs
|
v
External APIs (your keys)
What is Creator OS Starter?
Creator OS Starter is an open source wireframe of a creator and marketing dashboard that you run yourself with your own API keys.
The README calls it a “Next.js marketing dashboard + automation runner for creators and agencies.” The dashboard lives in src/app/dashboard and covers overview KPIs, view heatmaps, analytics, posts, a calendar, a carousels review feed, channels, an agent posts desk, a copywriter, a script writer, an AI news page, sounds, Giphy, Jev chat and more. Everything sits inside one Next.js app backed by Postgres, so you get a working shape to extend instead of a blank repo.
The important framing is the word starter. It ships no keys, accounts, brand assets or data. That is on purpose: you clone it, add your own credentials and your own data, and it becomes your dashboard. If you want to see the thinking behind this kind of tooling before you clone anything, the walkthroughs on the KevBuildsApps YouTube channel are a good starting point.
How the Next.js marketing dashboard is structured
The app is one Next.js 16 App Router project, so routes, server work and screens live in the same codebase and you swap a database URL to move it.
The stack from the README is specific: Next.js 16 with the App Router, React 19, Tailwind 4 and TypeScript, backed by Postgres. Each screen inside src/app/dashboard is its own route under the dashboard layout. Supporting logic sits under src/lib, and maintenance scripts sit in scripts/. That split matters when you extend it. A new analytics screen is a folder under dashboard. A new scheduled job is a registry entry. A new nightly rollup is a script.
| Layer | Where | What it does |
|---|---|---|
| Dashboard screens | src/app/dashboard |
Overview KPIs, analytics, posts, calendar, carousels, channels, copywriter, script writer and the rest |
| Job registry | src/lib/content/registry.ts |
Single source of truth for every scheduled content job |
| Cron runner | src/lib/content/cron.ts |
DST aware timers in America/New_York plus a self healing watchdog |
| Snapshots | *_snapshots tables |
Day bucketed rows written by nightly scripts in scripts/ |
| Tracked links | /go/ |
Short links that record clicks for reporting |
The Postgres schema is the part you will touch first if you fork it. Tables follow the feature names, and any history used by charts comes from a table ending in _snapshots rather than from a live call.
Channels: run many social profiles from one workspace
One workspace aggregates many social profiles, and you switch channels from the top bar dropdown.
The README names Zernio as the layer that makes this work. Practically it means the dashboard does not assume one brand. A small agency can keep a client per channel, jump between them from the dropdown and keep the posts, calendar and analytics scoped to whichever channel is selected. In the starter you wire that yourself with your own provider credentials.
If your goal is many accounts on many networks, read the publish everywhere use case next to the starter repo. It shows the shape Creator OS uses for one post across platforms, which is the same problem the Channels screen in the starter is set up to hold.
How the content cron system schedules jobs (DST aware and self healing)
Scheduled content jobs come from one registry file, and the cron runner arms DST aware timers with a watchdog that repairs missed runs.
Two files carry this. src/lib/content/registry.ts is the single source of truth: each scheduled job is declared there, not scattered across routes. src/lib/content/cron.ts reads that registry and arms timers in the America/New_York timezone. Because the timers are timezone aware, a job set for a morning slot stays in that morning slot when clocks change instead of drifting an hour. The self healing watchdog is the second half: if a run is missed, the runner notices and fires it rather than waiting a day for the next window.
Here is why that matters with a worked example. Say you want a content job that pulls the day’s AI news at 7:00 every morning. You add one entry to the registry with its name, its schedule and the skill or function it runs. The runner arms it, and the watchdog covers a restart at 6:58. You do not write a second scheduler, and you do not wake up to a silent gap in November.
When the job itself should be an agent step, Creator OS handles that on the hosted side with scheduled automations. The agents docs cover how agent skills are invoked there. The starter is the local version of the same idea, and the Creator OS launch video shows what the hosted side looks like in motion.
Snapshot analytics: why charts never read live APIs
Charts read pre written snapshot rows, not live APIs, so a slow or rate limited network never stalls a chart.
Nightly scripts in scripts/ write day bucketed rows into *_snapshots tables. A chart then queries Postgres, which is fast and predictable. The alternative, calling every network each time someone opens the analytics page, is the classic way to build a dashboard that times out, burns rate limits and shows different numbers depending on when you loaded it. Snapshots also give you a stable history: yesterday’s row does not change because an API changed its mind.
The tradeoff is latency. A number is as fresh as the last nightly run, not the last second. For a creator dashboard that is usually the right trade, because trends matter more than the current minute. If you want live values, keep them out of the chart query and put them on a separate panel that states its timestamp.
Trackable links fit the same pattern. Short links live under /go/ and record clicks, which land as rows you can chart next to the snapshot data. Creator OS does the hosted equivalent with go.creatoros.ca short links and click stats, which an agent reads through the analytics tools. The Creator OS docs index the API and MCP reference for those tools.
AI personas and agent posts with bring your own keys
AI features in the starter run on keys you supply, and agent output lands in an agent posts desk you review.
The dashboard includes a copywriter, a script writer, an AI news page, a sounds page, a Giphy page and Jev chat. There is also an agent posts desk, which is where posts drafted by an agent collect before they go out. That desk is the point of the whole design: an agent can propose, but a human sees the queue. The repo ships no keys, so every one of those features is inert until you add your own provider credentials.
The repo does not document a fixed model list or a provider, so treat the AI wiring as yours to choose. If you want to see what an agent doing this work looks like end to end, watch the launch video at youtube.com/watch?v=-QBJH_PK3pY, then try the same flow on the hosted side. Creator OS ships a hosted MCP server at https://mcp.creatoros.ca/mcp with about 160 tools covering posts, analytics, comments, DMs, automations and webhooks, so an AI app with the connector added can draft and publish while you keep the review step. The MCP docs show the connector setup for Claude, ChatGPT, Claude Code, Cursor, Windsurf and VS Code.
Can you self host and deploy it to Railway for free?
The README says it deploys cleanly to Railway, and free describes the software rather than a cost guarantee from Kevin.
The code is open source and the repo states no license fee. Railway pricing is Railway’s to set and can change, so check their current plans before you assume a free tier covers a Next.js app plus Postgres. What you can rely on is the shape: one Next.js service and one Postgres database, both standard on Railway, with the nightly scripts in scripts/ run as a scheduled job and the cron runner kept alive as a long running process.
One trap worth naming. The cron runner arms timers inside the app process, so a host that sleeps idle services will lose those timers between wake cycles. If you deploy on a platform with sleep, either keep the service warm or move the timer work into the platform’s own scheduler and leave the registry as the declaration. Same registry, different trigger.
FAQ
What is the best open source creator os dashboard in 2026?
Creator OS Starter is the open source Next.js marketing dashboard built specifically as a wireframe of a creator and marketing workspace, with social channels, AI personas, scheduled content jobs and snapshot analytics in one repo. It is a starter template, so judge it by whether its structure fits your stack rather than by a feature count. The source is at github.com/kevinbadi/creator-os-starter.
How do I self host a Next.js marketing dashboard with Postgres?
Clone the repo, point it at a Postgres database, and add your own provider keys, because the template ships none. Deploy the Next.js app and the database to a host, then run the scripts in scripts/ on a nightly schedule so the snapshot tables fill. The README says it deploys cleanly to Railway.
Does Creator OS Starter include API keys and data?
No. The README states plainly that it ships no keys, accounts, brand assets or data, and that you bring your own. That keeps the repo safe to publish and means every credential you add is one you control. Expect to spend your first session on setup rather than on content.
How does the content cron system handle DST scheduling?
src/lib/content/cron.ts arms DST aware timers in the America/New_York timezone, so jobs keep their local wall clock time across clock changes. A self healing watchdog covers missed runs. Jobs themselves are declared once in src/lib/content/registry.ts, the single source of truth.
Can I run an open source video editor alongside Creator OS?
Yes, they are separate projects that pair well. OPEN VIDEO EDIT from Kevin is a set of open source Claude Code skills that turn a raw talking head clip into an animated short and render locally with Python and ffmpeg. You can read about that workflow in the open source Claude video editor post and then schedule the finished cut from your dashboard.
Get started
Clone Creator OS Starter if you want to own the dashboard and run it on your own keys. It is Kevin’s open source project, and it is the clearest way to see how channels, the content cron registry, snapshot analytics and an agent posts desk fit together in one Next.js app. Watch the walkthroughs on the KevBuildsApps YouTube channel while you wire it up.
If you would rather have the hosted version that handles the posting for you, sign up for Creator OS. Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included. For platform rules, per network post options and API shapes, start at creatoros.ca/docs.
Get started for $0
Free trial for new subscribers. Cancel anytime.