Your drawings, BOQs, variation records and QA evidence are the things you would argue a claim with. This page says where they live, who can reach them, and what we do not yet have.
It is written in two layers. In plain terms is seven answers for the person deciding. The technical detail below it is for the reviewer who wants to check us rather than take our word — hosting, isolation, the audit trail, and the gaps.
Figures measured on the production database, 5 September 2026 — after 41 disused internal tables were removed — working copies made during earlier database upgrades, never reachable by the application. An earlier version of this page counted 94 for that reason. The schema got smaller; nothing a customer uses was touched.
Seven answers for the person who has to decide, without the engineering. The detail behind every one of them is further down, and your IT reviewer will want that part.
Worth stating plainly rather than leaving to a procurement questionnaire, because for some buyers it decides the deal.
No. Today it sits in Mumbai (ap-south-1) or Tokyo (ap-northeast-1), and we tell you which before you sign. We do not currently offer in-country hosting in the GCC.
If your organisation is subject to Saudi or UAE data-residency or cross-border-transfer rules, that is a real constraint and you should weigh it before, not after. For a buyer whose policy requires in-country storage, a dedicated deployment in a region you specify is an Enterprise conversation — ask us and we will tell you honestly whether we can meet the date you need.
We would rather lose a deal on this page than fail an audit after signing.
The processors are listed under “Who else touches your data” below: the database and storage platform, the static web host, and a transactional email service. Nobody else. A data processing agreement is available on request — write to support@muthari.com and we will send the current one rather than promise a template.
Not today. Encryption at rest is AES-256 managed by the platform. Customer-managed keys would require a dedicated deployment, and we will say so rather than imply the option exists.
Everything below is written for a reviewer who wants to check us rather than take our word. It is the same set of answers, with the specifics.
These are what a contractor’s technical reviewer actually asks. A certificate does not answer any of them. If a vendor cannot answer them specifically, that tells you more than a badge does.
Supabase, running managed PostgreSQL 17 on AWS, in one of two regions: Mumbai (ap-south-1) or Tokyo (ap-northeast-1). Your tenant sits in one of them and we tell you which before you sign. The application itself — the HTML and JavaScript — is static, served from separate hosting that stores no customer data at all. Exactly which parts of Supabase we use, and what travels through each →
Yes — AES-256, provided and key-managed by the database platform. We are precise about this because it matters: that is the platform’s control, operated by them, not something we implement. Customer-managed keys are not available today.
Yes. TLS 1.3 with AES-256-GCM. Strict Transport Security is set for a year including subdomains, so a browser refuses to speak to us unencrypted even if asked to. Clickjacking and content-sniffing protections are set at the same layer.
HSTS max-age 31536000 · X-Frame-Options DENY · X-Content-Type-Options nosniff
By the database, on every table without exception. The publishable client key grants no access to customer data. Data access requires a valid authenticated session, and PostgreSQL row-level security independently enforces the tenant boundary on every read and every write.
Put plainly: the filter lives in PostgreSQL, not in our application code, so it is not something a request can supply, omit or talk past. How that is wired →
Row-level security on all 54 tables · zero exceptions
Yes, and further than most. Beyond company separation, write access is checked against the specific right an action needs — stock movements require the stock right, drawing releases require the engineering right — and that check is also a database rule. Hiding a button is a convenience on top of our access control, never the access control itself.
~50 named rights, each assignable by you
Technically yes, and we will not pretend otherwise — every SaaS provider with a database can reach what is in it. What we can tell you is the shape of it. Access runs through a separate administrative console protected by a secret key and a time-based one-time code, every action it takes is written to an audit table, and it exists for support and billing rather than browsing. Customer-managed keys, which would remove even that, are not something we offer yet.
In object storage separate from the database, reached only through a server-side upload service that checks who you are, which company you belong to, and whether you hold the right to attach a file to that record. Files are addressed by identifiers nobody can guess by counting upward, and download links expire.
No, and we would rather say so plainly than let a file-type check be mistaken for one. What is enforced server-side is a fixed list of accepted file types — PDF, common images, Office documents, CSV, and DWG/DXF drawings — and a 30 MB ceiling per file, both checked in the upload service rather than in the browser.
Automatically and daily by the database platform, with point-in-time recovery on the production tier. Separately, you can take a complete export of your own whenever you like — see question 15.
From platform backups, within the retention window, by raising a support request. There is no self-service undelete in the product today.
Every stage change on every zone records who did it, when, from what previous value, and from which screen. Entries are appended and never edited. Movement through the workflow is forward-only at a single enforced gate; legitimate reversals use their own route and require a written reason. Records state facts rather than judgements — an approval made outside the usual route reads “Direct approval by [name]”, never an accusation. Those names stay in the record permanently.
Changes and approvals, yes, in full and permanently. Downloads through shared links are recorded with the link. A complete per-user document read log is not something we offer today.
All three. Roles are defined by you rather than by us: you build your own designations from about fifty individual rights and assign them to your people. Nothing in our access control is keyed to a job title we invented, so a company that calls the role something else still works.
Deactivating the account blocks any new sign-in immediately and ends every session that account already holds, on every device, at once. That is enforced by the database itself, so it holds even if the account is deactivated outside the application. Their name stays on every record they touched, because the audit trail is a permanent account of what happened and removing people from it would defeat the point.
Yes, and without asking us. One control in Company Settings exports your workspace as structured data and as an Excel workbook you can open and read. The workbook carries fourteen registers: projects, BOQ items, zones, purchase orders and their lines, requisitions, delivery notes, inspections and NCRs, the stock catalogue, batches and movements, suppliers, trips, and people. You do not need us present, and you do not need to be leaving.
Two limits, stated rather than glossed. Uploaded files are not inside the package — they arrive as a manifest of time-limited download links, and bundling them properly is listed below. And the per-zone history travels inside the structured data, but the new tamper-evident chain described in question 11 is not yet a register of its own in the workbook.
Worth stating precisely, because the answer to question 5 only means something once you know where the checks sit. There is no Muthari-operated application server. Your browser talks to Supabase, and the database is what enforces every rule.
Browser (static HTML and JavaScript, stores nothing)
|
|-- project data ---------> Supabase REST --> PostgreSQL
| row-level isolation on every table
|-- privileged actions ---> Database functions --> PostgreSQL
| sign-in, password change, audit entries
|-- files ----------------> Edge function --> Object storage
| checks session, right and quota,
| then issues a single-use signed link
|-- live updates ---------> Realtime
| a channel scoped to your company
'-- email ----------------> Edge function --> Resend
sign-in and account notices onlyDatabase. All project data. The browser reads and writes over Supabase’s REST interface, and every table filters on the company of the calling session — in PostgreSQL, not in our code.
Database functions. Anything privileged: signing in, changing a password, minting document numbers, writing audit entries. They take no account identifier, so a browser cannot name someone else.
Object storage. Drawings, photographs and documents. The browser never reaches storage on its own credentials. It asks a server-side function, which checks who you are, which company you belong to, whether you hold the right and whether you are inside your storage allowance — and only then issues a single-use signed link. Downloads work the same way and expire.
Realtime. Live notifications only, on a channel scoped to your company. No project content travels on it.
Edge functions. The file service above, transactional email, and website analytics that carry no customer data.
Not used: Supabase Auth. Accounts are username-first, because site crews often have no company email. We run our own session tokens and our own password verification.
Nothing on its own, and it is public by design — Supabase calls it the publishable key, and every application built this way ships one. It names the project. It grants no access to data.
Access comes from a separate session token issued when you sign in. Every rule in the database is written against that session, so a request carrying only the public key returns an empty result, and an attempt to write is refused outright. We test it in exactly those terms: with no session, with another company’s session, and by asking for another company’s rows directly by name.
The consequence worth understanding: the database is the security boundary, not the application. A rule written in application code protects whoever goes through that code. A rule written in PostgreSQL protects the data from anything that reaches it.
A short list is a feature. Every additional processor is another company you have to trust and another place your drawings can sit.
Managed PostgreSQL, object storage, server functions and realtime, running on AWS in the region assigned to your tenant. This is where your project data lives.
Serves the static application shell and this website, and nothing else. It holds no customer data and never sees a request for any — the application runs entirely against Supabase.
Transactional messages only: sign-in and account notices. No project content.
Published because a vendor who lists only strengths has told you nothing. The dates are our working targets and we will keep this page honest about them — they are not contractual commitments, and we would rather you held us to the list than to the calendar.
If you are evaluating Muthari for real project data, we will walk your IT reviewer through company separation, authorisation, storage and recovery in as much depth as they want, on a call, with the database open. Any vendor who answers that request with “everything is secure and encrypted” is telling you something.
support@muthari.com — including for reporting a vulnerability. We acknowledge within two business days and we will not threaten anyone who reports one in good faith.
Email support@muthari.com