Deploy a Claude Code project to WordPress in 4 commands

You opened Claude Code. You shipped a working app in an afternoon. Now you need it live on a WordPress site by Friday.

And the wheels come off.

The problem

Claude Code is excellent at building small apps. It is silent on the question of where they go next.

The WordPress site has the customers, the content, the logged-in users, and the domain Google already trusts. The Claude Code output has none of that. It is a folder on your laptop.

So you start improvising. A Vercel project, a custom subdomain, a CORS handler, a token to call /wp-json, a way to read the current user without re-implementing auth. Maybe a Cloudflare worker in front of it. Maybe a separate login.

Why this hurts

Every shortcut you add becomes a thing you maintain.

A second host means a second bill, a second deploy pipeline, a second place to rotate secrets, a second SSL cert that expires at 2am. CORS bugs eat a Saturday. The “quick” iframe embed leaks parent-page CSS and your client notices on the demo call.

Worse: you wrote a useful tool for one site and now you cannot easily ship it to the next one. The deploy is glued to a hostname.

The Claude Code build was the easy part. Everything after was the work.

What we are building on

DesignSetGo Apps is a WordPress plugin that runs sandboxed apps inside a WP site. Apps live at /apps/{slug}, get a permissioned bridge to WordPress data, and ship via a CLI that uses Application Passwords (the same credential system WordPress already documents).

WP 7.0 anchors this. The site admin configures the Anthropic or OpenAI key once at Settings, Connectors. DesignSetGo never sees the key. Your app calls dsgo.ai.prompt and the Connector handles the call.

That is the setup. Now the receipt.

The 4-command deploy

Open the folder you want shipped. Or scaffold a new one.

1. Scaffold the project.

npx @designsetgo/cli init lead-calculator
cd lead-calculator

You get a dsgo-app.json manifest, an entry file, and enough local context for Claude Code to understand the runtime. For a multi-page app, add --astro.

2. Hand it to Claude Code.

Open the folder. Give it a specific task that names the WordPress shape:

Build a lead calculator as a DesignSetGo App.

Run as an iframe app, ask five questions, compute a recommended
service tier, and persist the visitor's last answers with
dsgo.storage.user. No external dependencies. Update dsgo-app.json
with only the permissions required for that storage call.

Claude Code edits normal front-end files. It treats the manifest as the contract: if the app needs posts, it adds the posts permission; if it does not need WordPress data, permissions stay empty.

3. Log in to the target site.

npx designsetgo apps login https://example.com

This uses WordPress Application Passwords. Use a user with the smallest role that can deploy apps. The password is revocable from the user’s profile screen. Credentials cache locally so the next deploy is one command.

For CI, skip login and set DSGO_USER and DSGO_APP_PASSWORD as env vars.

4. Deploy.

npx designsetgo apps deploy --build

The CLI runs your build, validates the manifest, zips the bundle, uploads it, and prints the installed URL:

https://example.com/apps/lead-calculator/

No Vercel. No Netlify. No CORS. No separate auth story.

What you just shipped

The app does not need to know how WordPress REST auth works. It does not ship an application password. It does not call /wp-json directly. It calls the bridge:

await dsgo.ready;
const { items } = await dsgo.posts.list({ per_page: 5 });

The parent runtime checks the manifest permission, calls WordPress, normalizes the response, and returns data to the app.

Claude Code wrote the surface. WordPress kept the data and the identity. DesignSetGo Apps kept the boundary legible. One domain. One login. One bill.

That is one app on one site. The same deploy command works against a second site with --site, and the same project ships to a third with --sites (Pro). The tool you wrote on a Wednesday becomes the tool you sell on a Friday.

How to add an AI app to WordPress

Short version of the four commands above, for anyone landing here on that exact question. To add an AI app to WordPress with DesignSetGo Apps: scaffold a project with npx @designsetgo/cli init, hand the folder to Claude Code (or Cursor, Aider, Codex) to build the app, run npx designsetgo apps login against the target site using a WordPress Application Password, then npx designsetgo apps deploy --build. The bundle lands at /apps/{slug}/ on your WordPress site, sandboxed in an iframe, with a permissioned bridge to posts, users, and (on Pro) dsgo.ai.prompt.

The app you built in Claude Code does not need to know anything about WordPress REST auth. The DSGo bridge handles the boundary; your code calls dsgo.posts.list() and the parent runtime enforces the permission.

Free vs Pro

The HTML upload path (drop a built bundle into wp-admin) is free, unlimited apps to evaluate.

CLI deploy, dsgo.ai.prompt, abilities, scheduled jobs, and multi-site deploys are Pro. There is a 14-day full-feature trial; after that you need a license.

Ship it

Install DesignSetGo Apps on your WordPress site, run npx @designsetgo/cli init, and have a Claude Code project live at a real URL on a real WordPress site before lunch. No second host. No second login. No CORS tab open in another window.

Get started in 60 seconds.