To deploy a website from Cursor, Claude Code or Antigravity, point the agent at
https://dashploy.com/llms.txt with a DashPloy token, or add the MCP server at
https://dashploy.com/mcp. The agent then deploys with one API call, gets back
a live HTTPS URL, and when a deploy fails it receives a structured error with a
hint it can act on in the same turn.
This page is the developer version. If you just want your site online, how to deploy a vibe-coded website is the one to read, and Cursor website hosting and Claude website hosting cover each tool in plain steps.
The two ways in
The paste line. The agent reads llms.txt, which is written for it: how to
check it can actually publish, how to authenticate, what to deploy, and what
each error means. Nothing to configure. This is what the dashboard hands a new
user.
The MCP server. Typed tools instead of HTTP: deploy, get_logs,
set_env, add_domain, whoami, restore_deployment and the rest.
Streamable HTTP, POST only, with OAuth 2.1 and dynamic client registration, so
a client that supports it signs the user in with a click. A client with no
OAuth can send the token in X-API-Key.
Both are the same platform, with the same errors.
One API call
curl -X POST https://dashploy.com/api/v1/deploy \
-H "Authorization: Bearer $DASHPLOY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"project": "my-site",
"files": [
{ "path": "index.html", "content": "<!doctype html><h1>Hello</h1>" }
]
}'
The project name becomes the subdomain and is created on first deploy.
Binary files go as base64 with "encoding": "base64". Redeploying replaces the
site, and blobs are content-addressed, so an unchanged file is never written
twice.
What you can deploy
| Project | What to send |
|---|---|
| Static site | HTML, CSS, JS, images. Needs index.html at the root |
| React, Vue, Svelte, Astro | Run the production build and send the contents of the output folder |
| Server-side app | TypeScript or JavaScript with a default fetch export, or a Hono app |
Detection is automatic. TypeScript is compiled for you, with no build step and no bundler config.
Server-side apps run in a V8 isolate, not Node. Dependencies are not installed
from npm: a curated set is available, including hono, zod,
@neondatabase/serverless, @upstash/redis, jose and bcryptjs. Native
packages and child_process are not. llms.txt has the full list, and
importing anything else fails with an error naming the alternatives.
Errors are for the agent
Every failure returns a code, a message and a hint written for the model:
what to change, whether retrying can help, and when to stop and tell the user
instead. A missing index.html, an unavailable package, a name somebody else
owns and a plan limit each come back with the fix in the hint.
Two guard rails worth knowing about. Deploying over a project that already has
a live site is refused unless the request says "replace": true, so a second
agent cannot silently overwrite the first one's work. And publishing deletes
nothing: every version is kept, and restore_deployment puts any of them back.
Secrets, logs and domains
Environment variables are set with set_env. Values are encrypted and
write-only: you can list the names and delete them, never read a value back,
and a redeploy is what makes a change take effect. get_logs returns an app's
console output and uncaught exceptions. connect_domain attaches a custom
domain and says whether the user has DNS records to add; the free plan
includes one.
Questions developers ask
Is there a CLI?
No. The agent is the client: it calls the API or the MCP server directly, and there is nothing to install on our side.
Can I call OpenAI, Anthropic or Gemini from a server-side app?
Yes. Outbound requests go through an allowlist that includes all three, plus Stripe, GitHub, Resend, Supabase, Upstash and Neon. Anything else is refused and logged, and the list grows from what people ask for.
Where is the full reference?
The API reference lists every endpoint, and /llms.txt is the version written for your agent.