Privacy Policy
juudd — Just Upload. Done. Deployed.
Operated by MATTREK TECHNOLOGY CO., LTD. (บริษัท แม็ทเทรค เทคโนโลยี จำกัด), 147/169 หมู่ที่ 3 ตำบลสวนหลวง อำเภอกระทุ่มแบน จังหวัดสมุทรสาคร 74110, Thailand. Effective September 2, 2026.
This policy covers juudd.com, the connector at mcp.juudd.com, and the signed-in panel. It does not cover the sites our customers deploy: those belong to the customers who deploy them, and what a deployed site does with its own visitors is between that site and its visitors. The section "Your site's end users" says who is responsible for what.
We wrote this the way we write everything else: every statement here is one we can point at in our own system. Where something is not built yet, we say so instead of promising it.
What we hold about you
Your account. You sign in through WorkOS AuthKit; there is no separate juudd password and no API key. What we keep is the subject identifier your sign-in token carries, the token's issuer, and an email address if the token ever includes one. Your account id is derived from that subject and nothing else.
What you did, and what you were refused. Every action that changes something (a deploy, a database created, SQL applied, a domain claimed) is recorded: which account, which action, which site, when, and whether it was allowed or refused, with the refusal's exact wording. Refused reads are recorded too. This history is how we can answer "what happened to my site on Tuesday", and it accumulates; we have not yet set a retention period, and this policy will change when we do. The record never contains a credential, and the SQL statements you run are not recorded — those are your data, and only the fact that SQL ran is kept.
One exception, because it is the kind of thing a policy should not leave you to discover: when Postgres refuses a statement, we keep its error message, so that you can be told exactly why. Postgres sometimes quotes the offending value in that message — a duplicate email address, for instance — so a failed apply_sql can leave a fragment of your data in this history. Successful statements leave none.
If one of our operators looks at your account, that read is written into the same history, under your account, naming the operator. Operators are a short allowlist, not a role anyone can grant themselves. And when you read your database's owner connection string in the panel, that read is recorded in your history too, because handing out an owner credential is an act worth being able to look back at.
What you deploy. Your site's files and server-side function code, every version, kept permanently. This is a promise, not an accident: it is what makes a rollback possible. It also means a site can be replaced but never wiped. Treat everything you deploy as public and keep secrets out of it; the tools tell your assistant the same thing.
Your site's database. Each site gets its own Postgres database, created in our account at Neon. Until you take it with transfer_database, we hold it, and our tools run SQL against it only when you ask them to. We do not read it for our own purposes, ever; whatever your site stores in it about its own users is yours, not ours. The owner connection string is shown to you, a person, in the panel; it is never handed to an assistant, because a tool result is not a safe place for a credential. After a transfer we cannot read, back up, or recover that database at all.
Billing. Payments are not live yet. When they are, they will be handled by Stripe; your card details will go to Stripe and never to us, and we will keep only the Stripe customer id that links your account to your subscription.
Operational logs. Our servers log each request's method, path, the names of query parameters (never their values, never a request body), whether it carried a token, the client's user-agent string, and how long it took. Our storage provider writes its own access log of bucket operations.
Analytics on the marketing site only. juudd.com uses Google Analytics 4 (property G-T38LE5HK7G) to count page views. The page works exactly the same with the tag blocked. The panel and the connector carry no analytics.
What we do not have
- Server logs from your site. Nothing captures what a deployed function prints. There is no runtime log for us to read, sell, or leak.
- Your site's visitor traffic. Requests to deployed sites go to Cloudflare's edge and are served there. They never reach our servers and we keep no record of your visitors.
- Your database credentials. Connection strings are fetched from the provider when a tool needs one, held for the length of that call, and not stored. A credential you paste into set_database_url is written onto your site as a binding we cannot read back, and is neither stored nor logged by us.
One thing to understand about the channel
You use juudd through an AI assistant. Some tool results flow into that conversation: rows returned by apply_sql, and the one-time hand-over link from transfer_database. Your AI provider keeps its own logs of that conversation under its own policy. The channel is the product working as designed; it is also outside our control, and worth knowing about before you query personal data through it. Your database's owner credential does not travel this channel: it is shown only to you, in the panel.
Where data lives, and who touches it
Our infrastructure runs in Singapore. These providers process data for us:
| Provider | What it receives |
|---|---|
| WorkOS | Your sign-in; it is the identity provider |
| Neon | Your site's database, and our own control-plane database (accounts, ownership, action history) |
| Wasabi | Your deployed files and function code (Singapore region) |
| Cloudflare | Serves all deployed sites and juudd.com; sees visitor traffic to them; issues certificates for custom domains you claim |
| Railway | Hosts our servers, including their request logs |
| Stripe | Payment details, when billing goes live |
| Page-view analytics on juudd.com only |
Your site's end users
For personal data your deployed site collects from its visitors, you are the data controller and we are a processor, with the providers above as sub-processors. We never use your end users' data for our own benefit. Thailand's PDPA applies to us; if you collect personal data through your site, complying with the law that applies to *you* is your job, including telling your visitors what your site does.
Your rights
- Take everything out. read_site returns every file of every version. transfer_database hands you your database, with no deadline and no penalty. Portability is a feature here, not a concession.
- Access and correction. Ask us and we will show you what we hold; most of it is already visible in the panel.
- Deletion. Honestly: a self-serve deletion path is not built yet. Deployed versions are permanent by design. Your identity records and action history can be removed on request; write to alongkot.sa@mattrek.co, which a person reads, and we will handle it manually.
Changes and contact
If this policy changes, the change will say what changed. Questions go to alongkot.sa@mattrek.co. We have not appointed a Data Protection Officer; requests under Thailand's PDPA, including deletion requests, go to that same address, and a person reads it.