Privacy Policy

juudd — Just Upload. Done. Deployed.

Operated by MATTREK TECHNOLOGY CO., LTD. (บริษัท แม็ทเทรค เทคโนโลยี จำกัด), 147/169 หมู่ที่ 3 ตำบลสวนหลวง อำเภอกระทุ่มแบน จังหวัดสมุทรสาคร 74110, Thailand. Effective September 2, 2026. Last updated October 15, 2026.

This policy covers juudd.com, the connector at mcp.juudd.com (including when you use it as an app inside ChatGPT, Claude or another AI assistant), 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.

At a glance

Every category of data juudd handles, why, who else receives it, how long it is kept, and what you can do about it. The sections after this table explain each row.

We do not sell any of this, we do not use it for advertising, and we do not use it to train AI models.

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. When an AI app connects, it introduces itself by a name and version it chooses, and we keep that against your account with when we first and last saw it, so we can tell which apps people reach us through.

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.

Operators are people on our side who can look across accounts. There are only ever a handful, each is a row we add by hand, and it is not a role anyone can grant themselves.

If an operator opens your account's history, that read is written into the same history, under your account, naming the operator. One thing is not: we also have a platform-wide view of recent activity across every account at once, and opening that is recorded against the operator who opened it rather than against everyone who appears in it. So a line of yours can be seen there without a line appearing in your history. Anything an operator does to your account (stopping a site serving, putting it back, suspending or restoring the account, releasing a domain) is written under your account, naming them, as it always was.

To show an operator a name rather than an identifier, we ask WorkOS who a subject is and hold the answer in memory for a few minutes. It is never written to our database, so it is not part of what we keep, below.

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.

Builds and uploads. A project that needs building reaches us one of two ways. With start_build, your assistant sends the project's source; we run the build on a Cloudflare sandbox reserved for your account, using our own pinned toolchain, delete the working folder when the build ends, and store only the output as a version. We keep a record of the build (framework, outcome, any error, and the last 6,000 characters it printed) so build_status can report it. With request_upload, you build on your own machine and a script posts the output to a link that works once, for fifteen minutes, for one site. We store a one-way digest of that link, never the link itself, and delete the record a day after it expires.

Secrets. request_secret declares a name (like STRIPE_SECRET_KEY) and gives you a link to the panel. You type the value there, never into the conversation. The value goes straight onto your site at Cloudflare as a binding we cannot read back; we store only the name and whether it has been set. Taking a site off the air discards the values, and you set them again before it serves.

When your site fails in front of a visitor. If a visitor's request to your site ends in a 500 or 503, our front door counts it: the site, the request method, the path without its query string, which of the two outcomes, and the hour. Nothing else: no IP address, no headers, no body, nothing your function printed. The counts are deleted automatically after seven days, and site_errors reads them.

Conversations with juudd's assistant. If you use the assistant juudd runs, rather than connecting your own, we keep what you typed and what it answered, with the names of the tools it used, for 30 days after your last message in that conversation, and then delete it. You can delete a conversation yourself at any time. We do not keep what the tools sent or returned: site files are already in your stored versions, and query results or hand-over links are not written down anywhere. The table that holds a message has no column they could go in.

Photos you add there. The assistant's page lets you attach photos to a message, up to six at a time. Your browser shrinks each one before it leaves your phone, and we keep it under your account, named by a digest of its own contents. The photos are sent to Anthropic with that message, so the model can see them: to decide where each one goes, to describe it for visitors who cannot see it, and to read the items, prices and details from a photo of a menu, a price list or a sign. They are sent with the message you attached them to and not again with later ones; the conversation we keep holds only each photo's name. The model never writes the photo out: the assistant puts our stored copy on the page. The site then holds its own copy: what a visitor loads comes from the site, not from us. Nothing deletes the one we hold. Deployed versions are permanent by design and a photo used on a page is part of one, but the copy you uploaded is kept whether you used it or not, and no automatic deletion is built. We would rather write that down than state a period nobody enforces; ask us and we will remove it.

The one credential we keep. An access token from sign-in lives five minutes, and a build you asked the assistant for can run longer than that, with you switched to another app. So a deployment running the assistant asks for a refresh token at sign-in and keeps it — one row per account, encrypted with AES-256-GCM under a key that lives in the service's environment and not in the database, tied to your account so a copy of the row under another account does not open. It is spent and replaced when your access token is nearly out, deleted when you sign out, and removed after two days without use. This is the only credential of yours we hold, and it is worth being plain about: we designed secrets (below) specifically so we would not hold them, because a secret has somewhere else to live. A refresh token for a job you are watching has nowhere else. What it reaches is your own account and nothing more.

Beside it we keep one row per answer the model gave — which model, how many tokens went in and came out, and what that cost. That row is what your allowance is counted against and what a top-up is drawn from, so it outlives the conversation it came from; it holds nothing you typed.

One email when your first site goes live. When the first version of the first site on your account is published, we ask WorkOS for the email address you signed in with and send you one email: your site's link, how to change it or put it on your own domain, and that you can reply to reach a person. The address goes from WorkOS to us to Resend, which sends the email, and we do not store it. A second site, a redeploy or a rollback sends nothing, and there is no mailing list.

Problem reports, and when you get stuck. The panel has a form for telling us something went wrong. We keep what you write, the error message the panel was showing when you opened the form, which panel page you were on, the site if it is one of yours, and the time, for 180 days, and email a copy of it to ourselves so a person sees it; the copy in our mailbox is not deleted on that schedule. Separately, if you are refused the same action on the same site three times within fifteen minutes, we email ourselves the refusal from your action history, so we can help you without your having to write in. Neither adds anything to what is described above: the report is only what you typed and our own error message, and the refusal is a line your history already holds. Do not paste a password or an API key into a report.

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. The only trace a visitor leaves with us is the seven-day failure count described above, which holds a path and no information about who asked for it.
• Your conversation, when the assistant is your own. Connect your own assistant and we never receive your chat history, your prompts, or its replies: the connector sees only the arguments of each tool call it makes, listed below, and nothing else. The exception is the assistant juudd runs, where the conversation is with us and is described above — it is named here rather than left for you to notice. Either way we do not ask for your location, contacts, or any profile data.
• Payment cards, passwords, or API keys through the assistant. No tool asks for a card, a password, or an API key. Secrets are entered in the panel, not passed to a tool. The one exception is set_database_url, below.
• 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. Read this bullet as what it says and not as "no credentials at all": if you use the assistant juudd runs, we keep one sealed sign-in token of yours, described above.

What each tool takes, and what it returns

These are the connector's tools as they run today. "Recorded" means the call is written into your action history as described above; tools marked read-only record nothing when they succeed, and every refusal is recorded.

One thing to understand about the channel

You use juudd through an AI assistant, either your own or the one juudd runs. 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.

When the assistant is juudd's, that conversation goes to Anthropic, which deletes API inputs and outputs within 30 days, except where its Usage Policy is enforced, when they may be kept for up to two years (Anthropic). It is not used to train models.

Where data lives, and who touches it

Our infrastructure runs in Singapore. These providers process data for us:

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.
• Stop serving. unpublish_site takes a site off the air at once. Nothing stored is deleted, and publish_deploy puts it back.
• See what we recorded. Your sites, versions and action history are in the panel; list_refusals, list_secrets and site_errors answer from inside the conversation.
• Access and correction. Ask us and we will show you what we hold; most of it is already visible in the panel.
• Delete a conversation. A conversation with juudd's assistant has a button that deletes it, and its messages go with it. It is the one thing here you can erase without asking us.
• Deletion. Honestly: a self-serve deletion path for everything else is not built yet. Deployed versions are permanent by design. Your identity records and action history can be removed on request; write to support@juudd.com, 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 support@juudd.com. 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.