Skip to content
← All articles

GoDaddy's hosting API: deployment built for agents

Sep 29, 2026 · DevOps · 5 min

·By Dimitri Pisarev

On September 29, 2026 GoDaddy paid PR Newswire to distribute a press release headlined "GoDaddy Launches Web App Hosting with API for AI Coding Tools." The product inside is Node.js Hosting, and GoDaddy's own announcement page says it "went generally available on August 12, 2026." The launch already happened. What the release sells is an API across the app lifecycle: create, upload source, publish, manage secrets, read build and app logs (PR Newswire).

The sentence that matters if you run agents, verbatim: "Developers and AI coding agents can also create, deploy and manage apps entirely through the GoDaddy API, without opening a dashboard." The support agent on this site gets four tools, Zod-validated results and a limit of three rounds. A hosting API built for agents changes that arithmetic. The arithmetic is blast radius: whose token, which secrets, what separates preview from production.

What does the API hand an agent?#

Authentication is a Personal Access Token, Authorization: Bearer $GODADDY_PAT, shown once, with optional expiration and revocation the auth docs call "instant across all edges." Fourteen hosting.* scopes govern the surface, from application create and delete to deployment:execute, log:read, secret write and subscription write (core concepts). The split matters more than the count: a token can carry source write without deployment:execute, so an agent can stage a build and cannot ship it.

Each app has two variants, preview and publish, with separate sources, secrets and URLs. The promotion rule, in eleven words: "Uploads land on preview. Publishing promotes the current preview to publish." Secrets are set per variant via RFC 6902 JSON Patch, up to 50 operations per request, and reads are one-way: "No endpoint returns secret values, including reads." An agent can rotate a credential it will never see. Mutations take an Idempotency-Key header and long operations return pollable job records, so a retry loop that fires twice does not deploy twice.

Apps run as persistent Node.js 22 processes, and upload is a zip up to 100 MB or a GitHub repo, auto-detected for eight frameworks or a plain npm start. Two private preview apps are free, "with no Web Hosting plan or credit card required." Publishing takes a paid plan.

A launch release, seven weeks late#

That headline works hard for a September dateline. webhosting.today went through the platform on August 21. Bhala Dalvi, "CTO, products and AI at GoDaddy" per the release, keeps the pitch plain: "Getting an app working shouldn't mean you now have to learn how to host it." GoDaddy handles the build and the infrastructure. That part I believe.

Published apps get automatic HTTPS, a web application firewall, managed MySQL and a CDN the launch page says is powered by Cloudflare, in a region fixed before the first deploy. Hosting is included with Web Hosting plans, without per-request, per-gigabyte or per-build-minute billing. Per webhosting.today's reading of the tier table: one published app on Economy, ten on Deluxe, twenty-five on Ultimate, plus two previews each. Cancel the plan entirely and everything freezes for 30 days, then apps, secrets, databases and storage are deleted.

The constraints get less ink. Egress, per webhosting.today's reading of GoDaddy's GitHub repo, is ports 80 and 443 plus GoDaddy's managed MySQL, with email via a loopback gateway on 2525. Nodemailer and external relays are out. The docs disagree about previews: the launch page says they don't expire, while the FAQ still calls the product a beta and its German edition removes preview apps after 30 days. I have not shipped an app on it, so take this as a close reading of the docs, not a review.

The workflow it would replace#

My reference point is this site. It runs Next.js 16, and a deploy is two commands over SSH: git pull, then docker compose up -d --build. Traefik terminates TLS and Cloudflare fronts the zone; a WAF rule I wrote blocks .env probes. There is no staging slot. The build replaces the live container.

GoDaddy Hosting APIMy VPS, docker compose
Who can deployanything holding the PATwhoever holds the SSH key
Deploy actionupload source, poll the jobgit pull plus docker compose up -d --build
Stagingseparate preview variant, own URL and secretsnone, the build is the release
Promotiondeployment:execute promotes the previewthe same command as every deploy
SecretsRFC 6902 patch, values never returned.env on the server, mode 600
TLS, CDN, WAFautomatic on publish, CDN on CloudflareTraefik ACME, Cloudflare zone I configure

GoDaddy also publishes an agent skill under MIT that validates apps against the deploy contract; its README names Claude Code and Cursor, tools the press release never mentions. The MCP server is read-only and domains-only, so hosting actions ride the REST API. I build agent tooling myself, a search MCP server among them, and the discipline is the same: narrow tools, validated output, dangerous verbs out of reach. GoDaddy's scopes do the narrowing. The dangerous verb is the product.

Would you hand an agent the deploy key?#

My manual flow is safe because it is boring and because it is mine. The key lives on one laptop, and the only intelligence in the loop is me. The GoDaddy model is safe because it is narrow: a scoped token and an explicit promote step between preview and production. A leaked PAT publishes from anywhere in one call, and a stolen SSH key does the same with more typing. The token revokes instantly, on paper.

So the question for anyone whose agents can reach a deploy step: is a scoped token plus a promote step enough trust to remove the human from the loop, or does the verb that promotes preview to production stay with a person? I have not answered it for mine. The release does not ask it either.