A page that stays up
Real hosting on a subdomain of ours, not a preview that expires.
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.
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":[]}
Open it in a browser and you are the third request: no header, so no rows. https://probe.juudd.app/api/notes
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.
"Publish this site." Nothing to configure and no settings to choose, because your assistant is already holding the tools that do it.
Files and server code go up together, a Postgres database is created for them, and the reply is the address it is live at.
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.
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.
claude mcp add --transport http juudd https://mcp.juudd.com/mcp[mcp_servers.juudd]
url = "https://mcp.juudd.com/mcp" then codex mcp login juudd
{
"mcpServers": { "juudd": { "url": "https://mcp.juudd.com/mcp" } }
}{
"mcpServers": { "juudd": { "url": "https://mcp.juudd.com/mcp" } }
}With GitHub Copilot
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.
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.
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.
Real hosting on a subdomain of ours, not a preview that expires.
One Postgres per site, created for it and wired into your server code as env.DATABASE_URL.
Publishing an older one is how a rollback happens, so the rollback is exercised every time anyone deploys.
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.
One tool that takes no site, and therefore the only one with nothing to authorise.
Every version is kept. Publishing an older one is how a rollback happens, and it is the same code path a recovery runs.
One Postgres database per site. A table without a row-level security policy cannot be deployed against, and the exit is one call with no deadline on it.
Four limits, stated before you build on it.
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.
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.
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.
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.
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