Unify your stack.
Whoobe is a self-hosted platform that puts a visual page editor, a data model you change without a developer, a media library, a gateway to your existing systems and event-driven automation in one installation that you run.
Open source. One organisation per installation. No per-user, per-page or per-call fee.
Five products, five contracts, five places where a secret can leak.
A CMS, a page builder, a data model, a media library and an integration layer are usually bought and operated separately. Each has its own login, its own permission model and its own copy of your credentials.
CMS
Content and pages, edited by one team.
Data model
Products, people, events, kept in another system.
Media library
Files on a third service with its own rules.
Integrations
Glue code, with API keys in more than one place.
Mobile app
A separate build chain fed by hand.
Whoobe keeps these in one model, one permission system and one place where credentials live.
Four layers, one installation.
Data at the bottom, services above it, the applications people use, and the channels that publish. Everything goes through one reverse proxy; databases and storage are never exposed.
The same content and data leave as a Next.js, Nuxt or static website, a Capacitor mobile app, a headless API and documentation sites.
The admin dashboard manages data, media, pages, integrations and settings. The visual editor builds pages, snippets and templates, with a preview that is the real renderer.
The Core API owns records, permissions and the events they produce. The Gateway holds Integrations and credentials and delivers events and form automations to your systems. The asset processor handles uploads and thumbnails.
PostgreSQL holds records, pages, events and settings. Files live in any S3-compatible store. No queue, cache or search engine to run.
Outside Whoobe. An automation engine of your choice, a back-end of yours, a CRM, an ERP or a mail provider. Whoobe tells them that something happened and they decide what to do. Their credentials stay on the Whoobe server.
Eight areas, one installation.
Each area is documented on its own; this is the map.
Content
Visual editor for pages, snippets, kits and templates, with a live preview that is the real renderer. Themes, languages, documentation sites.
Data (PIM / MDM)
Classes and objects defined at runtime: fields, relations, reusable components, languages, draft and published states. Bind any element to your data.
Communication
Integrations describe an API once and bind it visually. Automations start flows from forms and from record changes. Client Hub lets your own apps use the same gateway.
DAM
Media library on S3-compatible storage with folders and visibility rules, image transforms, thumbnails, versions and an optional CDN mirror.
AI
Page, snippet and image generation and translation with the provider and key you choose. No AI vendor is built in.
Settings
General, DAM, classes, users and roles, two-factor authentication, workflows, mail, PWA and uploads in one place.
Security
Roles and permissions per route, encrypted credentials, an outbound address guard, rate limits, a published-only public surface, a written threat model and a test suite.
Operations
Create a workspace, TLS, backup and restore, upgrades, a configuration reference and observability.
Whoobe tells your service that something happened. The service decides what to do.
Whoobe does not run the automation and does not prefer an engine: n8n, Activepieces, Node-RED, Make or a back-end of yours all receive the same call. The event carries the names of the changed fields, never their values.
A record changes
A person, an API client, an import or a form writes a record.
The event is stored
In the same database transaction as the change: if the change rolls back, there is no event.
Filters and loop protection
Class, event type, an ignore list, an explicit end-of-flow header and a loop guard decide whether to send.
The gateway delivers
A signed HTTPS call through an Integrations route, retried on failure and logged as delivered, retrying, gave up or stopped.
Your service decides
It reads the record through its own API client and may write back.
The same pages and data feed every channel.
Nothing is re-entered per channel.
Website
Generate a Next.js, Nuxt or fully static site from a Whoobe website.
Mobile app
Generate a native iOS and Android app with Capacitor from the pages built for it.
Headless API
Read published content and data through the API from your own front end.
Documentation sites
Publish documentation written in the same tool, with search.
Where it fits, and where it does not.
A good fit
+ An organisation with a technical team or a partner that wants to own its web platform.
+ A company with several sites, or an agency running one workspace per client.
+ A team whose integrations no off-the-shelf connector covers.
+ An organisation that wants its applications to share one governed gateway to internal systems.
Not today
- A team with nobody to run a server.
- Single sign-on for staff, a full audit trail of administrative actions, high availability or a third-party compliance certificate.
- One shared platform for many unrelated companies: an installation serves one organisation.
Few moving parts.
Five application containers, PostgreSQL and an S3-compatible store. There is no queue, cache service or search engine to run.
One reverse proxy
Everything goes through it; databases and storage are never exposed.
One workspace, one organisation
Isolation is a separate stack, not a column in a shared table.
Published-only public surface
One shared query rule serves public content; the editor and the published site use the same renderer.
Use the demo or run your own.
Public demo
A sandbox that resets every three hours. The login is public: demo@whoobe.example with the password whoobe-sandbox-demo. Do not enter real data.
Run it locally
Node.js 18+, pnpm and Docker. The README covers the evaluation, development and production setups.
git clone https://github.com/swina/whoobe_project
cd whoobe_project
pnpm install
docker compose up -d --build
The decisions, the threats and the open findings are written down.
The licence is MIT. The design choices, the threat model and the register of open security findings are public, so you can judge the product by reading them.