← Blog · Guides

Deploying From Claude Code: What to Check Before an Agent Ships to Your Host

November 8, 2026

On 4 November 2026 Hostinger published "How to deploy a website from Claude Code in 8 steps". Nine days earlier it had published the same guide for OpenAI's Codex. Both describe the Hostinger Connector, which the guide says is built on MCP, the Model Context Protocol that lets a coding assistant call outside tools. Hostinger lists Claude Code as an officially supported way to deploy websites and Node.js apps to its hosting.

This is not the same story as Kodee. In June we looked at Hostinger's own assistant managing a server, which is the host's agent working on the host's machine. This is different: an agent running on your laptop, one you already use to write the code, deploys that code to someone else's platform. More hosts will offer this, so it helps to know what to ask before you say yes.

What Hostinger actually ships

From the guide itself:

  • Setup. You install a Hostinger plugin in Claude Code and sign in to your Hostinger account in a browser window that the connector opens. The guide does not mention an API token.
  • The deploy. You describe the deploy in plain language. The agent shows a deployment plan, and you approve the actions one at a time. Their test deploy was live about three minutes after the plan was approved.
  • What it deploys. Plain HTML, static framework sites such as React, Vue and Astro, and Node.js server apps. Static sites go up as ready-made files: there is no build step on the server, so what goes live is whatever your machine built.
  • The plan gate. In the guide's words, Node.js apps deploy as Web Apps, "available on the Unlimited and Cloud hosting plans". Node.js app archives are capped at 50 MB and must leave out node_modules and build folders.

The step-by-step approval is a good default. An agent that has to show its plan and wait gives you a place to catch "deploy" quietly turning into "deploy and also change the DNS".

Five questions to ask any host before an agent deploys for you

The connector protocol matters less than these. They apply to MCP, a CLI, a webhook or a script the agent writes itself.

1. What else can the agent's credential do?

An agent signed in to your hosting account holds whatever that sign-in allows. Find out whether that covers only deploys, or also billing, DNS, mailboxes and deleting sites. A credential that can only deploy one app is a much smaller thing to hand over. If you are deciding where the key itself should live, see our earlier piece on keeping API keys out of the agent. This article is about what the key opens.

2. Where does the build run?

If the platform uploads files your machine built, the live site is only as reproducible as your laptop on that afternoon. If the platform builds from the repository, the deployed thing is a commit someone can check out again. Neither is wrong, but you should know which one you have before an agent starts shipping several times a day.

3. How does the agent know the deploy worked?

"Done" from an agent means the agent thinks it is done. Ask what the platform itself reports: a status, the build log, the commit that went live. An agent that can read those can check its own work. One that cannot will tell you a failed deploy succeeded, sincerely.

4. What does a failed deploy leave serving?

This is the question hosts answer least precisely. "The old version keeps serving" can mean the old process is still running while new files already sit on disk, and that is not the same thing.

5. Which plan is it on?

Hostinger states its gate plainly, and every host has one somewhere. Check the gate before you build a workflow around the feature.

How an agent deploys to DeployBase today

To be clear first: DeployBase does not have an MCP connector or a Claude Code plugin. An agent deploys to DeployBase the way a CI job does, through git, and the parts it needs are already in the dashboard.

The plan gate. Git deployment and SSH start at Pro ($11.99/month). Starter ($5.99/month) has neither, so on Starter an agent has no deploy path other than you.

The deploy. You connect a repository and branch to an app. A push to that branch reaches a signed webhook (GitHub's HMAC-SHA256 signature, or GitLab's token), and the platform builds that commit from the repository. The agent's job ends at git push, and what goes live is a commit, not a folder on someone's laptop.

Checking the result. The app's Git settings show a Deploy Status API URL. Call it with the app's webhook secret as a Bearer token and it returns the latest deployments (up to 20) with status, branch, commit and the full build log. That is enough for an agent to wait for its own deploy and read why it failed:

# DEPLOY_STATUS_URL and DEPLOY_TOKEN come from the app's Git settings.
# Keep the token in the environment, never in the command itself.
git push origin main
sha=$(git rev-parse HEAD)

for i in $(seq 1 60); do
  status=$(curl -s -H "Authorization: Bearer $DEPLOY_TOKEN" \
    "$DEPLOY_STATUS_URL?limit=1" | jq -r '.deployments[0] | "\(.commitHash) \(.status)"')
  case "$status" in
    "$sha SUCCESS") echo "live: $sha"; exit 0 ;;
    "$sha FAILED")
      curl -s -H "Authorization: Bearer $DEPLOY_TOKEN" "$DEPLOY_STATUS_URL?limit=1" \
        | jq -r '.deployments[0].logs' | tail -n 40
      exit 1 ;;
  esac
  sleep 10
done
echo "no result for $sha after 10 minutes"; exit 1

Match on the commit, not just the newest row. Otherwise an agent that pushed a second time reads the first deploy's SUCCESS as its own.

What that token can do. The webhook secret does three things for one app: it triggers a deploy of the connected branch, reads that app's deploy logs, and restarts that app. It cannot read your environment variables or files, and it cannot touch billing, DNS or any other app. Because it can read build logs, anything your build prints ends up readable with that token. Don't echo secrets in build steps.

What a failed deploy leaves serving (question 4). The answer depends on the app type, so here it is per type:

  • Laravel (deployed from git): the new release is built in a copy of the app (Composer, the asset build and the config cache) and swapped in with a single atomic rename. If any step fails, the previous release is still the one being served, files included.
  • Node.js: the new build starts in a temporary container and has to pass a health check, plus a check that the assets the page references actually load, before it replaces the running one. A failed check leaves the old process serving. The new files are already in the app's directory, though, so the deploy log says so and tells you to redeploy or restart once the build is fixed. An agent should read that log, not just the status.

Those are the two app types we checked for this article, so they are the only two we make a claim about here.

SSH. From Pro, an agent can also work over SSH. It is an unprivileged shell with your app's files, not root on a machine: enough to run your framework's commands, not enough to reconfigure the server.

A short checklist

  • Give the agent a credential scoped to deploying one app, not your account login.
  • Prefer deploys built from a commit over uploads of local build output.
  • Make the agent confirm success from the platform's status for its own commit.
  • Find out, per app type, what a failed deploy leaves live.
  • Check the plan gate before you build the workflow.

Sources: Hostinger, "How to deploy a website from Claude Code in 8 steps", published 4 November 2026, read in full 9 November 2026; "How to deploy a website from Codex", dated 26 October 2026 in Hostinger's tutorials feed. DeployBase checks on 9 November 2026: the Deploy Status API returned 200 with a valid app token, 403 with a wrong one and 401 with none. While checking the restart hook for this article, we found it targeted the wrong container for PHP apps; that was fixed the same day.