Nothing to install. No second account.

Your AI made you a website. We give it a real address.

Ask your assistant to publish it. Files, server code and a Postgres database go up in one call, and the link works for anyone you send it to.

Connect your assistant
A Postgres database per siteRow-level security at the deploy gate

you:put this notes app online for me

tool:juudd · deploy_site · 3 files and functions/api/notes.js, stored as v1

tool:juudd · create_database · one Postgres, for this site only

tool:juudd · apply_sql · notes table, and the policy that says who can read a row

answer:Live at https://probe.juudd.app. Every note belongs to whoever wrote it.

you:change the heading to Today

you:add a table for the notes

refused:juudd · apply_sql · refused

answer:notes has no row-level security policy. A table cannot be deployed against until it carries one.

you:add the policy then

tool:juudd · apply_sql · 2 statements, one transaction

answer:notes created, policy on user_id. The deploy gate will pass it now.

you:that last deploy broke the list, put yesterday's back

tool:juudd · list_deploys · 4 stored versions, v4 is current

tool:juudd · publish_deploy · v3

answer:v3 is live again. v4 is still in the store; nothing was deleted.

shell:curl -H 'x-user: alice' https://probe.juudd.app/api/notes

answer:{"who":"alice","rows":[{"user_id":"alice","body":"alice keeps notes"}]}

shell:curl -H 'x-user: bob' https://probe.juudd.app/api/notes

answer:{"who":"bob","rows":[{"user_id":"bob","body":"bob keeps his own"}]}

shell:curl https://probe.juudd.app/api/notes

answer:{"who":null,"rows":[]}

Pick the one you use. Every tool name and every refusal above is one juudd really makes, and the last tab is the deployed demo answering as you read it.

Three steps, and you're online

  1. Step one

    Ask for it in plain words

    "Publish this site." Nothing to configure and no settings to choose, because your assistant is already holding the tools that do it.

  2. Step two

    You get a link that works

    Files and server code go up together, a Postgres database is created for them, and the reply is the address it is live at.

  3. Step three

    Change it whenever

    Ask for an edit and it goes live again. Every earlier version is kept, and putting an old one back is the same call that published it.

Quick connect

Works with the assistant you already use

juudd is a remote MCP connector. Add it once, wherever you already talk to your assistant, and the ten tools appear beside everything else it can do. It signs you in through your browser on the first call, so there is no API key, no token and no header to set by hand.

connector urlhttps://mcp.juudd.com/mcp10 tools
terminalclicktap to select, then copy
claude mcp add --transport http juudd https://mcp.juudd.com/mcp
~/.codex/config.tomlclicktap to select, then copy
[mcp_servers.juudd]
url = "https://mcp.juudd.com/mcp"

then codex mcp login juudd

.cursor/mcp.jsonclicktap to select, then copy
{
  "mcpServers": { "juudd": { "url": "https://mcp.juudd.com/mcp" } }
}
.vscode/mcp.jsonclicktap to select, then copy
{
  "mcpServers": { "juudd": { "url": "https://mcp.juudd.com/mcp" } }
}

With GitHub Copilot

settings

Settings → Connectors → Add custom connector, and paste the URL.

Needs a Pro, Max, Team or Enterprise plan. A config file will not work for these.

wherever it keeps servers

Add a remote MCP server over HTTP at the connector URL.

The server advertises its own authorization metadata, so there is no API key, no token and no header to set by hand.

ChatGPT is not in that list on purpose. Its handling of MCP authentication headers has been inconsistent enough that we would rather leave it out than give you a setup that fails.

What you get, without wiring any of it

Everyone sees only their own

A table cannot go live until it carries a rule about who may read a row. Nobody has to remember to switch privacy on, because nothing gets deployed until it is on.

notesone tablepolicy onaliceher one notebobhis one notea strangernothingnotespolicy onaliceher one notebobhis one notea strangernothing
One address, one table, three answers. Nothing in the site's own code decides which rows come back.

A page that stays up

Real hosting on a subdomain of ours, not a preview that expires.

A database of its own

One Postgres per site, created for it and wired into your server code as env.DATABASE_URL.

Every version kept

Publishing an older one is how a rollback happens, so the rollback is exercised every time anyone deploys.

Yours to take away

One call moves the database into a Postgres account of your own, after which this platform cannot read it, back it up or get it back. No deadline, and a new link can be minted whenever you ask.

How the exit works

Things we'd rather you hear now

Straight answers

Four limits, stated before you build on it.

It will not build a framework project

Server code is plain JavaScript, and the only import from npm that is allowed is the Neon driver. There is no install step and no bundler, so a Next.js or Vite project has nothing here to build it.

It will not show server logs

There is no way to read what a function printed. What a request returns is what you have to debug from, so write your functions to answer with the thing that went wrong.

It will not delete anything

Every version you deploy stays in the store, which is what makes a rollback a publish and not a restore. It also means a site cannot be wiped clean, only replaced.

It will not serve a custom domain

Your site gets a subdomain of ours and lives there. Pointing your own name at it is not supported yet, so a site that must answer at your address is not a fit today.

Ask your assistant to publish it. That's the whole thing.

Add the connector, then describe what you want. Everything it will refuse is written down above, and the database it makes for you is one call away from being yours.

Connect your assistant