Hostinger Connector and MCP: Safe Deployment Guide

Hostinger Connector lets an AI coding assistant inside an IDE interact with Hostinger services through the Model Context Protocol, or MCP. Depending on the enabled tools and account, an assistant can retrieve hosting information and perform actions involving websites, WordPress, VPS, domains and DNS, ecommerce, email marketing, subscriptions, payments, and other supported resources.

This removes some control-panel switching, but it also places live infrastructure tools next to a probabilistic AI system. A vague request, wrong domain, exposed token, overbroad connection, or unreviewed DNS change can affect production.

A safe setup therefore needs more than successful authentication. It needs resource scoping, separate environments, secret management, backups, approval boundaries, deployment verification, rollback, audit evidence, and a clear division between conversational operations and repeatable CI/CD.

This guide explains the current Connector and remote MCP options, OAuth and API-token setup, WordPress site connections, deployment workflows, DNS safety, secrets, troubleshooting, and production governance.

Key Takeaways

• Hostinger Connector is an IDE extension that configures access to Hostinger's MCP tools; Hostinger also offers a remote MCP endpoint and manual local server options.
• Prefer OAuth where supported because it avoids copying a long-lived API token into configuration.
• Enable only the Hostinger product MCPs and WordPress sites required for the current task.
• Product toggles and site-specific MCPs reduce exposure but do not replace per-action approval and account-level access design.
• Keep production, staging, client, and personal accounts separate where practical.
• Never ask an assistant to write production secrets into source code, chat, logs, or tracked environment files.
• Preview DNS, billing, ecommerce, user, deletion, and production changes before approving them.
• Back up the current system and record exact rollback steps.
• Keep Git, tests, review, CI/CD, and release records for repeatable production deployments.
• Verify every claimed action in Hostinger, DNS, WordPress, monitoring, or the live application.

What Are Hostinger Connector and MCP?

MCP is a standard through which an AI client can discover and call tools exposed by an external server. In this case, Hostinger exposes operations related to services in an authenticated Hostinger account.

There are three related setup approaches.

Hostinger Connector extension

Hostinger's current local IDE setup guide describes an extension that uses browser-based OAuth and configures compatible IDEs. It supports environments including VS Code, Cursor, Claude Code, OpenAI Codex, JetBrains products, and others listed in the current documentation.

The extension can show enabled MCPs, tool counts, and separate compatible WordPress sites.

Remote Hostinger MCP server

Hostinger's API MCP server documentation publishes a remote endpoint at mcp.hostinger.com. Compatible clients can use browser OAuth without maintaining a local Node.js process.

Manual local MCP server

A local package can run as a process and authenticate with a Hostinger API token supplied through an environment variable. This route can suit custom environments but creates token, runtime, update, and local-security responsibilities.

Use the simplest supported route that meets organizational security and deployment requirements.

What Can the Hostinger MCP Tools Access?

Hostinger's current documentation lists product areas such as:

• Websites and hosting
• Individual compatible WordPress sites
• VPS
• Domains and DNS
• Ecommerce
• Email marketing
• Subscriptions and payments

Available operations vary by plan, rollout, account, client, and selected MCPs.

The ability to discover a tool does not mean it should be enabled permanently. Domains, payments, VPS, production websites, and ecommerce data have very different consequences.

Step 1: Classify the Intended Workflow

Define the use case before connecting the account.

Examples:

• Read hosting details during diagnosis
• Deploy a static frontend to staging
• Create a Node.js web application
• Inspect a domain's current records
• Draft a DNS change
• Manage one WordPress site's posts
• Review ecommerce products
• Monitor a VPS
• Create an email campaign draft

For each use case document:

• User
• IDE or AI client
• Hostinger account
• Required product
• Exact resource
• Read or write
• Environment
• Business owner
• Approval level
• Backup
• Verification
• Rollback
• Access expiry

“Connect Hostinger to my AI” is too broad to be an access request.

Step 2: Choose OAuth or API Token

OAuth

OAuth is the recommended starting point when the client and workflow support it.

Advantages include:

• Browser authorization
• No token copied into a local configuration file
• Revocable account connection
• Easier user attribution
• Simpler extension setup

OAuth does not make every action safe. The authenticated connection can still expose powerful tools. Review the authorization screen, active account, enabled products, and client.

API token

Manual setup may use a Hostinger API token.

Hostinger currently instructs users to:

• Generate the token in hPanel
• Name it
• Set an expiration date
• Copy it once
• Pass it as an environment variable
• Avoid writing it directly into a configuration file

Token controls:

• One token per person, device, or automation purpose
• Shortest practical expiry
• Clear label
• Password-manager or approved secret-store storage
• No source-control commit
• No chat paste
• No screenshot
• No shell-history exposure
• Immediate revocation after suspected compromise
• Rotation schedule
• Offboarding checklist

Do not share one owner token across a team.

Step 3: Protect the Local Development Environment

A secure cloud connection can be undermined by an insecure laptop.

Protect:

• Operating-system account
• Full-disk encryption
• Screen lock
• IDE extensions
• MCP configuration
• Environment variables
• shell history
• Clipboard
• Debug logs
• Crash reports
• Cloud-synchronized settings
• Source control
• Backups
• Remote support sessions

Review installed IDE extensions and remove unknown or unnecessary ones. An extension running in the development environment may have broad access to files, terminals, and credentials.

Keep client projects in separate workspaces. Do not allow an assistant operating in one repository to search unrelated directories containing other secrets.

Step 4: Enable Only Required MCPs

Hostinger's Connector supports selecting product MCPs. Current documentation notes that many IDEs have a practical tool limit and recommends enabling only what is needed.

Security also benefits.

Examples:

• A WordPress content task does not need Domains, VPS, Billing, or Ecommerce.
• A static deployment does not need payments.
• A DNS review does not need WordPress user tools.
• A staging Node.js deployment does not need production ecommerce.

Disable unused product areas after the task.

Site-specific WordPress MCPs

Current Connector versions present compatible WordPress websites individually. Enable only the intended site.

Check:

• Domain
• environment
• customer
• WordPress role
• data sensitivity
• current backup
• maintenance window

A site-specific MCP prevents accidental selection from a general list, but the connected WordPress account can still have broad capabilities.

Step 5: Set Up the Connector Safely

The exact user interface can change. Follow Hostinger's current setup guide and the selected IDE's MCP documentation.

A controlled setup sequence:

1. Update the IDE from its official source.

2. Install the official Hostinger Connector from the documented marketplace or link.

3. Confirm publisher and extension identity.

4. Open a non-sensitive test workspace.

5. Start browser OAuth.

6. Confirm the correct Hostinger account.

7. Review access.

8. Enable one required product MCP.

9. Restart the IDE if instructed.

10. Use a read-only query.

11. Confirm the response against hPanel.

12. Review connection and revocation settings.

Initial test:

List the connected Hostinger account resources without changing anything. Return each resource name, type, and environment.

Do not begin with “deploy everything” or “fix my DNS.”

Step 6: Use an Action-Risk Model

Level 1: Read-only inspection

Examples:

• List websites
• Read deployment status
• Inspect DNS records
• List WordPress posts
• Review resource configuration

Controls:

• Exact account
• No secrets in output
• Verification against hPanel

Level 2: Prepare or preview

Examples:

• Generate build plan
• Draft DNS changes
• Prepare a campaign
• Propose product edits
• Create deployment checklist

Controls:

• No mutation
• Diff or table
• Named reviewer
• Acceptance criteria

Level 3: Reversible non-production change

Examples:

• Deploy to staging
• Create a draft post
• Update a test record
• Add a temporary subdomain after review

Controls:

• Backup
• separate environment
• approval
• test
• cleanup date

Level 4: Production or high-impact change

Examples:

• Production deployment
• Root-domain DNS
• Nameservers
• Resource deletion
• Billing or subscription
• Payment settings
• Ecommerce price or inventory
• WordPress plugins, themes, users, or settings
• VPS firewall or destructive command
• Email campaign send

Controls:

• Human authorization
• exact resource and values
• recoverable backup
• maintenance window
• preview or diff
• two-person review where warranted
• post-change monitoring
• rollback trigger

Do not grant standing permission for Level 4 work.

Step 7: Use Plan–Preview–Approve–Execute–Verify

Plan

Ask the assistant to identify:

• Account
• resource
• environment
• current state
• desired state
• commands or tools
• files and records
• downtime
• security impact
• data migration
• backup
• rollback
• validation

Preview

Request structured output.

DNS example:

Deployment example:

• Repository and commit
• Build command
• runtime
• output directory
• environment variables by name only
• target website
• domain
• health check
• rollback artifact

Approve

Make approval exact:

Deploy commit abc123 to the staging resource named customer-portal-staging. Do not connect the production domain, alter DNS, create paid resources, or change production.

Execute

Perform one bounded action. Do not bundle resource creation, database reset, DNS, and production deployment into one instruction.

Verify

Check:

• Hostinger resource state
• deployment logs
• live URL
• HTTPS
• health endpoint
• critical routes
• database connectivity
• error logs
• monitoring
• DNS from independent resolvers
• WordPress admin
• analytics

Step 8: Prepare an Application for Deployment

Conversational deployment cannot fix an undefined application contract.

Record:

• Node.js or runtime version
• package manager
• lockfile
• install command
• build command
• start command
• output directory
• entry file
• port behavior
• environment variables
• database migrations
• persistent storage
• health check
• domain
• logging
• rollback

Hostinger's current Node.js deployment guide explains deployment from GitHub, upload, or Connector and notes that build output and entry configuration depend on the application.

Run local verification

Before deployment:

• Clean install from lockfile
• Type checking
• Lint
• Unit tests
• Integration tests
• Production build
• Dependency audit
• Secret scan
• License review where required
• Run production artifact locally
• Test required environment variables

Do not let the first production build discover that the project depends on an uncommitted local file.

Step 9: Manage Environment Variables and Secrets

Secrets include:

• Database URLs
• API keys
• signing secrets
• payment secrets
• OAuth credentials
• application passwords
• SMTP credentials
• private keys
• webhook secrets

Rules:

• Keep .env files out of Git.
• Commit a .env.example with names and safe placeholders only.
• Use separate test and production secrets.
• Put production secrets into approved hosting configuration.
• Never request secret values back in chat.
• Avoid printing environment variables.
• Redact logs.
• Rotate after exposure.
• Revoke unused credentials.
• Document owner and expiry.

Unsafe prompt:

Create a database and put its production password into the repository.

Safer:

List the environment variable names required for the database. Do not reveal or write secret values. Tell me where to configure them securely for the staging application.

After deployment, inspect the browser bundle and public endpoints to ensure server secrets were not exposed.

Step 10: Deploy to Staging First

A staging deployment should resemble production while remaining isolated.

Use:

• Separate Hostinger resource
• Separate domain or subdomain
• Separate database
• Synthetic or sanitized data
• Test payment credentials
• Non-production email routing
• Search-engine blocking
• Restricted access where appropriate
• Separate analytics property
• Lower-risk API keys

Test:

• Build and startup
• Core routes
• Authentication
• roles
• forms
• file uploads
• emails
• scheduled behavior
• payments
• migrations
• performance
• accessibility
• mobile
• error monitoring

Do not point a production domain to a staging resource merely to test DNS.

Step 11: Treat Git and CI/CD as the Release Record

Connector can accelerate interactive work, but repeatable production systems benefit from Git and automated pipelines.

Git provides:

• Source history
• peer review
• commit identity
• rollback reference
• branches
• tagged releases

CI provides:

• Repeatable installation
• tests
• builds
• security checks
• artifacts

CD provides:

• Environment-specific deployment
• approvals
• promotion
• health checks
• rollback

A mature pattern is:

1. AI assists locally.

2. Developer reviews the diff.

3. Tests pass.

4. Pull request is reviewed.

5. CI creates an artifact.

6. Approved workflow deploys staging.

7. Acceptance tests pass.

8. Production promotion is authorized.

Use Connector for inspection, environment setup, or controlled deployment where useful. Do not let an unrecorded chat become the only history of production.

Step 12: Manage DNS With Extreme Care

DNS errors can break websites, email, verification, and security controls.

Before a DNS change export or record:

• nameservers
• A and AAAA
• CNAME
• MX
• TXT
• CAA
• SRV
• DKIM
• SPF
• DMARC
• verification
• subdomain records
• TTL

Check the authoritative DNS provider. The domain may be registered at Hostinger while DNS is managed elsewhere.

Safe DNS prompt

Read only. Show current records for example.com and identify which support the website, email, DKIM, SPF, DMARC, and verification. Propose the minimum change needed to connect app.example.com to the staging deployment. Do not change nameservers or any record.

Approval

Approve the exact type, name, value, and TTL. Avoid replacing root nameservers when one subdomain record is sufficient.

Verify independently

Use:

• Authoritative nameserver query
• Public DNS resolvers
• HTTPS check
• email test
• SPF and DMARC inspection
• domain verification

DNS propagation is not a reason to make repeated conflicting changes.

Step 13: Handle WordPress Separately

Hostinger's WordPress MCP guide uses the Hostinger AI Plugin and WordPress Application Passwords for compatible setups.

Create:

• One application password per tool
• A descriptive label
• Lowest suitable WordPress role
• Expiration or review date
• Revocation record

Potential tool areas include posts, pages, media, users, plugins, themes, categories, tags, and settings. Connect only the required site MCP.

Draft-only content workflow

• Create draft
• Assign reviewer
• verify facts and sources
• check links
• check accessibility
• preview
• publish separately

Plugin or theme workflow

• Read-only audit
• backup
• staging
• changelog and compatibility
• one update at a time
• critical-journey tests
• production approval
• rollback

For detailed WordPress governance, see our Hostinger Agent and Kodee guide.

Step 14: Protect VPS Operations

VPS tools can have broad consequences.

Before any change identify:

• Server hostname and purpose
• Production or staging
• operating system
• running services
• containers
• storage
• firewall
• backup or snapshot
• current sessions
• dependency
• monitoring
• rollback

Prohibit unreviewed:

• recursive deletion
• disk formatting
• firewall replacement
• SSH lockout changes
• production database reset
• credential rotation without dependent updates
• broad package upgrades
• container volume deletion
• shutdown or reboot
• public port exposure

Prefer read-only diagnosis first. Review every command and resolved path. Use explicit targets rather than globs or unresolved environment variables for destructive work.

Step 15: Protect Ecommerce, Billing, and Campaign Actions

Ecommerce

Preview by SKU:

• Current and proposed price
• stock
• variation
• tax
• status
• sale schedule
• affected channels

Run a small batch and reconcile.

Billing and subscriptions

Do not create, upgrade, cancel, or renew paid services without:

• account owner approval
• exact resource
• price and billing term
• tax and renewal
• cancellation impact
• data-retention consequence

Email marketing

Separate draft from send.

Before sending:

• approved audience
• lawful basis or consent
• suppression list
• sender identity
• content and links
• unsubscribe
• schedule
• test email
• budget
• final approver

An IDE assistant should not have casual permission to send to a production list.

Step 16: Backups and Rollback

Back up before high-impact changes.

Possible rollback inputs:

• Git commit or release artifact
• Hosting backup
• Database dump
• VPS snapshot
• DNS export
• WordPress backup
• previous environment-variable set
• previous build
• product export
• campaign draft

A rollback plan states:

• Trigger
• owner
• deadline
• exact artifact
• restore steps
• data reconciliation
• verification
• stakeholder communication

Test rollback before relying on it.

Step 17: Logging and Audit Evidence

Retain:

• User
• client
• authentication method
• enabled MCPs
• target account and resource
• prompt
• proposed plan
• approval
• tool calls where available
• time
• result
• verification
• rollback
• incident

Do not log secret values or sensitive customer data.

For organizations, define retention, access, and review. Audit logs should help answer who authorized a production DNS change and what exact values changed.

Step 18: Troubleshoot Safely

Connector not visible

• Confirm official extension installation.
• Check supported IDE and version.
• Restart fully.
• Check extension logs without exposing secrets.

Authentication fails

• Confirm correct account.
• Review OAuth status.
• Check token expiry.
• Revoke and reconnect when appropriate.
• Do not paste tokens into public support channels.

Too many tools

• Disable unused product MCPs.
• Connect only required WordPress sites.
• Restart the client.
• Use a smaller task-specific configuration.

Wrong account or resource

Stop. Do not attempt a compensating change. Verify identity, revoke access if needed, and reconnect deliberately.

Action reports success but state did not change

Check hPanel and the authoritative service. Capture logs and avoid repeating a potentially non-idempotent operation such as resource purchase, email send, refund, or DNS creation.

Deployment fails

Inspect build logs, runtime, package manager, lockfile, output directory, entry point, environment-variable names, and resource limits. Reproduce locally before another production attempt.

DNS appears inconsistent

Check authoritative nameservers, TTL, cached resolvers, and exact record type. Wait for intended propagation rather than layering extra records.

30-Day Adoption Plan

Week 1: Read only

• Install official Connector.
• Use OAuth.
• Enable one product MCP.
• Inventory resources.
• Test revocation.
• Define action levels.

Week 2: Staging

• Deploy a low-risk sample.
• Test environment variables.
• Configure a staging subdomain through a reviewed change.
• Verify rollback.
• Measure logs and approval evidence.

Week 3: Repeatability

• Put source in Git.
• Add tests and CI.
• Document runtime.
• Compare interactive deployment with repeatable pipeline.
• Rehearse failure recovery.

Week 4: Controlled production

• Approve one bounded deployment.
• Monitor.
• Review incidents and time saved.
• Remove unused tools and tokens.
• Formalize allowed and prohibited actions.

Hostinger Connector Production Checklist

Access

• [ ] Official client and extension verified
• [ ] OAuth preferred
• [ ] Tokens named, expiring, and secured
• [ ] Separate access per user
• [ ] Correct Hostinger account
• [ ] Only required product MCPs
• [ ] Only intended WordPress site
• [ ] Revocation tested
• [ ] Offboarding documented

Application

• [ ] Git clean
• [ ] Commit identified
• [ ] Lockfile present
• [ ] Build documented
• [ ] Tests pass
• [ ] Secret scan passes
• [ ] Environment variables configured securely
• [ ] Database migration reviewed
• [ ] Health check defined
• [ ] Monitoring active

Change

• [ ] Exact resource and environment
• [ ] Plan reviewed
• [ ] Diff or preview reviewed
• [ ] Backup verified
• [ ] Approval recorded
• [ ] One bounded action
• [ ] Verification completed
• [ ] Rollback available
• [ ] Audit evidence retained

DNS and business systems

• [ ] DNS exported
• [ ] Email records protected
• [ ] Billing impact approved
• [ ] Ecommerce changes reconciled
• [ ] Campaign remains draft until send approval
• [ ] High-impact actions require human confirmation

For professional deployment architecture, review our custom development services and website maintenance service.

Frequently Asked Questions

What is Hostinger Connector?

Hostinger Connector is an IDE extension that configures Hostinger MCP access so compatible AI coding tools can retrieve information and perform supported Hostinger actions from the development environment.

What is Hostinger's remote MCP server?

Hostinger publishes a remote endpoint at mcp.hostinger.com. Compatible clients can connect through HTTP and browser OAuth without maintaining a local MCP process.

Is OAuth safer than an API token?

OAuth generally reduces manual secret handling and is recommended by Hostinger for external tools and multi-user use. Safety still depends on account security, tool scope, approvals, device protection, and revocation.

Which IDEs support Hostinger Connector?

Current documentation lists VS Code, Cursor, Claude Code, OpenAI Codex, JetBrains tools, Devin, and other compatible clients. Check the live setup guide because support evolves.

Can the Connector deploy Next.js or Node.js apps?

Hostinger supports Node.js and static frontend deployments under applicable plans and configurations. The project must have a compatible runtime, build, output, entry point, and resource requirements. Test the actual application.

Can the Connector change DNS?

Hostinger's Domains MCP includes DNS tools. DNS is high impact: preview exact records, back up the zone, approve specific changes, and verify from independent resolvers.

Can it manage WordPress?

Compatible Hostinger WordPress sites can appear as separate MCPs, and Hostinger documents tools for content and site areas. Use a dedicated Application Password and lowest suitable role.

Should Connector replace CI/CD?

Not necessarily. It can complement development and operations, while Git and CI/CD provide repeatable builds, review, approvals, artifacts, and release history. Production teams usually benefit from both.

Where should the Hostinger API token be stored?

Hostinger recommends passing it through an environment variable rather than writing it into the MCP config. Use an approved secret store or protected local environment, keep it out of Git and chat, set expiry, and rotate it.

Can I let an AI assistant run Hostinger autonomously?

Avoid broad unattended production authority. Use risk levels, scoped MCPs, preview, explicit approval, backups, monitoring, and rollback. Keep destructive, financial, DNS, payment, user, and bulk ecommerce actions under strong human control.

How do I verify a Connector action?

Check the authoritative Hostinger or WordPress interface, deployment logs, live service, DNS, monitoring, or business record. A chat response alone is not evidence.

Final Recommendation

Hostinger Connector is most valuable when it reduces navigation and makes approved infrastructure tools available beside the code. It is most dangerous when convenience is mistaken for permission or a chat transcript replaces an engineering release process.

Connect the minimum account surface, prefer OAuth, protect local credentials, preview high-impact changes, deploy to staging, keep production releases in Git, and verify every result.

The goal is not one-prompt production. It is a faster workflow that remains reviewable, repeatable, recoverable, and accountable.