PageMotor on Hostinger with Cursor

Hostinger have a native MCP server and Cursor is one of the supported IDEs. Connect it once through Cursor’s settings, then use Composer to provision a PageMotor VPS, set DNS, and deploy — without a browser or a separate terminal.

1Go to the Hostinger API page

Log into hPanel and click API in the left sidebar under Dev tools. The page opens with the Cursor tab already highlighted.

Extension path: if you prefer, click Install in Cursor and the Hostinger Connector extension handles the connection through a UI — no JSON editing needed. Skip to Step 7 once it’s connected. The manual path (this guide) gives you more control over which tools load in Composer.

2Select the MCP tools you need

Click Config manually. The page reveals a numbered setup flow, starting with tool selection. For PageMotor you need two:

• Domains and DNS — sets the A record that points your domain at the new server
• VPS hosting — creates and manages your servers

Tick only those two and untick the rest. The file path below the grid confirms where the config goes: ~/.cursor/mcp.json.

The page says it well: “Enable only the products you use for faster and more focused MCP responses.” Fewer tools means a cleaner Composer context window.

3Generate your API token

Scroll up to the Generate an API token section and click the button.

A modal opens with a name field and an expiration dropdown. Give it a name you will recognise (e.g. cursor-token) and set expiration to Never expires.

4Copy the token before leaving the page

After generating, the token appears once with a copy warning. Copy it now — refreshing or leaving the page hides it permanently.

5Copy the MCP JSON config

Scroll back down to the Manual Configuration section. Step 3 on the page shows the JSON Hostinger generated for the tools you selected. Use the Copy button on the right of the code block.

Add your token as an env variable in each server entry. The complete, paste-ready version for DNS + VPS:

Copy

{
  "mcpServers": {
    "hostinger-dns": {
      "command": "npx",
      "args": ["--package=hostinger-api-mcp@latest", "hostinger-dns-mcp"],
      "env": { "HOSTINGER_API_TOKEN": "YOUR-TOKEN-HERE" }
    },
    "hostinger-vps": {
      "command": "npx",
      "args": ["--package=hostinger-api-mcp@latest", "hostinger-vps-mcp"],
      "env": { "HOSTINGER_API_TOKEN": "YOUR-TOKEN-HERE" }
    }
  }
}

Replace YOUR-TOKEN-HERE with the token from Step 4. It must appear in each server entry separately.

POST /api/vps/v1/virtual-machines
{
  "item_id": "hostingercom-vps-kvm2-usd-1m",   // KVM 2, billed monthly
  "setup": {
    "template_id": 1096,               // Ubuntu 24.04 with CloudPanel
    "data_center_id": 18,             // Manchester, UK
    "hostname": "pagemotor-mysite",
    "public_key": "ssh-ed25519 ..."   // from ~/.ssh/id_ed25519.pub
  }
}

Migrating an existing site onto this VPS?

A fresh install can skip this section. If you are moving an existing PageMotor site here from another host, two things break silently on the way in. Both come from a real migration reported on the PageMotor developers forum, so this is field experience, not theory.

1. Apache protection does not follow you to nginx. PageMotor guards its sensitive directories (error logs, Skill state, and protected uploads including Brain files) with per-directory .htaccess files, which is automatic on Apache and LiteSpeed. CloudPanel serves your site with nginx, and nginx ignores .htaccess entirely. So the moment nginx starts serving a migrated site those directories are publicly readable over the web, and nothing looks broken. Current PageMotor releases probe for this themselves and raise an admin warning with the exact paths for your install. The fix is three rules. In CloudPanel open Sites → your site → Vhost, add these inside the server { } block, and save:

location ^~ /user-content/logs/              { deny all; }
location ^~ /user-content/skills/            { deny all; }
location ^~ /user-content/uploads/protected/ { deny all; }

Always edit the vhost through the CloudPanel page, not the file on disk: the panel regenerates that file, and panel edits are what survive. To confirm the rules are live, request https://yourdomain.com/user-content/logs/ in a browser. You want a 403, not a log file.

2. Zip extraction can strip the write bits. If you carry the site over as a zip and extract it on the server, directories can come out as 555 (read and execute, no write) depending on what built the zip. Ownership then looks perfect, every file belongs to the site user, but PHP cannot write anywhere, and the first symptom is usually a plugin install failing with “staging directory could not be created”. The scripted provision this guide references sets the permission bits explicitly, so a from-scratch build never hits this; a hand-carried zip is the case it cannot see. The fix is one pass in a server terminal:

cd /home/SITEUSER/htdocs/yourdomain.com
chown -R SITEUSER:www-data .
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Who looks after this server?

You do. Hostinger sell a self-managed VPS, and say so plainly on their own VPS page: “As our VPS solutions are self-managed, you will get full freedom to configure and manage the virtual server.”

Hostinger looks after the hardware, the network, DDoS filtering at the edge, and whatever backups your plan includes. Everything from Ubuntu upwards is yours: security patches, your control panel, PHP, the database, your TLS certificate, and PageMotor itself.

That is not a catch. It is the same freedom that makes a VPS fix the problems shared hosting gives PageMotor. But nobody emails you when a patch is published, and a server left alone for a year is running a year of known, catalogued, publicly indexed vulnerabilities. Budget about fifteen minutes a month.