Skip to content
Falrow
Your data, your server

One codebase. One database file. Yours.

The web app, the CRM, the REST API and the MCP server are one TypeScript application on one SQLite database. It is built to run on a server you control, which means your roadmap, your client records and your meeting notes do not have to live in someone else's cloud.

One file

Everything is in one place, on purpose

There is no separate analytics store, no queue you also have to back up, and no second database holding the CRM. Every ticket, cycle, customer, meeting note, document, saved view and report is in the same SQLite file, so backing the product up is copying one thing and restoring it is putting one thing back.

That is also why the app, Slack, the API and your agents never drift apart. They are not syncing copies of each other. They are four doors onto the same records.

npm run db:backupAn online SQLite backup with a SHA-256 manifest, taken while the app is running.
npm run db:verifyChecks a bundle against its manifest before you rely on it. A backup you have never restored is a hope, not a backup.
npm run db:restoreRestores to a new file, revokes access copied along with the data, and pauses pending jobs so a restored worker does not re-send yesterday's notifications.
Access, the same everywhere

Who can do what, checked in one place

A role is not a setting per integration. It is one answer the service layer gives, and the browser, Slack, the REST API and every MCP tool ask the same question.

Four rolesOwner, admin, member and viewer, with the same checks in the browser, in Slack, over the REST API and through every MCP tool. There is no back door that skips them.
Scoped accessOAuth with read or write scope and rotating refresh tokens, workspace tokens that expire after 90 days, and sessions you can revoke.
Secrets encryptedSlack bot tokens and Granola API keys are stored with AES-256-GCM. Passwords are hashed with scrypt, and logins are throttled.
Hardened requestsA fresh script nonce on every page, bounded upload sizes, and read deadlines on the API and MCP endpoints.
Said plainly

Self-hosting is what the application is built for, not a managed service we run for you with an uptime figure attached. During the private beta we host beta workspaces ourselves and will hand over the deployment when you want it. Tell us in your access request if running it yourself is the point for you.

And for the humans

Owning your data should not mean putting up with the interface.

C creates a ticket where you are,⌘K searches everything, in light or dark.

Keep the plan on a server you control

Request access and tell us how you want it hosted. We will be straight with you about what is ready today.

Request accessSee the product