What PlatformKit is
How PlatformKit combines a framework, theme, and site-specific content and modules, with example configurations and product comparisons.
What it is
PlatformKit is an open-source platform for building and operating a website with its business features in one application. It includes a content system, a theme, an admin, and optional modules for selling, memberships, bookings, forms, community, support, and marketing.
A site chooses modules in platformkit.config.js and supplies its own content, business rules, and visual design. For example, a publisher can enable books, print sales, memberships, and email; a practice can enable bookings, paid sessions, and member chat. These are configurations of one platform, not separate product forks.
What comes in the platform
- Kit (
@platform-kit/kit): content processing, the CLI, build and deployment tools, database declarations, APIs, and shared services such as checkout and messaging. - Theme (
@platform-kit/movable-types): the public pages, reader and admin interfaces, components, and styles. - Site: the configuration and content that select the modules, set the brand and policies, and add site-specific components, routes, data, or admin screens.
The demo site enables modules to show how they work together. The docs site disables the application modules and serves documentation without sign-in.
How sites are configured
The site's configuration determines which routes, navigation items, admin screens, build steps, and deployment requirements exist. Turning off a module removes the surfaces it owns. Site code can replace a named theme component without copying the theme, and site strings can override the theme's defaults.
The platform keeps a few conventions consistent across modules:
- Content is authored as records. A page, product, book, or email has a defined file or row as its source of truth.
- The database is declared. Schema files describe the intended tables; the migration planner compares them with the database and blocks destructive changes unless explicitly allowed.
- Drafts are not public. Unpublished records remain editable but are excluded from public routes, search, and build output.
- Interface copy is editable. Reader- and admin-facing words live in markdown string files, not component templates.
- Forms edit structured values. The admin presents fields and controls instead of asking editors to type YAML or another file grammar.
- Deployment checks run first. Before deploying, PlatformKit checks that enabled features have the required credentials and that mock integrations are off.
Where content lives
File-backed sites keep their records in the site's content/ directory. In cloud mode, Supabase stores a draft and a published version of each record. Publishing makes the draft live; if the site has a repository in its publish cycle, it also commits the change and triggers a rebuild. A cloud deployment without a repository serves the published database records directly.
The admin uses the same editing workflow in local development and in production when row-backed content is enabled. Static deployments do not include a production admin or authentication. See The three deployment shapes for the full comparison.
Comparable products and feature limits
The table compares PlatformKit modules with products people may otherwise use for the same job. The last column identifies important capabilities those products offer that PlatformKit does not provide.
Community spaces are for a site's members. The social network is a separate feature and can connect to Bluesky when the site and each member opt in.
| Instead of | The kit's module | What it does | What it deliberately leaves out |
|---|---|---|---|
| WordPress | content collections, the admin CMS, the theme | pages, articles, books, wiki and docs as markdown; an admin that edits them as forms; a theme system | no third-party plugin marketplace; extensions are registered by the site or theme rather than installed as arbitrary plugins |
| Contentful, Sanity, Strapi | content models, content API | content types defined in the admin as fields with kinds and rules; entries as markdown with frontmatter, edited as forms; delivered as data, plain pages, static JSON or a landing section, as each model says — and served over Contentful's own Delivery, Preview, GraphQL, Sync and Images APIs — and, in cloud mode, written through its Management API with its webhooks — with keys, so a Contentful client works with the host swapped, reading and writing | no entries in several languages (the translation module); no review step between a draft and its publish; no roles per model; no environments beyond master, no content types written through the API (a model is the builder's) |
| Laravel Spark, Memberstack | memberships, auth | tiers with ranks, subscriptions switched up now and down later, the billing portal, roles | no teams, seats or metered billing |
| Ghost, Substack | memberships, the reader, funnels and blasts | free and paid content by chapter allowance; a newsletter to the audience, on site and by email | — |
| Shopify, BigCommerce, Gumroad | store | products, a bag, checkout with shipping chosen first, guest checkout, downloads, orders — the store served over Shopify's own Storefront API (products, collections, the cart, a checkout url into the site's bag) with a public token, so a headless storefront and Shopify's storefront client work with the domain swapped | no full inventory-management suite beyond configured availability and checkout holds; no multi-currency or tax engine; on the API no customer accounts, selling plans, discount codes, gift cards or markets, and not the Admin API |
| Blurb | print editions, print production | a book typeset, covered and quoted by the build; printed to order and shipped by a printer plug-in | no design tool — the book is typeset from markdown; no author storefront of Blurb's own |
| Crisp, Chatwoot, Intercom | support chat, coaching chat | an embedded chat for guests and readers with an inbox, prompts, escalation; a members' chat with coaches — the desk served over Chatwoot's own Client and Application APIs with webhooks and keys, and Chatwoot's website snippet mounting the site's widget on any page, so anything written for Chatwoot works with the base changed | no multi-channel inboxes, no bots, no visitor tracking, no product tours; on the API no identity validation (a signed-in person is the site's sign-in), no teams, labels, macros, automations or reports |
| Calendly, Acuity, cal.com | sessions | booking inside the app on the site's own calendar (a coach's hours, seats, notice, reminders and invitations) or on cal.com's engine, under the site's own judge of what a plan allows — the sessions served over cal.com's own API v2 with webhooks and keys, so cal.com's embed and anything written against its API work with the host swapped | no external-calendar sync yet — a host blocks outside meetings as exceptions |
| Zoom, Google Meet, Daily | sessions | a video room on the site for a booked call or a channel’s huddle — on LiveKit where the site has an account, recorded into the site’s own storage, and browser to browser with no account and nothing to configure where it has none; or a link to a room elsewhere | no in-call chat, breakout rooms, dial-in or transcript of a room's call |
| Slack, Microsoft Teams, Discord | spaces | the business's own chat: spaces whose membership is a role or a tier, channels read as a stream or a forum, direct messages, threads, mentions that decide the notification, search, huddles, a channel that may be end-to-end encrypted, and operations channels the platform writes into — an order, a failed print job, an escalation are the database's own messages, not an integration — and the whole of it served as a Matrix homeserver's Client-Server API, so Element, FluffyChat, Nheko and any other Matrix client sign in and read the site's rooms with the host swapped, on every platform, without the kit shipping an application of its own | no workspaces sold to other operators from one instance; no applications, bots or slash commands; no rich-text blocks; no scheduled send, do-not-disturb or statuses; no native mobile application; no federation (a site is a homeserver for its own people, not a node on the public network), end-to-end encryption only where a channel asks for it, and then the site gives up the three things it was reading its own rooms for — there is no search of a sealed room, no bot in one, and no moderating what nobody can read, no presence, no Matrix VoIP (a huddle is the site's own video) |
| Circle.so, Mighty Networks, Skool, Discourse | spaces, network, memberships | a community for the site's members: the tier that was bought is the membership of the space, channels per book, topic or cohort read as chat, a forum or a feed, the space's feed pinnable in any atproto client, and a member's card showing what they have read, scored and bought | no courses, levels or leaderboards (Skool's classroom and its game); no moderation queue, ranks, events or invitations yet (a coming change) |
| Bluesky, Mastodon | network | the site's own social network: every member a page, follows, a timeline, posts with likes, reposts, replies and quotes, each post to everyone, to the site's own people or to a space's members — closed to the site's people by default, joined to Bluesky's network by the site's switch and each member's consent — the whole of it served as an atproto server and app view, so Bluesky's app and any atproto client sign in with the host swapped | no relay or app view of the whole network (the world outside is read through Bluesky's), no labeler, no encrypted posts, and no static shape |
| Mixpanel | analytics, recommendations | events as the record, dashboards, audiences from what the account knows, personalisation signals | no funnel analysis, cohorts or session replay; an individual is never listed |
| ActiveCampaign | funnels | drip sequences targeted by rules, cooldowns, once-ever per email, chat prompts as steps | no visual automation builder, no SMS |
| Mailchimp | blasts, emails | one-off sends to an audience, designs built in the admin, tracked links, unsubscribe | no deliverability tooling, no templates service |
| Wikipedia, Read the Docs, Docusaurus, Mintlify | wiki and docs collections, search | reference content with its own index and navigation | — |
| Algolia | search | semantic and text search built at build time, instant in the browser, no service | no service |
| Elementor, Plasmic, Builder.io | page builder, experiments | landing pages from a catalogue of some forty sections with schemas and layouts — openers (an announcement, a hero that takes any visual, a marquee), content (features, a split, a bento, steps, a showcase, before/after, a carousel, tabs, a gallery, a video, prose, a timeline, a divider), proof (logos, stats, testimonials, a quote, a comparison, an FAQ, integrations), commerce (pricing, perks, products, a spotlight, collections), people (a team, a newsletter, a contact block, a form), the site's own data (articles, a model's entries), closers (a call to action, a countdown, the close, a footer) — each a form in the admin with one look fold (tone, glow, ground, spacing, width, reveal), drawn in the site's look; A/B tests as their own records | no free-form canvas, no visual A/B editor |
| Typeform, SurveyMonkey, forms.md | forms, and instrument over it | a general-use form builder: a form is a forms.md document (its field kinds, slides, logic jumps, bindings), run by the kit's own runner in the site's design, written by a builder that never shows the grammar, with the backend forms.md lacks — every answer a row as it is given, files in a bucket, a webhook, responses and analytics in the admin — on its own page, embedded, or on a landing page; and, over it, the quiz-scoring / IRT instrument: screens drawn from a bank, scored by the site's registered graders — the forms served over Typeform's own Create (read), Responses, Webhooks and Insights APIs with keys, so Typeform's client and embed work with the host swapped | no payment or signature fields, no matrix, no calculations beyond a score; forms.md's renderer and theming (the site's design instead), its nine languages (the strings scope), its Google Sheets script and CLI |
| ElevenLabs, Audible's pipeline | spoken books | every chapter spoken locally, cached by its text, generated in the browser when missing | no voice cloning, no API — a local model on the CPU and in the browser |
| Weglot, Lokalise | translation | every language as files, audited, served statically per route | the translation module is reserved but not implemented; there is no translation workflow in the product today |
| OneSignal | staff notifications | web push per browser per topic, asked by the database | no segments beyond role and topic, no email or SMS channels |
| Auth0, Clerk | auth | sign-in, staff roles, the app's own confirmation of an address | no organisations, SSO or MFA in this version |
Example site configurations
- Documentation site: enable docs, disable account and commerce modules, and deploy static files.
- Online shop: enable the store and configure payment and shipping; leave the book library and community modules off if they are not needed.
- Paid publication: combine books, memberships, print editions, and email campaigns.
- Member community: combine memberships, spaces, and the support desk; use membership tiers to control access where required.
- Booking practice: enable sessions and configure the scheduler, access rules, and payment method for each appointment.
- Directory: define a content model for each listing type, then publish model entries through the site's pages.
- Assessment product: register an instrument with the site's questions, scoring rules, and results copy.