Flowershow: a markdown publishing platform built as a Next.js and Go monorepo

The product's own site is the demo

The README opens with a claim worth checking rather than accepting: flowershow.app itself is built and published with Flowershow. That is the kind of statement projects usually make about a static landing page, so the detail that makes it credible is the other links in that same block. The docs at flowershow.app/docs are user documentation, and there is a separate page at flowershow.app/cli aimed at agents rather than humans.

The positioning is broader than a blog engine. The description says markdown and HTML websites, docs, wikis, and websites, which is a little repetitive but accurate to what the code contains: a remark plugin for wiki-style links, an Obsidian integration page, and a search path that goes through Typesense. Flowershow is a product of Datopian, which describes itself as dedicated to democratising the power of data and knowledge, and it carries an AGPL-3.0 licence.

The topics tell the same story from the other direction: blogging, cms, digital-garden, markdown, mdx, nextjs-template, obsidian-md, tailwind-css. Digital garden and obsidian-md together suggest the target user is someone with an existing vault of linked notes who wants it online.

A Next.js app and a Go CLI in the same workspace

The monorepo structure is the first thing the README explains, and it is short enough to read twice:

apps/
  flowershow/           # Next.js web application (flowershow.app)
  cli/                  # Go CLI (`fl`) — publish markdown files from the terminal or AI agents
packages/
  api-contract/         # @flowershow/api-contract — Zod schemas, TS types, OpenAPI 3.1 spec
  cloudflare-worker/    # Markdown processing Cloudflare worker
  remark-wiki-link/     # @flowershow/remark-wiki-link — remark plugin for wiki-style links
content/
  flowershow-app/       # Marketing site content (Obsidian vault, not a workspace package)

The two decisions here matter more than the directory names. First, the CLI is Go while everything else is TypeScript, which is a deliberate split rather than an accident of history: a single static binary named `fl` is the thing you want an agent or a CI job to invoke. Second, the content directory is an Obsidian vault that is explicitly not a workspace package, so your files stay plain markdown on disk rather than becoming part of the npm dependency graph.

It is a Turborepo managed with pnpm workspaces, and the repo root confirms it with turbo.json, pnpm-workspace.yaml, and a pnpm-lock.yaml. There is also a package-lock.json sitting next to it, which is the kind of stray file that hints at a migration that finished but left its previous lockfile behind.

Getting the stack running means Docker and five services

The prerequisites are Node.js 22 or newer, pnpm, and Docker. The clone step asks for submodules, which tells you the e2e test site lives in a separate repository:

# Clone (include the e2e test-site submodule)
git clone --recurse-submodules https://github.com/flowershow/flowershow.git
cd flowershow

# Install dependencies
pnpm install

# Copy env template (then edit apps/flowershow/.env with your secrets)
cp apps/flowershow/.env.example apps/flowershow/.env

# Start everything: Postgres, MinIO, Inngest, Cloudflare Worker, Next.js app
pnpm dev

The service list in that comment is the real local topology: Postgres for data, MinIO for object storage, Inngest for background jobs, a Cloudflare Worker for markdown processing, and the Next.js app itself. The docker-compose.yml backs this up with postgres:16, a pinned MinIO release, and a one-shot init container that creates the bucket and wires an event notification webhook into the worker.

Optional services are behind flags rather than always running, which is a considerate default:

pnpm dev --stripe              # Also start Stripe webhook forwarding
pnpm dev --github              # Also start Smee (GitHub webhook proxy)
pnpm dev --search              # Also start Typesense

pnpm dev:all                   # Start everything including all optional services

pnpm dev:local                 # Start dev servers only (no Docker infrastructure)
pnpm dev:local:all             # Start dev servers only + all optional services
pnpm dev:down                  # Stop Docker containers (keep data)
pnpm dev:nuke                  # Stop containers + delete all data volumes

The `dev:local` variant is worth noting. You can run the Next.js app against your own Postgres and storage instead of the bundled containers, which is what you would do if you already run that infrastructure.

The api-contract package is the seam everything else meets

The most architecturally interesting line in the README is the one describing the REST API contract. Zod schemas, TypeScript types, and an OpenAPI 3.1 spec live in @flowershow/api-contract, and the README states that the contract is the single source of truth for the API surface, with the Next.js API routes, the CLI, and the Obsidian plugin all consuming it.

That is a real constraint, not a slogan. It means a schema change breaks three clients at build time instead of drifting quietly until an agent sends a malformed request. For a product whose stated pitch includes integrating with AI, having a machine-readable contract is the part that makes the agent story hold together.

The docs are unusually complete for a repository README. With the dev server running you get Swagger UI at /api/docs and the raw spec at /api/docs/openapi.json, and the production equivalents are linked at flowershow.app/api/docs. Per-area READMEs are linked for the web app, the API contract, and the CLI, so the root document points rather than duplicates.

Tooling follows the same deliberate split: Biome formats and lints packages, ESLint with eslint-config-next handles the Next.js app, Vitest unit tests the remark plugin, and Playwright runs end to end tests. Husky plus lint-staged formats staged files on every commit, and Changesets handles versioning and npm publishing for the packages.

Version 4.0 of the remark plugin silently changed link behaviour

The release history is where you find out which parts matter most, and the three most recent releases split into two stories. Two of them are CLI releases: cli/v2.3.0 on 2026-09-05 and cli/v2.2.0 on 2026-08-03. The changelogs are mostly fix entries, but two are worth naming. The 2.3.0 line made the CLI respect contentExclude and contentInclude from config.json, which is the difference between a publish command that works and one that silently uploads files you meant to skip. The 2.2.0 line makes the CLI recover gracefully from server-side site renames.

The third release is @flowershow/[email protected] from 2026-06-23, and it is the only one that changes what users see. Links are now prefixed with leading slashes so they resolve from the site root rather than relative to the current page, and the `regular` link format was renamed to `exact`.

Both of those are breaking changes for anyone with an existing vault, and neither would be obvious from a feature list. If you have linked notes where relative resolution was what you wanted, the upgrade changes the output. The rename from `regular` to `exact` also means any theme or config referencing the old name needs updating.

Rest of the 2.3.0 changelog is housekeeping: a new official Monospace theme, a fix resolving that theme from main, mobile layout fixes for the tokens table and create-token modal, and documentation regenerations. The repo's last push was on 2026-09-19.

Contributing to the main repository is not open yet

This is the sentence most project READMEs would leave out. Flowershow says it is working on opening up parts of the project for community contributions, and that while this is not ready yet, contributors are welcome soon. Then it tells you what you can do instead: add pull requests for demos or tests of markdown features, pointed at demo.flowershow.me and test.flowershow.me.

So the split is clear. Documentation and feature-demo work goes to separate repositories you can pull against today. Changes to the application, the CLI, or the packages do not, yet. For an AGPL-3.0 project that also gates its contribution surface, that is a meaningful constraint on anyone hoping to shape the tool rather than just publish with it.

The development workflow for whatever is open runs through a staging branch rather than main: create a feature branch from staging, implement, submit a pull request to staging, and after approval the change moves along. The tree also carries AGENTS.md, CONTEXT.md, and an opencode.json, so the project ships context files for coding agents, which fits the stated plan to treat the CLI as the agent interface.

The web app README is where the pieces the root document omits live, specifically the database, storage, and auth configuration. That is the file to read before you try to point Flowershow at your own infrastructure.

Editorial conclusion

Flowershow is doing something a lot of markdown site generators do not: treating the vault, the CLI, and the API contract as first class parts of one product. The monorepo makes that visible, the Go `fl` binary gives agents and terminals a real interface, and the api-contract package stops the Next.js routes and the CLI from drifting apart. What you cannot do today is open a pull request against the interesting parts. The README says contributions are still being opened up and points instead at demo and test sites. So the practical entry point is running the stack with Docker, pointing it at a vault, and reading apps/flowershow/README.md, where the database, storage, and auth setup actually live. The AGPL-3.0 licence is worth weighing before you connect it to a company wiki.

Frequently asked questions

Official sources

1. flowershow/flowershow on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases