DeployX docs

DeployX puts an app on a live URL and runs what it needs beside it: domains, variables, data, files, schedules and monitoring. Static sites, build output and Claude artifacts go live on DeployX Sites with no keys. Apps that need a server build, such as Next.js, run in the Vercel account you connect, so the code and bill stay yours.

1. Create an account and confirm your email.
2. Open New project and pick a starter, paste a Claude artifact, drop in a folder, or import a GitHub repository.
3. For a server app, connect a Vercel token in Settings → Providers. Add a GitHub token too if your repositories are private.
4. To deploy from an AI agent instead, open Agents and follow the three steps there.

What DeployX deploys

44 stacks, each with the route it takes. Agents read the same list with the MCP tool list_stacks, the CLI with deployx stacks [query], and scripts with GET /api/v1/stacks.

Deploy without GitHub

Send the files themselves. Files that run as they are go to DeployX Sites with no key; source with a package.json that needs a build goes to Vercel. A new version is another upload to the same project. Uploads hold up to 4 MB, so push bigger apps to GitHub and import the repository.

Copycurl -X POST https://deployx.verionx.org/api/v1/deploy \
  -H "Authorization: Bearer $DEPLOYX_TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "menu", "files": [{"path": "index.html", "content": "<h1>Today: jollof and plantain</h1>"}]}'

The console does the same from New project: drag a folder in, or start from a template (a static site, a React artifact, Vite + React or Next.js). Agents use the MCP tools deploy_files and deploy_template.

DeployX Sites

DeployX Sites is the built-in host. It needs no account, key or payment: files that run as they are (HTML, a build output such as dist/ or build/web, a Claude artifact) go live at <sites origin>/<project>/. Each deployment also keeps its own address, rollback is instant, and the files of the newest ten deployments are kept. Sites are served from a separate origin, so a hosted page can never read your console session.

Source that still needs a build is refused with the reason. Build it locally and upload the output, or export Build in CI for DeployX Sites: GitHub Actions builds on every push and publishes the result here. Flutter web and threaded WebAssembly builds are detected and served cross-origin isolated.

Claude artifacts

Paste an artifact in New project, or send it from an agent with deploy_artifact. DeployX compiles React artifacts at deploy time, with Tailwind, lucide icons, npm imports and the shadcn/ui components from claude-artifact-runner, and serves HTML and SVG as they are.

Copycurl -X POST https://deployx.verionx.org/api/v1/artifacts \
  -H "Authorization: Bearer $DEPLOYX_TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "menu", "code": "export default function App() { return <h1>Today: jollof</h1>; }"}'

The other way round, get_status_page returns a self-contained status page for a project. Claude Code can publish it with its Artifact tool and refresh it later.

Free subdomains

Under Domains, DeployX checks a free name on is-a.dev or rweb.site and writes the exact record for your project, with a link that opens the registry on GitHub filled in. You submit the pull request yourself; is-a.dev closes AI-generated ones. Sites projects use an is-a.dev URL record. rweb.site takes CNAME records, so it suits projects on Vercel. Open Domains has moved to open-domains.com, where you register directly.

Deploys

A deploy downloads the commit from GitHub, transfers it to the build provider with your environment variables, and tracks the build until it is live or fails. The production branch deploys to production; any other branch gets a preview with its own URL.

Rollback switches production to an earlier ready build at once, with no rebuild. Promote takes a preview to production; it rebuilds so production variables apply. When a build fails, DeployX matches the log against known causes (a missing package, a type error, a lockfile mismatch, memory, the Node.js version, the output directory) and shows the line that proves it with the fix.

Deploy on push

Each project has a GitHub webhook URL and its own secret under Settings → Deploy on git push. Every request is verified against that secret before anything is read. With a GitHub token connected, DeployX installs the hook for you. Or deploy from GitHub Actions with the workflow from Export → GitHub Actions, which waits for the build and fails the check when it fails.

Data API

Each project has a JSON document store. Collections appear on first write. Your app authenticates with a project key from the Data tab. Keep the key on your server and out of browser code.

Copycurl -X POST https://deployx.verionx.org/api/v1/data/orders \
  -H "Authorization: Bearer $DEPLOYX_PROJECT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"customer": "ada@example.com", "status": "open", "total": 42}'

curl "https://deployx.verionx.org/api/v1/data/orders?where=%7B%22status%22%3A%22open%22%7D&limit=20&order=newest" \
  -H "Authorization: Bearer $DEPLOYX_PROJECT_KEY"

# PATCH merges fields (null removes one), PUT replaces, DELETE removes
curl -X PATCH https://deployx.verionx.org/api/v1/data/orders/<id> -H "Authorization: Bearer $DEPLOYX_PROJECT_KEY" \
  -H "Content-Type: application/json" -d '{"status": "paid"}'

Responses return documents flattened with id, _created_at and _updated_at. Updates are guarded against lost writes: if the document changed since it was read, the update is refused.

Runtime monitor

A 2 KB script reports uncaught errors, failed resources, failed requests and response times from the browsers of real visitors. DeployX adds it to uploaded pages; for a repository, paste the tag from the Monitoring tab into your root layout. Reports appear under Monitoring, grouped by message, and the MCP tool get_runtime_errors returns the same view.

Copy<script src="https://deployx.verionx.org/rum.js" data-key="<your project's key>" defer></script>

Webhooks

Events: deployment.created, deployment.ready, deployment.error, deployment.canceled, deployment.promoted, uptime.down, uptime.up. JSON deliveries are signed: verify X-DeployX-Signature before trusting a payload.

Copyimport { createHmac, timingSafeEqual } from 'node:crypto';

export function verify(rawBody: string, header: string, secret: string) {
  const expected = 'sha256=' + createHmac('sha256', secret).update(rawBody).digest('hex');
  return header.length === expected.length && timingSafeEqual(Buffer.from(header), Buffer.from(expected));
}

REST API

Authenticate with a personal API token from Settings → API tokens: Authorization: Bearer dxp_…. Errors come back as { "error": { "message": … } } with a meaningful status code.

MCP server

DeployX speaks the Model Context Protocol over Streamable HTTP at https://deployx.verionx.org/api/mcp. Agents authenticate with the same API tokens and can do what the token's owner can, and no more.

Copy{
  "mcpServers": {
    "deployx": {
      "type": "http",
      "url": "https://deployx.verionx.org/api/mcp",
      "headers": {
        "Authorization": "Bearer dxp_your_token"
      }
    }
  }
}

Copyclaude mcp add --transport http deployx https://deployx.verionx.org/api/mcp --header "Authorization: Bearer dxp_your_token"

CLI

One file, no dependencies, Node.js 18 or newer. The installers put it on your PATH.

Copy# macOS and Linux
curl -fsSL https://deployx.verionx.org/install.sh | sh

# Windows (PowerShell)
irm https://deployx.verionx.org/install.ps1 | iex

Copydeployx login --token dxp_…        # saved to ~/.deployx/config.json
deployx projects                    # list projects
deployx import acme/shop            # import and deploy a repository
deployx deploy shop [--branch b] [--preview]
deployx status shop                 # current production and latest deploy
deployx logs <deployment-id>
deployx rollback <deployment-id>
deployx env ls shop | set shop KEY=value | rm shop KEY | pull shop > .env
deployx export shop docker -o ./deploy
deployx open shop

Coding agents can install it themselves: point them at /llms.txt.

Deploy anywhere

The Export tab writes the files to run a project somewhere else, derived from its detected runtime and build settings:

• Build in CI for DeployX Sites (GitHub builds it free, DeployX Sites serves it)
• GitHub Pages (Free static hosting from the repository)
• Netlify (netlify.toml for a free Netlify site)
• Dockerfile (Any container host)
• Docker Compose (A single server)
• Kubernetes (Any cluster)
• GitHub Actions (Deploy through DeployX from CI)
• systemd (A Linux VM without containers)
• Fly.io (Fly Machines)
• Render (Render Blueprint)
• Windows (PSADT) (Intune, ConfigMgr and other endpoint tools)
• Android app (TWA) (Google Play, from the site you already deployed)

The Windows export targets desktop applications published as GitHub release assets. It produces a PSAppDeployToolkit v4 deployment script (MSI or EXE, with silent install, process closing and uninstall) ready for Intune or ConfigMgr. PSAppDeployToolkit is an open-source LGPL-3.0 project by its own authors; DeployX generates the script and the module comes from the PowerShell Gallery.

The Android export wraps a site that is already live into a Trusted Web Activity for Google Play. It writes a Bubblewrap manifest, a Digital Asset Links file and a GitHub Actions workflow that builds a signed app bundle from repository secrets. The app opens full screen only when the site owns its domain and serves /.well-known/assetlinks.json, so give the project a custom domain first; on a shared DeployX Sites path, Android shows a browser bar.

Security model

Every table is protected by Postgres row-level security. Policies resolve the caller from a session or an API token, so the dashboard, REST API, CLI and MCP server are held to the same rules. There is no service-role key in the application. Provider tokens, environment values and webhook secrets are stored in Supabase Vault and readable only by the DeployX server, which authenticates to the database with its own secret. API tokens and project keys are stored as SHA-256 hashes and shown once.

Limits

• Repositories up to 100 MB compressed and 15,000 files per deploy; single files up to 50 MB.
• Documents up to 256 KB; queries return up to 500 at a time.
• Files up to 50 MB each.
• Uptime checks every 5 minutes; schedules at one-minute resolution, in UTC.
• Uploads without a repository hold up to 4 MB and 2,000 files.
• DeployX Sites: up to 10 sites per workspace and 25 MB per deployment.
• Builds on your own account follow your Vercel plan's limits.