Use cases
What you can do with Whoobe
One capability per card, with an everyday example and where to read more. Only what the current release does; the limits are below.
Ten things, in plain words
One place for product data
The catalogue that lives in spreadsheets, the ERP and the website becomes a Data Class. The people who own it edit it in the dashboard, with validation, a published flag and an optional workflow; the site, the app and partners read the same source.
Example: A product sheet is changed once; the site, the app and the reseller's feed show it.
Files out of the shared folders
Photos and technical PDFs go into the asset library: private while they are prepared, mirrored to a CDN when they are published.
Example: The new brochure is uploaded once, kept private until launch day, then served from the CDN.
A landing page without a ticket
A visual block editor with themes and pages bound to data. A site can also start from the website wizard or from a specification written by an AI assistant.
Example: Marketing builds the campaign page, and its prices stay right when the catalogue changes.
Each application gets only what it needs
An API client has its own key (or a token of your identity provider), scopes, a request limit and a log. No database credentials, no VPN.
Example: The agency building the mobile app gets "read the catalogue, create orders", nothing else, revocable at once.
Third-party passwords stay on the server
The credentials of the CRM, the mail service or the payment provider are held by the Gateway. Sites and apps call the Gateway, never the service.
Example: The CRM key is changed in one place; no app is rebuilt and no browser ever sees it.
When X happens, start Y
Forms, Data Objects, files and pages emit events, delivered as signed webhooks with retries to the engine you run: n8n, Activepieces, a script. Whoobe ships none and prefers none.
Example: A "request a quote" form sends an event; your workflow creates the lead in the CRM.
Answers for the security officer
An audit log, mandatory two-factor authentication for the roles you choose, single sign-on with your OpenID Connect provider, data subject requests and retention. Signed images, SBOM and test results with each release, failed runs included.
Example: "Who changed the price list last Tuesday?" is one filter in the audit log.
It runs on your servers
Self-hosted with Docker Compose, MIT licence. The private profile runs on a network with no route to the internet. One installation per organisation.
Example: An installation inside the company network, with no call leaving it.
Many clients without mixing them
One isolated workspace per client, and fleet commands for the status, the backups and the upgrade of all of them.
Example: An upgrade tried first on one client's workspace, then on the others.
Try it in five minutes
A public sandbox with a demo login, reset every three hours, or ./try.sh on your own machine.
Example: Open the sandbox, sign in with the account in the banner, build a page.
What to know before you decide
A 0.x series: behaviour can change between minor releases; the release notes say what.
Single sign-on is tried with one OpenID Connect provider (Keycloak); no SAML or LDAP without a broker.
No high availability yet: one instance per service; recovery is a restore from backup.
No third-party certification and no outside penetration test.
One stack instead of four
Instead of a CMS, a DAM, a PIM and an API gateway to buy, integrate and keep running: one self-hosted stack with one permission model and one log, which you can try today without installing anything.