> This is part 1 of 7 of the full documentation (pages 1–100 of 602).
> The content is paginated: fetch every part to see all of it.
> Next part: https://docs.hostinger.com/llms-full.txt/1
> Page index: https://docs.hostinger.com/llms.txt
# Hostinger Docs
Hostinger product documentation covering website creation, domains, WordPress, Node.js hosting, Agency Hosting, and the Public API and CLI, all managed through hPanel.
Welcome to Hostinger's product documentation. These pages cover everything from spinning up your first website to running Node.js apps, managing client sites on Agency Hosting, and automating with the Public API.
## Where to start
* **New to Hostinger?** Begin with [Getting Started](/getting-started/overview) — create your first website, connect a domain, and find your way around hPanel.
* **Running a WordPress site?** Jump to [WordPress](/wordpress/overview) for installation, plugins, themes, and security.
* **Deploying a Node.js app?** Head to [Node.js](/node.js/overview) for the deploy flow, build settings, and runtime logs.
* **Sending email campaigns?** [Reach](/reach/overview) covers contacts, segments, campaigns, and automated email flows.
* **Managing client sites?** Read the [Agency Hosting](/agency-hosting/overview) guide for cloning, staging, and access sharing.
* **Automating with code?** [API Reference](/api-reference/overview) covers authentication, [every endpoint](/api-reference/endpoints), and the [Hostinger CLI](/api-reference/cli), [SDKs](/api-reference/sdks) and [other tools](/api-reference/tools) for driving the same API.
## Sections at a glance
| Section | What's inside |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Getting Started](/getting-started/overview) | First-time setup: create a website, connect a domain, deploy. |
| [Websites](/websites/auto-installer) | Hosting environment — files, databases, PHP, caching, SSL, security, analytics. |
| [Domains](/domains/overview) | Registration, DNS, pointing a domain, free subdomains. |
| [Emails](/emails/overview) | Mailboxes on your domain — Webmail, device setup, DNS, forwarders, import, logs. |
| [Reach](/reach/overview) | Email marketing — contacts, segments, campaigns, automations, forms, deliverability. |
| [WordPress](/wordpress/overview) | Install WordPress, manage plugins / themes / staging, troubleshoot. |
| [Node.js](/node.js/overview) | Managed Node.js: deploy, build settings, GitHub integration, runtime logs, supported frameworks. |
| [Agency Hosting](/agency-hosting/overview) | Multi-site management for agencies — cloning, access sharing, WordPress Add-ons, Partner Program. |
| [Account](/account/overview) | Profile, security, 2FA, API tokens. |
| [Hostinger Connector](/hostinger-connector/overview) | Manage Hostinger from your code editor through an AI assistant. |
| [API Reference](/api-reference/overview) | The Public API — authentication, [endpoints](/api-reference/endpoints), [pagination](/api-reference/pagination), [errors](/api-reference/errors), and the [CLI, SDKs and integrations](/api-reference/tools). |
***
*Last updated: September 10, 2026*
# Overview
Introduction to Hostinger's managed web hosting platform, covering hosting plans, the hPanel control panel, domains, WordPress, Node.js apps, and API access.
Hostinger is a managed web hosting platform that takes care of everything between your code and your visitors — domains, servers, runtimes, databases, certificates, and the control panel that ties it all together. You bring a website, an app, or just an idea; Hostinger handles provisioning, scaling, and day-to-day operations so you don't have to maintain infrastructure yourself.
It covers the full lifecycle of a site: register or connect a domain, spin up hosting, deploy your code (or install a CMS like WordPress), and keep it running with built-in SSL, backups, caching, and monitoring.
## What you can do
* **Host websites** — Static files, PHP, or WordPress on shared hosting. Each site gets its own domain, storage, and database.
* **Build with AI or drag-and-drop** — Hostinger Horizons builds websites and web apps from a described idea; the Website Builder offers beginner-friendly drag-and-drop editing.
* **Deploy Node.js apps** — Hostinger builds from source and keeps the process running. See [Node.js Hosting](/node.js/overview).
* **Auto-deploy from Git** — Connect GitHub; every push ships. See [Git](/websites/git) for static/PHP sites, or [GitHub](/node.js/github) under Node.js for apps that run a build.
* **Manage domains** — Register, point, and configure DNS in one place. See [Domains](/domains/overview).
* **Run WordPress** — One-click install, managed updates. See [WordPress](/wordpress/overview).
## Hosting plans
Plans differ by resource limits (CPU, RAM, storage, visits/month), number of websites, and included tooling. The broad families:
* **Web Hosting** — Premium, Business, and other shared plans for personal sites through small-business workloads.
* **Cloud Hosting** — Cloud Startup, Professional, and Enterprise. More powerful than shared Web Hosting plans and built to handle higher traffic volumes.
* **Agency Hosting** — multi-site management, staging environments, and cloning. See [Agency Hosting](/agency-hosting/overview).
* **VPS Hosting** — full-root Linux VMs for custom workloads.
* **WordPress Hosting** — the above, preconfigured for WordPress.
Check [hostinger.com/web-hosting](https://www.hostinger.com/web-hosting) for the current plan matrix and limits. Feature availability in this documentation assumes a web, cloud, or agency plan unless noted.
## Control panel (hPanel)
Everything lives at [hpanel.hostinger.com](https://hpanel.hostinger.com):
* Create and configure websites
* Manage domains and DNS
* Set up databases, FTP, SSH
* Configure PHP, cache, CDN, SSL
* View resource usage and logs
## Developer access
Automate with the [Public API](/api-reference/overview) — manage websites, deploy archives, trigger Node.js builds.
## FAQ
What is Hostinger?
Hostinger is a managed web hosting platform covering the full lifecycle of a website: domain registration, hosting, deployment, SSL, backups, caching, and monitoring — all managed from the hPanel control panel.
What kinds of websites can I host on Hostinger?
Static sites, PHP applications, WordPress sites, and Node.js apps. You can also build sites with Hostinger Horizons (AI) or the drag-and-drop Website Builder.
How do I create my first website?
Add a website in hPanel, pick how to build it (WordPress, Website Builder, or upload your own files), and connect a domain. See [Creating Your First Website](/getting-started/creating-your-first-website).
Do I need to buy a domain from Hostinger?
No. You can register a new domain with Hostinger, connect a domain registered elsewhere, or start on a free `*.hostingersite.com` subdomain. See [Connecting a Domain](/getting-started/connecting-a-domain).
Which hosting plan should I choose?
Web Hosting suits personal and small-business sites, Cloud Hosting handles higher traffic, Agency Hosting adds multi-site management and cloning, and VPS gives you a full root-access Linux VM. See [hostinger.com/web-hosting](https://www.hostinger.com/web-hosting) for the current plan matrix.
Is SSL included?
Yes. Every domain and subdomain hosted on Hostinger gets a free lifetime SSL certificate with automatic renewal.
Can I deploy from GitHub?
Yes. Connect a GitHub repository and every push deploys automatically — both for static/PHP sites and for Node.js apps that run a build.
## Next steps
* [Create your first website](/getting-started/creating-your-first-website)
* [Connect a domain](/getting-started/connecting-a-domain)
***
*Last updated: July 27, 2026*
# Creating Your First Website
Step-by-step guide to creating a website on Hostinger in hPanel, choosing a platform like WordPress or Node.js, assigning a domain, and picking a datacenter.
Spin up a new website on Hostinger in under a minute.
## Requirements
* An active Hostinger hosting plan
* A domain (or use a free subdomain)
## Steps
1. Open [hpanel.hostinger.com](https://hpanel.hostinger.com) and log in.
2. Click **Websites** in the top navigation.
3. Click **Add website**, then choose to create a new website (or **Migrate Website** to bring an existing one — see [Migrate Website](/websites/migrate-website)).
4. Pick a platform:
| Platform | Best for |
| ---------------------- | ----------------------------------------------------------------------------------------------- |
| **Hostinger Horizons** | Build websites and web apps by describing your idea to AI |
| **Website Builder** | Beginner-friendly drag-and-drop editing |
| **WordPress** | Fully customizable sites — start from scratch or with AI, thousands of plugins |
| **Node.js web app** | Deploy your own code from GitHub, a file upload, or your IDE — see [Node.js](/node.js/overview) |
| **PHP/HTML website** | Upload PHP or HTML files, or start from a template |
5. Assign a domain — an existing domain, a free `*.hostingersite.com` subdomain, or a custom domain to connect later.
6. Pick a datacenter close to your audience.
7. Confirm. Provisioning takes a few seconds.
## What's included
Every website comes with:
* A `public_html` directory for your files
* At least one MySQL database (plan-dependent)
* An SSL certificate (activate in [SSL settings](/websites/ssl))
* FTP and SSH access
* Full hPanel feature access
## Next steps
* [Upload files with File Manager](/websites/file-manager)
* [Connect your domain](/getting-started/connecting-a-domain)
* [Enable SSL](/websites/ssl)
* [Install WordPress](/wordpress/installing)
***
*Last updated: July 22, 2026*
# Connecting a Domain
How to point a domain to Hostinger by updating nameservers or adding A records, use a free subdomain, and verify domain ownership through hPanel or the API.
Point your domain to Hostinger so visitors can reach your site.
> **Note:** DNS changes can take up to 24–48 hours to propagate globally, though most take effect within a few hours.
## Method 1: Update nameservers (recommended)
Delegates all DNS to Hostinger. Best for most cases.
Hostinger now assigns **unique nameservers per site** — they are not the same for every account, so don't copy values from another guide. Always pull yours from hPanel before changing anything at your registrar:
1. In hPanel, open **Websites** and select your site.
2. Next to the temporary domain (or the "Domain not connected" notice), click **Check guide**.
3. Copy the two nameserver values shown.
Then at your registrar:
1. Log in to your domain registrar.
2. Open DNS or Nameserver settings.
3. Replace the existing nameservers with the values from hPanel.
4. Save.
> If your domain is registered with Hostinger on the same account, nameservers are already configured — no action needed.
## Method 2: A record only
Keep DNS at your current registrar and only point web traffic to Hostinger.
1. In hPanel, open your website dashboard and copy your hosting IP.
2. At your registrar, add these records:
| Type | Name | Value |
| ---- | ----- | ----------------- |
| A | `@` | Your Hostinger IP |
| A | `www` | Your Hostinger IP |
## Using a free subdomain
No domain yet? Use a free `*.hostingersite.com` subdomain — assigned instantly, no DNS needed.
1. During website creation, select **Free subdomain**.
2. Hostinger generates one for you.
3. Your site is live immediately.
Replace it with a custom domain any time.
## Verifying domain ownership
If you need to prove ownership (e.g., via API), see [Verify domain ownership](/api-reference/endpoints/hosting/domains/verify-domain-ownership) in the API reference.
## After connecting
* [Enable SSL](/websites/ssl) for HTTPS
* [Configure DNS records](/domains/dns) for email, subdomains, or third-party services
***
*Last updated: July 21, 2026*
# Auto Installer
Install WordPress, WooCommerce, Joomla, and other apps in one click with Hostinger's Auto Installer in hPanel, including setup steps and troubleshooting.
One-click installer for popular web applications. Installs the app into your `public_html` (or a subdirectory), sets up the database, and hands you admin credentials — no manual unzip, no `wp-config.php` editing.
## Available apps
The installer highlights three options:
* **WordPress** — the default choice for most sites; see [Installing WordPress](/wordpress/installing)
* **WooCommerce** — installed as WordPress with the WooCommerce plugin
* **Joomla**
Below them, an **Other** option opens a searchable catalog of additional applications (CMSs, forums, e-commerce, and more). The catalog changes over time — search it in hPanel for the current lineup.
## Install an app
1. Open your website dashboard in hPanel.
2. Click **Auto Installer** (under **Website** in the sidebar).
3. Pick one of the highlighted apps, or search the catalog under **Other**.
4. Fill in the setup form:
* **Install path** — leave blank to install at the domain root, or enter a subdirectory (`/blog`, `/shop`, etc.)
* **Admin username + password** — your login for the app's admin panel
* **Admin email**
* **Site name / language** — app-specific
5. Click **Install**.
Installation usually completes in under a minute.
## What happens under the hood
* The latest stable release of the app is downloaded to the target directory.
* A MySQL database is created and credentials injected into the app's config file.
* Admin user is created with the credentials you provided.
* File permissions are set to match the app's recommendations.
## Managing installed apps
The **Installed applications** list on the same page shows every app installed through the installer, with per-app details and management actions.
For WordPress, we recommend [Automatic updates](/wordpress/security) — they catch security releases faster than manual updating.
To remove an app, delete it from the installed applications list. This deletes the app files and the database it created — back up first if you might want the data later.
## Troubleshooting
**Install failed partway** Delete the partial install directory via [File Manager](/websites/file-manager), then try again. Most failures are due to subdirectory permission issues that resolve on retry.
**"Database limit reached"** Your plan has a cap on MySQL databases. Delete an unused database or pick an install that can share an existing database.
***
*Last updated: July 22, 2026*
# Migrate Website
Move an existing website to Hostinger by submitting a migration request in hPanel with credentials or a backup, plus supported formats and next steps.
Move an existing site to Hostinger. You submit a migration request from hPanel — with credentials or a backup — and the transfer runs from there.
## Before you start
* The source site must be self-hosted on an open-source CMS or a compatible platform. **WordPress.com** and **WordPress multisite** are not supported by the automated flow — those need a manual export.
* On the source account, **disable two-factor authentication and any anti-bot verification** before submitting. The migration team can't sign in past those.
* Make sure your destination plan has enough resources (storage, databases) for the source site.
## Where to start in hPanel
Two equivalent entry points:
* **Websites** → **Add Website** → **Migrate Website**
* **Home** → dropdown under **Websites** → **Migrations**
Both lead to the same flow. Track in-flight requests under **Migrations**.
## Pick your path
| Source | Method | What you provide |
| -------------------------------------------- | ------------------------- | ----------------------------------------------------- |
| WordPress (online, self-hosted, single-site) | **WordPress admin login** | Source domain + WordPress admin username and password |
| WordPress (offline, or you'd rather upload) | **Upload backup** | Site files archive + `.sql` database export |
| cPanel / WHM | **cPanel and WHM** | cPanel login URL + admin credentials |
| Anything else (non-WordPress, non-cPanel) | **Upload backup** | Site files archive + `.sql` database export |
| Node.js application | **Node.js Application** | App source as a `.zip` archive |
The flow also asks where the site should land — the target website slot and datacenter — and runs a requirements check before submitting. After you submit, the request enters the migration queue and Hostinger's migration team handles the transfer. You'll be notified once it's ready for DNS switchover.
> **Note:** A small number of source platforms can't be migrated automatically and are rejected at submission — upload a backup instead for those.
## Supported backup formats
* **Website files:** `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.7z`, `.gz`
* **Database:** `.sql` export
For databases, the `.sql` file should be a full export — schema and data — produced by `mysqldump`, phpMyAdmin **Export → Quick → SQL**, or your CMS's built-in export tool.
## After migration completes
1. **Test the site on Hostinger before pointing DNS.** Use the temporary preview URL Hostinger assigns, or the [SkipDNS](https://skipdns.link/) tool against your hosting IP, to confirm the site loads correctly.
2. **Point your domain to Hostinger** — see [Connecting a Domain](/getting-started/connecting-a-domain).
3. Wait for DNS to propagate (usually a few hours, up to 24–48).
4. [Enable SSL](/websites/ssl) on the connected domain.
5. Some hPanel WordPress tools are **temporarily disabled during migration** and re-enable automatically once the transfer finishes — no action needed.
## Troubleshooting
**Site loads but internal links still point to the old domain** For WordPress, run a search-and-replace against the database: `wp search-replace 'old-domain.com' 'new-domain.com'`. For other apps, update the relevant value in the config file or settings table.
**Emails not migrating** Email is not part of website migration. Set up [mailboxes](/emails/mailboxes) separately on Hostinger, then use [Email Import](/emails/email-import) to copy mailbox contents from your previous provider over IMAP.
**Migration request rejected or stuck** Check that 2FA and anti-bot verification are off on the source, and that the credentials you provided still work. If the issue persists, reply on the migration request in hPanel to reach the team.
***
*Last updated: July 22, 2026*
# Git
Deploy your website from a Git repository on Hostinger using GitHub auto-deployments or SSH-based deployment, with branch setup and troubleshooting tips.
Deploy your site from a Git repository. Push to the connected branch and Hostinger pulls the latest files into your chosen directory — no manual uploads, no SSH.
> **Note:** This is the generic Git feature for any website: static HTML, PHP apps, WordPress custom code — anything that runs what's in the repo as-is. For Node.js apps that need to run a build step (install deps, run `npm run build`, start the server), use the Node.js-specific [GitHub](/node.js/github) integration instead.
## What it does
* Pulls files from your repo into a target directory on your site
* Replaces existing files in that directory on each deploy
* Does **not** run a build step — the files committed to the repo are the files served
## Two ways to connect
| | GitHub auto-deployments | SSH-based deployment (legacy) |
| ----------- | --------------------------------------- | ------------------------------------------------------------ |
| Providers | GitHub | Any Git host (GitHub, GitLab, Bitbucket, …) |
| Auth | Hostinger GitHub App | Deploy SSH key |
| Auto-deploy | On by default (webhook managed for you) | Manual webhook setup |
| Where | **Advanced** → **Git** | **Advanced** → **Git** (shown if you have an SSH key set up) |
New connections should use GitHub auto-deployments. The SSH flow remains available for non-GitHub hosts and existing setups.
## GitHub auto-deployments
### Connect a repository
1. Open your website dashboard in hPanel and go to **Advanced** → **Git**.
2. Click **Connect with GitHub** — a popup installs the Hostinger GitHub App on your account. Choose which repositories to grant access to.
3. Pick the repository to import. Use **Refresh repositories** or check your GitHub access settings if one is missing.
4. Configure the deployment:
| Setting | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------- |
| **Branch** | The branch that triggers deployments |
| **Deploy directory** | Root (`public_html`) by default, or click **Change** to deploy to a subfolder like `public_html/blog` |
5. Click **Deploy** for the initial deployment. Progress and logs stream live.
### Automatic deployments
Once connected, every push to the selected branch deploys automatically:
1. You push to the connected branch.
2. GitHub notifies Hostinger via webhook.
3. Hostinger pulls the latest code.
4. Files are replaced in the deploy directory.
No build step runs — what's in the repo is what gets served. The website dashboard shows an **Auto-deployment** chip while the connection is healthy.
### Manual deployment
Click **Redeploy** on the Git page's **Overview** tab to pull the latest code on demand. History lists it as a "Manual deployment" (no commit attached).
### Deployment history
The **Deployments** tab lists recent deployments — branch, commit, time, and status (**Deploying / Completed / Build failed**), with the live one labeled **Current**. Click a row for the full deployment log. Logs from recent deployments are retained; older ones are pruned.
### Connection status and disconnecting
The Overview tab shows the same connection states as the Node.js integration — connected, not connected, different GitHub account, or repository access missing — with a one-click fix for each. From the menu you can:
* **Disconnect from repository** — stops deployments for this site only; your GitHub account stays connected.
* **Disconnect GitHub** — removes the installation; deployments stop for **all** sites connected to that account. Already-deployed files stay in place.
## SSH-based deployment (legacy)
Works with any Git host. Shown on the **Git** page for accounts that have a deploy SSH key.
1. **Private repos:** click **Generate SSH Key**, copy it, and add it as a deploy key on your Git host (GitHub, GitLab, Bitbucket, etc.).
2. **Add the repository:** enter the repository URL (`https://...git` for public, `git@...:...git` for private), the branch, and the target directory. Leave the directory blank to deploy to `public_html` — the target directory must be empty for the first deployment.
3. **Deploy:** use the repository's actions menu — **Deploy** pulls the latest code; **View latest build output** shows the last deployment log.
4. **Auto deployment:** the **Auto Deployment** action shows a **webhook URL**. Add it as a push webhook in your Git host's repository settings, and every push triggers a deploy.
To remove a repository, use **Delete** in its actions menu.
## Branch strategy
* Deploy `main` for simple, always-live workflows.
* Use a dedicated `production` branch to batch changes and control what ships.
* For preview workflows, deploy a testing branch to a separate site on a free subdomain before merging to the live branch.
## Troubleshooting
**Deployments not triggering on push** GitHub auto-deployments: confirm you're pushing to the connected branch and the connection status is healthy (no account mismatch or missing repository access). SSH-based: verify the webhook URL is configured on your Git host.
**Files not updating after deployment** Review the deployment log for errors. If caching is enabled, [clear the cache](/websites/cache) to force fresh content.
**GitHub lost access** The Git page shows **Repository access missing** — click **Manage access** to restore the Hostinger app's repository access in GitHub, or reconnect from hPanel if the installation was removed.
**SSH deployment fails on first pull** The install directory must contain no files or folders. Clear it (or pick an empty subdirectory) and deploy again.
**My project needs a build step** This feature serves files as-is. For Node.js apps that need `npm install` and a build, see [GitHub](/node.js/github) under Node.js.
***
*Last updated: July 22, 2026*
# File Manager
Manage your website files in the browser with Hostinger's File Manager in hPanel — upload, edit, move, and delete files, extract archives, and set permissions.
Browser-based file manager — no FTP client needed.
## Open File Manager
1. Open your website dashboard.
2. Click **File Manager** in the left menu.
## Directory structure
Your website files go in `public_html` — anything there is publicly accessible.
```
/
├── public_html/ ← Your website files go here
│ ├── index.html
│ ├── index.php
│ └── ...
├── hbuilds/ ← Node.js deployments (managed — do not edit)
├── logs/ ← Access and error logs
└── ...
```
For Node.js apps, `public_html` and `hbuilds` are managed by deployments and overwritten on each deploy — see [Node.js File Structure](/node.js/file-structure).
> **Warning:** Never put sensitive files (config with credentials, backups) inside `public_html` — they'd be publicly accessible.
## Upload files
* **Drag and drop** files from your computer into the File Manager window.
* Or click **Upload** and select files.
For large uploads or full project folders, use [FTP/SFTP](/websites/ftp-ssh) — it's faster and more reliable.
## Create files and folders
* **New folder** — click **New Folder**, name it, confirm.
* **New file** — click **New File**, include the extension, confirm.
## Edit files
Click a file, then **Edit** — the built-in editor has syntax highlighting for HTML, CSS, JavaScript, PHP, and more. Click **Save**.
## Copy, move, rename
* **Copy** — select → **Copy** → navigate → **Paste**.
* **Move** — select → **Move** → navigate → confirm.
* **Rename** — right-click or use the toolbar.
## Delete files
Select → **Delete** → confirm.
> **Warning:** File Manager deletions can't be undone. Recover via [Backups](/websites/backups) if needed.
## Extract archives
1. Upload a `.zip`.
2. Right-click → **Extract**.
3. Contents extract in place.
Extraction keeps each file's modification time stored inside the archive — **Last modified** shows when the file was edited, not when it was extracted.
## File permissions
1. Right-click the file or folder.
2. Select **Permissions**.
3. Set values and confirm.
Common values:
| Value | Use for |
| ----- | ------------------------------------------------------------ |
| `644` | Files — owner read/write, others read |
| `755` | Directories and scripts — owner execute, others read/execute |
| `600` | Private files — owner read/write only |
***
*Last updated: September 9, 2026*
# FTP & SSH Access
Set up FTP, SFTP, and SSH access on Hostinger, including creating FTP accounts in hPanel, finding connection details, and using SSH key authentication.
File transfers and terminal access over FTP, SFTP, and SSH.
> **Tip:** Prefer SFTP over plain FTP — SFTP encrypts credentials and transfers.
## FTP accounts
### Create an FTP account
1. Open your website dashboard.
2. Go to **FTP Accounts** → **Create FTP Account**.
3. Enter:
* **Username** — the FTP username
* **Password** — strong password
* **Directory** — accessible directory (defaults to `public_html`)
4. Click **Create**.
### Connection details
Use these in FileZilla, Cyberduck, etc.:
| Setting | Value |
| ------------ | ------------------------------------------- |
| **Host** | Your domain or the FTP hostname from hPanel |
| **Username** | Your FTP username |
| **Password** | Your FTP password |
| **Port** | `21` (FTP) or `22` (SFTP) |
| **Protocol** | FTP or SFTP |
### Change an FTP password
1. **FTP Accounts** → find the account.
2. Click **Change Password**.
3. Enter and confirm.
### Delete an FTP account
1. **FTP Accounts** → find the account.
2. Click **Delete**.
## SSH access
Terminal access for commands, files, and databases. Available on eligible plans.
### Get your SSH details
1. Open your website dashboard.
2. Go to **SSH Access** (or check **Advanced**).
3. Note your **hostname**, **username**, and **port**.
### Connect
```bash
ssh username@yourdomain.com -p 22
```
Replace with the values from hPanel.
### SSH key authentication
More secure than passwords.
Generate a key pair locally (if you don't have one):
```bash
ssh-keygen -t ed25519 -C "your@email.com"
```
This creates `~/.ssh/id_ed25519` (private) and `~/.ssh/id_ed25519.pub` (public).
Add your public key in hPanel:
1. **SSH Access** → **Add SSH Key**.
2. Paste the contents of `id_ed25519.pub`.
3. Click **Add**.
> **Warning:** Never share your private key. Only the public key goes to Hostinger.
Connect with the key:
```bash
ssh -i ~/.ssh/id_ed25519 username@yourdomain.com -p 22
```
### Remove an SSH key
**SSH Access** → click **Delete** on the key.
## Protocol comparison
| Protocol | Port | Use for |
| -------- | ---- | ---------------------------------- |
| FTP | 21 | Legacy transfers — avoid, use SFTP |
| SFTP | 22 | Secure file transfers over SSH |
| SSH | 22 | Terminal and commands |
***
*Last updated: July 21, 2026*
# Databases
Create and manage MySQL databases in hPanel on Hostinger, including phpMyAdmin access, imports and exports, password changes, and remote connections.
MySQL databases for your websites, managed from hPanel.
## Create a database
1. Open your website dashboard.
2. Go to **Databases** → **MySQL Databases**.
3. Click **Create database**.
4. Enter a name and click **Create**.
A database user is created automatically.
## Connect from your app
| Parameter | Value |
| ------------ | ------------------------------------------------------------------------------------- |
| **Host** | `localhost` for PHP apps, `127.0.0.1` for [Node.js apps](#connect-from-a-node-js-app) |
| **Port** | `3306` |
| **Database** | Your database name |
| **Username** | Your database user |
| **Password** | Your database user's password |
Drop these in `wp-config.php` (WordPress) or `.env` (Laravel, etc.).
### Connect from a Node.js app
Set your database host to `127.0.0.1` rather than `localhost`.
PHP apps reach MySQL over a local socket, so `localhost` works for them. Node.js connects over TCP and resolves `localhost` to the IPv6 loopback address `::1`, which your database user may not be granted for — so the connection is refused:
```
Access denied for user 'u123456789_admin'@'::1'
```
`127.0.0.1` forces IPv4 and works on every account:
```
DB_HOST=127.0.0.1
DB_PORT=3306
```
Store the credentials as [environment variables](/node.js/environment-variables) rather than hardcoding them in your source.
> **Note:** This is a local connection — you don't need to enable [Remote MySQL](#remote-database-access) to connect from an app running on the same hosting account.
## phpMyAdmin
1. Go to **Databases** in hPanel.
2. Click **phpMyAdmin** next to the database.
Use it to browse tables, run SQL, and import/export data.
## Change a user's password
1. **Databases** → **MySQL Users**.
2. Click **Change Password** on the user.
3. Enter and confirm.
> **Warning:** Update the password in your app's config right after — or the app will stop connecting.
## Import a database
phpMyAdmin:
1. Open phpMyAdmin.
2. Select the database in the left sidebar.
3. Click **Import**.
4. Select your `.sql` file and click **Go**.
Large files via SSH:
```bash
mysql -u username -p database_name < dump.sql
```
## Export a database
1. Open phpMyAdmin.
2. Select the database.
3. Click **Export**.
4. Choose **Quick** and format **SQL**, then **Go**.
## Delete a database
> **Warning:** This is permanent. Export a backup first.
1. **Databases** → **MySQL Databases**.
2. Click **Delete** on the database.
3. Confirm.
## Remote database access
Databases are `localhost`-only by default. To allow remote connections:
1. **Databases** → **Remote MySQL**.
2. Enter the allowed IP and click **Add**.
The same page shows the **hostname** your client connects to — for example `srv1517.hstgr.io`. Remote clients use port `3306`.
***
*Last updated: August 24, 2026*
# Backups
Learn how Hostinger's automatic and manual website backups work in hPanel, including how to generate, restore, and download file and database snapshots.
Automatic scheduled backups plus manual snapshots. Restore to any available point.
## Automatic backups
Hostinger backs up your site on a regular schedule. Backups cover site files and databases.
Automatic backups run **weekly** by default, and **daily** on plans that include daily backups. If your plan only includes weekly backups, you can purchase the **Daily backups** add-on from hPanel — same retention behavior, run every 24 hours instead of once a week. Check your plan's details for what's included.
> **Note:** Email mailboxes are not included in website backups (the Backups page lists what's excluded) — website backups cover [hosting content](#what-backups-include), while [email](/emails/overview) is a separate service. Configure your mail client or a third-party backup tool if you need email archives.
## View available backups
1. Open your website dashboard.
2. Go to **Backups**.
You'll see a list of snapshots with timestamps.
## Create a manual backup
1. Go to **Backups**.
2. Click **Generate backup**.
The backup runs in the background and shows up in the list once done.
Limits to know:
* Manual backups can be generated **once per 24 hours**.
* On entry-level plans, generating manual backups requires upgrading to a Business or higher plan.
## Restore a backup
> **Warning:** Restoring overwrites your current files and/or database. This cannot be undone. Download the backup first if you want a before-state copy.
1. Go to **Backups**.
2. Find the backup you want.
3. Click **Restore**.
4. Pick what to restore:
* **Files only**
* **Database only**
* **Full backup**
5. Confirm.
## Download a backup
1. Go to **Backups**.
2. Click **Download** on the backup.
It's packaged as a `.zip` or `.tar.gz`.
## What backups include
* All files in `public_html` and subdirectories
* MySQL databases
Email mailboxes and server configuration are not included. Server configuration is managed by Hostinger.
## Best practices
* Create a manual backup before major updates (CMS, theme, plugin changes).
* Download a copy locally for extra safety.
* Test restores occasionally to confirm they work.
***
*Last updated: July 22, 2026*
# PHP Configuration
Change your website's PHP version, enable extensions, and adjust php.ini options like memory\_limit per site from the PHP configuration panel in hPanel.
Pick your PHP version, toggle extensions, and tune settings per website.
## Change PHP version
1. Open your website dashboard.
2. Go to **PHP** (or **Advanced** → **PHP Configuration**).
3. Pick a version.
4. Click **Save**.
Takes effect immediately.
### Supported versions
Hostinger supports every PHP version still under [active or security support from php.net](https://www.php.net/supported-versions.php). When a version reaches end of life upstream, it's retired from the selector. New versions are added on release. Use the latest stable for performance and security.
> **Warning:** Always test a new PHP version in staging first — some plugins or libraries may not be compatible.
## PHP extensions
1. Go to **PHP** → **Extensions** tab.
2. Toggle extensions.
3. Save.
Common extensions (`mysqli`, `pdo`, `curl`, `gd`, `mbstring`, `zip`) are enabled by default. Enable others as your app needs.
## PHP options (`php.ini`)
1. Go to **PHP** → **Options** tab.
2. Adjust values.
Common settings:
| Setting | What it controls |
| --------------------- | ------------------------------------------------------ |
| `memory_limit` | Max memory per script |
| `max_execution_time` | Max script runtime in seconds |
| `upload_max_filesize` | Max upload size |
| `post_max_size` | Max POST body size |
| `display_errors` | Show PHP errors in the browser (disable in production) |
| `error_reporting` | Error reporting level |
> **Note:** Values must stay within your plan's limits.
## Override via `.htaccess`
```apacheconf
php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
```
`.htaccess` overrides only work within plan limits.
***
*Last updated: July 21, 2026*
# Cron Jobs
Schedule automated tasks on Hostinger with cron jobs in hPanel, including cron syntax, common schedules, PHP script commands, and capturing output to logs.
Schedule commands or scripts to run automatically — emails, reports, cleanup, app tasks.
## Create a cron job
1. Open your website dashboard.
2. Go to **Cron Jobs**.
3. Click **Create Cron Job**.
4. Set the schedule and command.
5. Click **Save**.
## Cron syntax
Standard cron — five fields:
```
* * * * * command to run
│ │ │ │ │
│ │ │ │ └── Day of week (0–7, Sunday = 0 or 7)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)
```
### Common schedules
| Schedule | Cron expression |
| ------------------------ | --------------- |
| Every minute | `* * * * *` |
| Every 5 minutes | `*/5 * * * *` |
| Every hour | `0 * * * *` |
| Daily at midnight | `0 0 * * *` |
| Daily at 8:00 AM | `0 8 * * *` |
| Every Monday at 9:00 AM | `0 9 * * 1` |
| First day of every month | `0 0 1 * *` |
hPanel also has a visual schedule builder.
## Commands
Typically a PHP script, shell script, or system command.
### Run a PHP script
```bash
php /home/username/public_html/script.php
```
### WordPress cron
WordPress's built-in `wp-cron` runs on page visits. For reliability, disable it and use a real cron job:
1. Add to `wp-config.php`:
```
define('DISABLE_WP_CRON', true);
```
2. Create a cron job:
```bash
php /home/username/public_html/wp-cron.php
```
## Manage cron jobs
All jobs are listed in the **Cron Jobs** panel. Click to edit, or **Delete** to remove.
## Capturing output
Output is discarded by default. Redirect it to a log file for debugging:
```bash
php /home/username/public_html/script.php >> /home/username/cron.log 2>&1
```
***
*Last updated: July 21, 2026*
# Cache
Enable, disable, and purge server-side caching with Hostinger's Cache Manager in hPanel to speed up your website and keep visitors seeing fresh content.
Server-side cache stores generated HTML pages and serves them without re-running PHP or database queries. In hPanel the tool is called **Cache Manager**, under **Advanced**.
## Enable cache
1. Open your website dashboard.
2. Go to **Advanced** → **Cache Manager**.
3. Toggle **Automatic cache** on.
With automatic cache on, the cache clears itself every 30 minutes — stale content ages out without manual purging.
## Disable cache
**Cache Manager** → toggle **Automatic cache** off.
## Clear cache
After updating content or code, purge the cache so visitors see the new version.
1. Go to **Advanced** → **Cache Manager**.
2. Click **Purge all** — or purge a **specific URL** if only one page changed.
Next visit regenerates each purged page.
## When to purge
Purge after:
* Content updates
* Theme or style changes
* Code deployments
* Plugin installs or updates
* Config changes
## WordPress caching
If you use a WordPress caching plugin (LiteSpeed Cache, W3 Total Cache), it runs alongside the server-side cache. Clear both after changes.
WordPress sites on Hostinger additionally get **LiteSpeed** and **Object Cache** toggles with their own settings — see [WordPress Overview](/wordpress/overview).
## Cache exclusions
Pages that shouldn't be cached (carts, checkouts, user dashboards) are usually excluded automatically by caching plugins that understand dynamic content. If a specific page keeps serving stale content, purge its URL from Cache Manager.
***
*Last updated: July 22, 2026*
# CDN
Enable Hostinger's CDN in hPanel to serve static assets from edge locations worldwide, purge cached files, and use built-in optimization and security controls.
A CDN serves static assets from locations close to your visitors, cutting load time for distant users. Find it under **Performance** → **CDN** in your website dashboard. Available on Premium plans and higher; on some plans it's enabled automatically for new sites.
## Enable CDN
1. Open your website dashboard.
2. Go to **Performance** → **CDN**.
3. Enable it for your domain.
Static assets route through the CDN automatically — no code changes. Controls are per domain, so a site with several domains can have different settings for each.
## Disable CDN
**Performance** → **CDN** → disable for the domain.
## Purge the CDN cache
After updating assets, purge so the CDN fetches fresh copies.
1. Go to **CDN**.
2. Click **Purge cache**.
Full refresh may take a few minutes to propagate globally.
## What the CDN caches
Static files:
* Images (`.jpg`, `.png`, `.gif`, `.webp`, `.svg`)
* CSS
* JavaScript
* Fonts
* Videos and media
Dynamic content (PHP pages, form posts, API responses) is never CDN-cached — it always goes to your origin.
## Optimization settings
The CDN panel includes asset-optimization options you can toggle per domain — compression and related speed features. Pair them with [PageSpeed](/websites/pagespeed) test runs to measure the effect.
## Security controls
Beyond caching, the CDN panel includes access controls enforced at the edge:
* **IP block list** — block specific IP addresses before they reach your site.
* **Traffic blocking by country** — block visitors from selected countries, or switch to **Allowed countries** mode to permit only the countries you list.
> **Warning:** In Allowed-countries mode, visitors from every unlisted country are blocked — double-check the list includes all your real audiences (and your own location).
## Analytics
The CDN panel shows per-domain metrics: requests served by the CDN, bandwidth saved, and cache performance. Use them to confirm the CDN is actually absorbing traffic after you enable it.
## SSL
CDN-served assets are delivered over HTTPS when your site uses SSL.
***
*Last updated: July 22, 2026*
# PageSpeed
Run on-demand performance tests with Hostinger's PageSpeed tool in hPanel to measure Core Web Vitals and get prioritized recommendations for faster loading.
Integrated performance check that measures how fast your site loads for real users. Runs on demand from hPanel, reports Core Web Vitals, and surfaces concrete improvements.
## What it measures
* **Largest Contentful Paint (LCP)** — when the main content becomes visible
* **Cumulative Layout Shift (CLS)** — visual stability while the page loads
* **Interaction to Next Paint (INP)** — how snappy the page feels when clicked or typed into
* **Time to First Byte (TTFB)** — how fast the server starts responding
* **Total page weight** — HTML, JS, CSS, images, fonts
Scores are reported separately for mobile and desktop.
## Run a test
1. Open your website dashboard in hPanel.
2. Click **PageSpeed** (sometimes grouped under **Performance**).
3. Click **Run test**.
Results appear in under a minute.
## Read the results
Each metric is graded:
| Grade | Meaning |
| --------------------- | ---------------------------------------------------- |
| **Good** | Meets Google's Core Web Vitals thresholds |
| **Needs improvement** | Borderline — affects SEO under real-world conditions |
| **Poor** | Fails the threshold — high-priority to fix |
Below the metrics, PageSpeed lists actionable recommendations ordered by estimated impact — e.g., "Serve images in next-gen formats", "Reduce unused JavaScript", "Enable text compression".
## Applying fixes
Many recommendations map to other Hostinger features:
* **Cache / compression** → [Cache](/websites/cache)
* **Global asset delivery** → [CDN](/websites/cdn)
* **Image optimization** → Hostinger's auto-optimization (enable in **Performance** settings)
* **PHP version** → [PHP Configuration](/websites/php) (newer versions are faster)
Some require code changes — the report links to the specific file or resource.
## Notes
* Results vary by network conditions, time of day, and visitor geography. One test isn't a trend — look at multiple runs.
* Lighthouse scores from different tools (Google PageSpeed Insights, WebPageTest) may differ from Hostinger's because of network profiles and thresholds.
***
*Last updated: July 21, 2026*
# SSL Certificates
Install a free lifetime SSL certificate on your Hostinger domain in hPanel, force HTTPS, and troubleshoot common installation and auto-renewal issues.
Free lifetime SSL on every domain and subdomain you host with us. One click to install, auto-renewed as long as the site stays on Hostinger.
All Web, Cloud, and Agency hosting plans include lifetime SSL at no extra cost.
## Requirements
* The website is added to your hosting plan.
* The domain is pointing to Hostinger and DNS has propagated. See [Domain Pointing](/domains/pointing).
## Install SSL
1. Open **Websites** in hPanel.
2. Click **Dashboard** next to the domain or subdomain.
3. In the sidebar, go to **Security** → **SSL**.
4. Click **Install SSL**.
The certificate moves through **Installing** and lands on **Active** within a few minutes. To verify, open your site in an incognito window or clear your browser cache.
> If the **Install SSL** (or **Import SSL**) button isn't shown, a certificate is already installed on that domain. Uninstall the existing certificate first if you need to reinstall.
## Force HTTPS
Once SSL is active, redirect HTTP traffic to HTTPS.
**Option A: hPanel toggle**
In the SSL panel, enable **Force HTTPS**.
**Option B: `.htaccess`**
```apacheconf
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```
## Renewal
Hostinger renews your certificate automatically — no action needed as long as the site is hosted with us and the domain still points to Hostinger.
## Status
The SSL panel shows:
* Active / inactive per domain
* Certificate expiry date
* Any issuance or renewal errors
## Troubleshooting
**SSL failed to install** The domain probably isn't pointing to Hostinger yet, or DNS hasn't fully propagated. Run a DNS lookup against the domain and wait for propagation (up to 24–48 hours after pointing) before retrying.
**Install / Import SSL button missing** A certificate is already installed on that domain. Uninstall it first, then reinstall.
**Mixed content warnings** Some assets are still loaded over HTTP. Update URLs in your site to `https://` or protocol-relative `//`.
**Certificate not renewing** Auto-renewal needs the domain to keep pointing to Hostinger. If DNS was changed, fix it and the next renewal cycle will pick up.
***
*Last updated: July 21, 2026*
# Malware Scanner
Learn how Hostinger's Malware Scanner automatically checks website files for malicious code, how to read scan results in hPanel, and how to clean infections.
Automatic background scanning of your website files for malicious code, with reporting in hPanel. Included on Web and Cloud hosting plans.
## What it scans
* All files in `public_html` and subdirectories
* PHP, HTML, JavaScript, shell scripts, and other executable content
* Recently modified files (tracked by timestamp)
* Upload directories (a common infection vector for WordPress)
The scanner runs in the background — there's no schedule to configure and nothing to trigger manually.
## What it looks for
* Known malware signatures (backdoors, webshells, SEO-spam injectors, phishing kits)
* Obfuscated PHP (`eval(base64_decode(…))`, encoded payloads)
* Suspicious file modifications (e.g., core WordPress files changed outside an update)
* Unauthorized admin or cron entries that commonly drop when a site is compromised
## View scan results
1. Open your website dashboard in hPanel.
2. Click **Malware Scanner** in the sidebar.
The dashboard shows:
| Field | Meaning |
| ---------------------------- | ---------------------------------------------------------- |
| **Total discovered malware** | How many infected files were found in the most recent scan |
| **Actions taken** | Files the scanner removed or cleaned automatically |
| **Status** | Clean, infected, or partially cleaned |
| **Recent activity** | Detection log over time |
## If malware is detected
You have three options:
1. **Clean it yourself.** Restore the affected files manually — replace WordPress core files from a fresh download, reinstall plugins/themes from official sources, and remove any unfamiliar files in `public_html`.
2. **Restore from a clean backup** with a pre-infection timestamp. See [Backups](/websites/backups).
3. **Order a paid malware cleanup.** A one-time service where Hostinger's security team performs the cleanup for you. Offered for WordPress sites from the Malware Scanner panel in hPanel — availability and current pricing are shown there when you order.
> **Warning:** Before manually deleting a flagged file, verify it's not a legitimate plugin or theme file that was modified. Restore from [Backups](/websites/backups) if you're unsure.
## After a confirmed compromise
1. Restore the site from a clean backup (pre-infection timestamp).
2. Change all admin, FTP, SSH, and database passwords.
3. Update WordPress core, all plugins, and all themes.
4. Review [WordPress Security](/wordpress/security) and [IP Access Rules](/websites/ip-access-rules).
5. Rotate any API keys or tokens stored in `wp-config.php` or elsewhere on the server.
## Notes
* The scan database covers **files only** — it detects malicious files, not database-level infections (e.g. injected posts or options). For database cleanup, restore from a backup or clean manually.
* Scanning runs on the server; it doesn't slow down visitor-facing performance.
* Not every theme/plugin modification is malicious — the scanner uses heuristics that occasionally flag legitimate code. Review before deleting.
***
*Last updated: July 22, 2026*
# Password-Protected Directories
Require a username and password for specific website directories using hPanel's Password Protect Directories tool on Hostinger or .htaccess and .htpasswd.
Require a username and password to access specific directories. Visitors see a browser prompt before they can view the content.
Common uses:
* Development or staging sites
* Admin or internal areas
* Client preview pages
## Set up in hPanel
1. Open your website dashboard.
2. Go to **Advanced** → **Password Protect Directories**.
3. Pick or enter the **directory** to protect.
4. Set a **username** and **password**.
5. Click **Protect**.
Visitors now see an auth prompt on that directory.
## Manage protected directories
All protected directories are listed in the panel. You can:
* Add more users to a directory
* Change a user's password
* Remove protection
## Via `.htaccess`
### 1. Create `.htpasswd`
Store usernames and hashed passwords. Put it **outside** `public_html` (e.g., `/home/username/.htpasswd`).
```bash
htpasswd -c /home/username/.htpasswd yourusername
```
### 2. Add `.htaccess`
In the directory you want to protect:
```apacheconf
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user
```
Replace `/home/username/.htpasswd` with your actual path.
## Remove protection
* **In hPanel:** Go to **Advanced** → **Password Protect Directories** and remove the directory from the list.
* **Via `.htaccess`:** Remove the `AuthType`, `AuthName`, `AuthUserFile`, and `Require` lines.
***
*Last updated: July 22, 2026*
# IP Access Rules
Allow or block specific IP addresses and CIDR ranges with Hostinger's IP Manager in hPanel, or manage website access rules directly through .htaccess.
Allow or block specific IPs or ranges. In hPanel this tool is called **IP Manager**.
Common uses:
* Block abusive IPs
* Restrict access to your office or team
* Lock down development sites
## Add a rule in hPanel
1. Open your website dashboard.
2. Go to **Advanced** → **IP Manager**.
3. Use the **Allow an IP** or **Block an IP** form.
4. Enter the IP or range, plus an optional note to remind you why the rule exists.
5. Save.
## IP formats
| Format | Example | Matches |
| ---------- | ---------------- | ----------------------------- |
| Single IP | `203.0.113.5` | One IP |
| CIDR range | `203.0.113.0/24` | `203.0.113.0`–`203.0.113.255` |
## Allow vs. Block
| Rule type | Effect |
| --------- | ----------------------------------------------------- |
| **Allow** | Only listed IPs can access. Everyone else is blocked. |
| **Block** | Listed IPs are blocked. Everyone else can access. |
> **Warning:** With an **Allow** rule, only listed IPs work — include your own IP, or you'll lock yourself out.
## Edit or remove
Rules are listed in the panel. Click to edit, or **Delete** to remove.
## Via `.htaccess`
Block a specific IP:
```apacheconf
Require all granted
Require not ip 203.0.113.5
```
Allow only specific IPs (block everyone else):
```apacheconf
Require ip 203.0.113.5
Require ip 198.51.100.0/24
```
Block a range:
```apacheconf
Require all granted
Require not ip 203.0.113.0/24
```
***
*Last updated: July 22, 2026*
# Hotlink Protection
Stop other sites from embedding your images and media by enabling hotlink protection in hPanel or with .htaccess rules on your Hostinger-hosted website.
Block external sites from embedding your images and media — save bandwidth, stop leeches.
## Enable in hPanel
1. Open your website dashboard.
2. Go to **Hotlink Protection**.
3. Toggle **Enable Hotlink Protection** on.
4. (Optional) Add allowed domains.
5. Click **Save**.
External requests for protected file types return 403 Forbidden.
## Disable
**Hotlink Protection** → toggle off.
## Allow specific domains
For trusted externals (a CDN, partner site, or your own domains):
1. In Hotlink Protection, find **Allowed Domains**.
2. Add domains, one per line.
3. Save.
## Via `.htaccess`
```apacheconf
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?yourdomain\.com/ [NC]
RewriteRule \.(jpg|jpeg|png|gif|svg|webp|mp4|pdf)$ - [F,NC]
```
This blocks image and media requests from domains other than `yourdomain.com`.
Allow more domains with extra `RewriteCond` lines:
```apacheconf
RewriteCond %{HTTP_REFERER} !^https://(www\.)?anotherdomain\.com/ [NC]
```
## What it protects
Only the file types you specify — typically images, video, audio, and PDFs. HTML pages and other web content aren't affected.
***
*Last updated: July 21, 2026*
# Redirects
Create 301 and 302 URL redirects for your Hostinger website in hPanel or via .htaccess, including wildcard, domain, HTTPS, and www redirect examples.
Send visitors from one URL to another when you move content or restructure URLs.
## Create a redirect in hPanel
1. Open your website dashboard.
2. Go to **Domains** → **Redirects** in the sidebar.
3. Fill in:
* **Source URL** — URL to redirect from (e.g., `/old-page`)
* **Destination URL** — target URL
* **Redirect type** — 301 or 302
4. Click **Save**.
## Redirect types
| Type | Code | Use when |
| ------------- | ---- | ------------------------------------------------------------ |
| **Permanent** | 301 | URL has moved for good. Search engines transfer link equity. |
| **Temporary** | 302 | Short-term redirect; the original may come back. |
Use 301 for most cases — site restructures, domain migrations.
## Via `.htaccess`
### Simple redirect
```apacheconf
Redirect 301 /old-page https://yourdomain.com/new-page
```
### Wildcard redirect
Redirect all `/blog/*` to `/articles/*`:
```apacheconf
RedirectMatch 301 ^/blog/(.*)$ /articles/$1
```
### Entire domain
```apacheconf
RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain\.com$ [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]
```
### HTTP to HTTPS
```apacheconf
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```
### `www` to non-`www`
```apacheconf
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
```
## Manage redirects
Redirects created in hPanel are listed in the **Redirects** panel — click to edit, or **Delete** to remove. `.htaccess` redirects are managed by editing the file.
***
*Last updated: July 22, 2026*
# Error Pages
Customize 404, 500, and other HTTP error pages for your website using the Error Pages editor in hPanel on Hostinger or ErrorDocument rules in .htaccess.
Customize the pages visitors see on errors like 404 and 500.
## Common HTTP error codes
| Code | Error | When it happens |
| ----- | --------------------- | -------------------------------------- |
| `400` | Bad Request | Server couldn't understand the request |
| `401` | Unauthorized | Authentication required |
| `403` | Forbidden | Access denied |
| `404` | Not Found | Page or file doesn't exist |
| `500` | Internal Server Error | Server-side error |
The one you'll actually want to customize is **404**.
## Customize in hPanel
1. Open your website dashboard.
2. Go to **Website** → **Error Pages** in the sidebar.
3. Select the error code (e.g., `404`) to open its editor.
4. Edit the HTML.
5. Click **Save**.
## Customize via `.htaccess`
In `public_html/.htaccess`:
```apacheconf
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
ErrorDocument 403 /403.html
```
Create the corresponding HTML files in `public_html`.
### Example 404 page
`/public_html/404.html`:
```html
Page Not Found
Page Not Found
Sorry, the page you're looking for doesn't exist.
Go back to home
```
In `.htaccess`:
```apacheconf
ErrorDocument 404 /404.html
```
## Tips for a good 404 page
* Include site navigation or a search bar.
* Link back to the homepage.
* Keep it friendly.
* Optionally surface popular or recent content.
***
*Last updated: July 22, 2026*
# Directory Indexes
Control whether visitors see a file listing or a 403 error for folders without index files using Hostinger's Folder Index Manager in hPanel or .htaccess.
Control what visitors see when they hit a URL that maps to a directory with no `index.html` or `index.php`: a file listing, or a 403 Forbidden. In hPanel this tool is called **Folder Index Manager**.
> **Warning:** Directory listing should be disabled in most cases. Exposing your file structure can leak sensitive files, config, or backups.
## Toggle in hPanel
1. Open your website dashboard.
2. Go to **Advanced** → **Folder Index Manager**.
3. Choose:
* **Enabled** — visitors see directory contents when there's no index file.
* **Disabled** — visitors get 403 Forbidden.
4. Click **Save**.
Only enable this if you intentionally want a browsable folder (e.g., a public downloads directory).
## Per-directory via `.htaccess`
Disable listing:
```apacheconf
Options -Indexes
```
Enable listing:
```apacheconf
Options +Indexes
```
Place the `.htaccess` in the directory you want to affect.
***
*Last updated: July 22, 2026*
# Analytics
Learn how to use the Analytics panel in hPanel to review your website's traffic, bandwidth usage, access logs, and 4xx/5xx error logs on Hostinger hosting.
Server-side request and resource-usage stats for your website, plus access and error logs. Useful for spotting traffic spikes, tracking bandwidth, and pinpointing broken pages.
## Where to find it
In hPanel, open your website's dashboard and pick **Analytics** in the left sidebar (grouped under **Performance**).
The panel is split into a few tabs:
| Tab | What's there |
| ------------------ | --------------------------------------------------------------------------------------------------------- |
| **Overview** | Total bandwidth, total number of requests, top countries, IP addresses, requests, and domains |
| **Analytics** | Total HTTP/HTTPS requests, unique IP addresses, bandwidth, plus a 30-day history of RAM and CPU usage |
| **Access logs** | Per-request log: time, IP, request type (GET/POST/…), device, country, size in bytes, response time in ms |
| **Error code 4xx** | The same per-request log, filtered to 4xx responses |
| **Error code 5xx** | The same per-request log, filtered to 5xx responses |
## Time range
Use the **Filter** control to pick a window: **last hour**, **6 hours**, **24 hours**, or **7 days**. No custom date ranges.
## What the numbers actually count
* **Total requests** — every HTTP/HTTPS hit on your site, including assets, AJAX calls, and bots. Not visitors.
* **Unique IP addresses** — distinct IPs seen in the selected window. A rough proxy for visitors, but skewed by NAT, VPNs, and corporate networks.
* **Bandwidth** — total data transmitted in the window.
* **Top countries / IPs / requests / domains** — leaderboards over the same window.
* **Device** and **Country** in access/error logs are derived from User-Agent and IP, so they can differ from the real client (VPNs, spoofed user agents, etc.).
## Common questions you can answer
* **Did we get a traffic spike?** Open the **Analytics** tab and compare Total requests over the last hour vs. 24 hours.
* **What's eating bandwidth?** **Overview** → top requests and top domains.
* **Why is the site slow?** Check CPU and RAM in the **Analytics** tab, then **Access logs** for slow response times.
* **Where do my 5xx come from?** **Error code 5xx** tab — full request line, response time, and originating IP per error.
## "No activity to report yet"
That just means there were no requests (or no errors, on the error tabs) in the selected window. Switch to a wider filter (24 h or 7 d) or wait for traffic.
## Looking for visitor analytics?
This panel reports server-side request metrics — it doesn't track sessions, page views, referrers, or custom events. For deeper marketing analytics, run a dedicated tool such as [Google Analytics](https://analytics.google.com) alongside it.
## Related tools
* **Activity Log** (**Advanced** → **Activity log**) — an audit trail of actions taken on the website, as opposed to visitor traffic.
* [Monitoring](/websites/monitoring) — availability alerts that notify you when the site goes down.
***
*Last updated: July 22, 2026*
# Monitoring
Set up availability alerts in hPanel's Monitoring tool to get notified when your Hostinger-hosted website goes down or an alert condition is triggered.
Watch your websites' availability and get notified when something goes wrong — without polling the site yourself. Find it under **Websites** → **Monitoring** in hPanel.
## Alerts
Create alerts that check your site on a schedule and notify you when a condition trips:
1. Open **Monitoring** and create an alert.
2. Configure it:
* **Name** — what this alert watches
* **Type and threshold** — the condition that triggers it
* **Check interval** — how often the check runs
* **Notification channels** — where the alert is delivered
3. Save.
You can create up to **10 alerts**.
## When to use it
* Know a client site went down before the client does
* Catch outages after deploys, DNS changes, or SSL renewals
* Watch a site you've just migrated while DNS propagates
## Related
* [Analytics](/websites/analytics) — traffic and error-rate history for diagnosing what an alert caught
* [Backups](/websites/backups) — recover quickly when an alert turns out to be real
***
*Last updated: July 22, 2026*
# Domains Overview
Overview of domain management in hPanel, covering registration, DNS configuration, pointing, transfers, domain types, and status meanings at Hostinger.
Register, point, and manage domains and DNS from hPanel.
## Domain management
The **Domains** section of hPanel is organized into **Domain portfolio** (all your domains), **Get a new domain**, **Transfers**, and **Contact profiles** (the WHOIS contact details used for registrations). From there you can:
* Register new domains — one at a time or in bulk
* Renew existing ones
* Configure DNS, with snapshots you can restore
* Point domains to hosting
* Transfer in or out, with a transfer lock to prevent unauthorized moves
* Manage WHOIS privacy protection
## Domain types
| Type | Description |
| ------------------ | ------------------------------------------------------ |
| **Custom domain** | A domain you've registered or transferred in |
| **Subdomain** | Prefix under your domain (e.g., `blog.yourdomain.com`) |
| **Free subdomain** | Hostinger-provided (`*.hostingersite.com`) |
| **Parked domain** | Points to your site without a separate website |
## Domain status
| Status | Meaning |
| ----------------- | ------------------------------------ |
| **Active** | Registered and in use |
| **Expiring soon** | Renew soon or lose it |
| **Expired** | Renew ASAP to recover |
| **Pending** | Registration or transfer in progress |
## Related guides
* [Registering a Domain](/domains/registering)
* [DNS Management](/domains/dns)
* [Domain Pointing](/domains/pointing)
* [Free Subdomains](/domains/subdomains)
***
*Last updated: July 22, 2026*
# Registering a Domain
Search and register domains in hPanel, enable WHOIS privacy protection and auto-renewal, manage transfer locks, and transfer domains in to Hostinger.
Search and register domains directly in hPanel.
## Search
1. Go to **Domains** in hPanel.
2. Click **Register a domain** or use the search bar.
3. Enter the name you want (e.g., `mybusiness`).
4. Browse available TLDs and prices.
5. Select the domain.
## Register
1. Add to cart.
2. Pick a registration period (1 year, 2 years, etc.).
3. Optionally enable **Privacy protection** (hides your personal info from public WHOIS — recommended).
4. Complete purchase.
The domain appears in your hPanel account immediately. Registering several domains at once? The domain checker supports **bulk registration**.
Registration contact details are managed as **Contact profiles** under **Domains** — create one per person or organization and reuse it across registrations.
## Auto-renewal
Domains auto-renew by default using your payment method on file. Disable it in domain settings if you prefer manual renewal.
> **Warning:** If a domain expires and isn't renewed, it enters a grace period, then becomes available for anyone to register.
## Connect to your hosting
1. Go to **Websites** → your site.
2. Open **Domains** → **Add domain**.
3. Select the domain from your account.
DNS is configured automatically since the domain is registered with Hostinger.
## Privacy protection (WHOIS)
Replaces your name, email, address, and phone in public WHOIS with proxy info — protects you from spam.
1. **Domains** in hPanel.
2. Click the domain.
3. Toggle **Privacy protection**.
## Transfer lock
Each domain has a **Transfer lock** toggle that prevents unauthorized transfers away from Hostinger. Keep it on unless you're actively transferring out.
> **Note:** ICANN rules impose a 60-day transfer lock after registration or an ownership change — during that window the domain can't be transferred regardless of the toggle. For `.uk` domains, transfers work via the **IPS tag** instead; the transfer lock must be off to change it.
## Transfer a domain in
1. Unlock the domain at your current registrar.
2. Get the **EPP/authorization code**.
3. In hPanel, go to **Domains** → **Transfers**.
4. Enter the domain name and EPP code.
5. Complete the transfer.
Transfers typically take **5–7 days**.
***
*Last updated: July 22, 2026*
# Domain Pointing
Point a domain to Hostinger by updating nameservers at your registrar or adding A records, then verify pointing status and DNS propagation in hPanel.
Connect your domain to Hostinger so visitors reach your site.
> **Note:** DNS changes can take up to 24–48 hours to propagate globally, though most take effect within a few hours.
## Option 1: Update nameservers (recommended)
Delegates all DNS to Hostinger.
Hostinger now assigns **unique nameservers per site** — they are not the same for every account, so don't copy values from another guide. Always pull yours from hPanel before changing anything at your registrar:
1. In hPanel, open **Websites** and select your site.
2. Next to the temporary domain (or the "Domain not connected" notice), click **Check guide**.
3. Copy the two nameserver values shown.
Then at your registrar:
1. Log in to your domain registrar.
2. Open DNS or Nameserver settings.
3. Replace the existing nameservers with the values from hPanel.
4. Save.
> If your domain is registered with Hostinger on the same account, nameservers are already configured — no action needed.
## Option 2: A record only
Keep DNS at your registrar; only web traffic points to Hostinger.
1. In hPanel, open your website dashboard and copy your hosting IP.
2. At your registrar, add these records:
| Type | Name | Value |
| ---- | ----- | ----------------- |
| A | `@` | Your Hostinger IP |
| A | `www` | Your Hostinger IP |
3. Wait for DNS to propagate (up to 48 hours).
## Verify pointing
```bash
nslookup yourdomain.com
# or
dig yourdomain.com A
```
The IP should match your Hostinger server.
The **Domains** panel in hPanel shows pointing status — green means correctly pointed.
## Multiple domains
One hosting account can serve many domains:
* **Primary** — main domain for the website
* **Addon** — a separate website
* **Parked** — redirects to the primary
***
*Last updated: July 21, 2026*
# DNS Management
Manage DNS records on Hostinger nameservers from hPanel — add or edit A, CNAME, MX, and TXT records, restore DNS snapshots, and handle propagation.
DNS records route your domain's traffic to websites, email, and third-party services.
> **Note:** DNS management in hPanel is only available when your domain uses Hostinger's nameservers. If DNS lives at another provider, manage it there.
## Open DNS settings
1. Go to **Domains** in hPanel.
2. Click your domain.
3. Click **DNS / Nameservers**.
The **DNS Zone Editor** is also available from a website's dashboard sidebar, so you can edit records without leaving the site view.
## Record types
| Type | Purpose | Example |
| --------- | ----------------------------------- | -------------------------------------- |
| **A** | Points to an IPv4 address | `@ → 185.0.0.1` |
| **AAAA** | Points to an IPv6 address | `@ → 2001:db8::1` |
| **CNAME** | Alias to another domain | `www → yourdomain.com` |
| **MX** | Mail server for the domain | `@ → mail.hostinger.com (priority 10)` |
| **TXT** | Free-text (verification, SPF, DKIM) | `@ → "v=spf1 include:... ~all"` |
| **NS** | Authoritative nameservers | `@ → ns1.dns-parking.com` |
| **SRV** | Service locator records | App/protocol-specific |
| **CAA** | Allowed certificate authorities | `@ → 0 issue "letsencrypt.org"` |
## Add a record
1. Click **Add record**.
2. Select the type.
3. Fill in:
* **Name/Host** — `@` for root, `www` for `www.yourdomain.com`, or a subdomain
* **Value/Points to** — IP, domain, or text value
* **TTL** — cache lifetime in seconds; default is fine
* **Priority** — required for MX and SRV; lower = higher priority
4. Click **Save**.
## Edit or delete
Find the record → click **Edit** or **Delete** → confirm.
## DNS snapshots
Hostinger keeps snapshots of your DNS zone, so a bad edit isn't fatal:
1. Open your domain's DNS page and find **DNS snapshots** (also labeled **Restore DNS Snapshot**).
2. Pick a snapshot from before the change.
3. Restore — the zone reverts to that state.
> **Tip:** Making a risky change (switching email providers, re-pointing a live site)? Note the current snapshot time first, so you know exactly what to restore to.
## Propagation
DNS changes can take up to **24–48 hours** to propagate globally — often sooner. Check status at [dnschecker.org](https://dnschecker.org) or [whatsmydns.net](https://www.whatsmydns.net).
## Common setups
> Using Hostinger Email? Don't add these records by hand — the [Email Domain Settings](/emails/domain-settings) page sets up MX, SPF, DKIM, and DMARC for you.
### Point `www` to root
```
CNAME www yourdomain.com
```
### Google Workspace email
```
MX @ ASPMX.L.GOOGLE.COM (priority 1)
MX @ ALT1.ASPMX.L.GOOGLE.COM (priority 5)
MX @ ALT2.ASPMX.L.GOOGLE.COM (priority 5)
...
```
### Domain verification (TXT)
```
TXT @ google-site-verification=xxxxxxxxxxxx
```
### SPF
```
TXT @ v=spf1 include:_spf.hostinger.com ~all
```
***
*Last updated: July 22, 2026*
# Free Subdomains
Get a free hostingersite.com subdomain from Hostinger, upgrade to a custom domain later, and create custom subdomains under your own domain in hPanel.
Publish instantly on a free `*.hostingersite.com` URL — no domain purchase required.
## What you get
```
yourname.hostingersite.com
```
* Available immediately, no registration
* Permanent as long as your plan is active
* DNS pre-configured
* SSL supported — enable it like on any domain (see [SSL Certificates](/websites/ssl))
## Get one
During website creation:
1. In hPanel, go to **Websites** → **Add website**.
2. When asked for a domain, pick **Free subdomain**.
3. Hostinger generates a unique one.
4. Your site is live.
You can also generate a free subdomain via the [API](/api-reference/endpoints/hosting/domains/generate-a-free-subdomain).
## Upgrade to a custom domain later
1. Register or transfer your domain to Hostinger, or point an existing one.
2. Go to **Websites** → your site → **Domains**.
3. Click **Add domain**, enter the custom domain.
4. Set it as primary.
The free subdomain can stay as a secondary or be removed.
## Custom subdomains under your domain
Create things like `blog.yourdomain.com` or `app.yourdomain.com`:
1. Go to **Websites** → your site → **Domains**.
2. Click **Add domain** or **Create subdomain**.
3. Enter the prefix (e.g., `blog`).
> **Note:** For subdomains to resolve, your domain's DNS must be managed by Hostinger, or you must add the DNS record manually at your registrar. See [DNS Management](/domains/dns).
***
*Last updated: July 22, 2026*
# Email Overview
Overview of Hostinger email products and plans, the Emails section of hPanel, and the getting started path from mailbox creation to DNS and device setup.
Professional email on your own domain, managed from the **Emails** section of hPanel. Create mailboxes, read mail in Webmail or any mail app, and keep deliverability healthy with guided DNS setup.
## Email products
| Product | What it is | Managed from |
| -------------------- | --------------------------------------------------------------------------- | -------------------------------------------------- |
| **Hostinger Email** | Hostinger's own email service — the default choice, fully managed in hPanel | hPanel + Webmail |
| **Titan Email** | Partner email suite with its own apps and productivity tools | hPanel (billing, accounts) + Titan's own interface |
| **Google Workspace** | Gmail, Meet, Drive and the Google suite on your domain | hPanel (billing, setup) + Google Admin console |
This documentation covers **Hostinger Email**. Titan and Google Workspace are set up through hPanel but managed day-to-day in their own consoles.
> **Note:** Looking to send newsletters or campaigns? That's [Hostinger Reach](/reach/overview) — an email *marketing* product, separate from mailbox hosting.
## Hostinger Email plans
* **Free Business Email** — included with eligible hosting plans. A set number of mailboxes per domain (depends on your hosting plan), with essential features: basic spam protection, one forwarding rule, and one alias per mailbox.
* **Free trial** — try a paid plan for **30 days** with **1 mailbox**, no charge.
* **Paid plans — Pro, Standard, Premium** — priced per mailbox, with no cap on how many mailboxes you can add to a domain. Paid plans add larger mailbox storage (up to 50 GB per mailbox depending on the tier, expandable with add-on storage), more forwarders and aliases, advanced spam/malware/phishing protection, AI mail tools, no Hostinger branding in Webmail, and [Agentic Mail](/emails/agentic-mail).
Exact limits per plan — storage, daily sending, message size, attachment size, recipients per message, alias and forwarder quotas — are shown in hPanel under **Mailboxes** → **View limits**.
## The Emails list
**Emails** in the top navigation lists every email plan on your account with its domain, plan, mailbox count, expiry date, and status (for example **Expiring soon**, **Setup not finished**, or **Domain suspended** — each with a shortcut to fix it). Plans shared with you by other accounts appear in a separate tab.
## Getting started
A new email plan shows a **getting started** checklist: connect your domain, send your first email from Webmail, set up apps and devices, and import your old emails. The typical path:
1. [Create a mailbox](/emails/mailboxes)
2. [Connect your domain's DNS](/emails/domain-settings) — MX, SPF, DKIM, DMARC
3. [Set up your devices](/emails/setup-devices) — or just use Webmail
4. [Import existing email](/emails/email-import) from your previous provider
## Related pages
* [Mailboxes](/emails/mailboxes) — create, manage, and grow mailboxes
* [Forwarders, Aliases & Auto-Replies](/emails/forwarders-aliases)
* [Email Logs](/emails/email-logs) — delivery, access, and audit logs
* [Agentic Mail](/emails/agentic-mail) — email API, webhooks, and MCP server for AI agents
***
*Last updated: August 21, 2026*
# Mailboxes
Create and manage Hostinger Email mailboxes in hPanel, including passwords, mailbox seats, storage quotas, app passwords, and access to Webmail.
Create and manage email accounts under **Emails** → your domain → **Mailboxes**. The header shows your plan, expiry date, remaining mailbox seats, and a **View limits** link with the authoritative quotas for your plan.
## Create a mailbox
1. Open **Mailboxes** and click to create a mailbox.
2. Choose the address — up to 50 characters before the `@`, using letters, numbers, dots, dashes, and underscores.
3. Set a password or generate one.
4. Create — then **Open inbox** to jump straight into Webmail.
Password requirements: 8–50 characters with at least one uppercase letter, one lowercase letter, one number, and one symbol; Latin characters only, no spaces. Passwords found in known breach databases are rejected.
## Mailbox seats
Paid plans are priced per mailbox:
* **Buy more mailboxes** from the Mailboxes page whenever you need them — there's no per-domain cap on paid plans.
* **Remove mailboxes** you no longer pay for (you can't go below the number currently in use).
* Free plans include a set number of mailboxes based on your hosting plan; trials include one. To add more, upgrade to a paid plan first.
## Storage
Each mailbox has a storage quota set by your plan. The Mailboxes table shows a per-mailbox usage bar that turns yellow at 80% and red at 90%.
On paid plans you can buy **extra mailbox storage** as an add-on and allocate it to one or more mailboxes as needed, up to **100 GB per mailbox**. Add-on storage is pro-rated to your plan's renewal date and non-refundable.
## Managing a mailbox
Each row in the Mailboxes table offers:
* **Webmail** — open the inbox
* **Change password**
* **App passwords** — see below
* **Create alias / forwarder / catch-all / automatic reply** — see [Forwarders, Aliases & Auto-Replies](/emails/forwarders-aliases)
* **Disable 2FA** — turn off two-factor authentication for a mailbox (2FA itself is enabled in Webmail)
* **Delete** — permanently removes the mailbox **and its email data**
Mailbox status shows **Active** or **Suspended**, with tooltips distinguishing whether access, receiving, or sending is suspended.
## App passwords
App passwords let third-party apps connect to a mailbox without its real password:
1. Open **App passwords** for the mailbox.
2. Name the password and create it.
3. Copy it immediately — it's shown only once.
Each app password grants full mailbox access and can be revoked individually at any time. There's a per-mailbox limit on how many you can have.
## Webmail
Webmail lives at [mail.hostinger.com](https://mail.hostinger.com) — or one click from the Mailboxes table, with automatic sign-in. Message filters, signatures, and mailbox-level 2FA are configured inside Webmail.
## Related
* [Setting Up Apps & Devices](/emails/setup-devices) — IMAP/SMTP settings for mail clients
* [Email Import](/emails/email-import) — bring mail over from your previous provider
***
*Last updated: July 22, 2026*
# Setting Up Apps & Devices
IMAP, SMTP, and POP3 server settings for Hostinger Email, guided setup for Gmail, Outlook, and Apple Mail, plus autoconfig DNS records and fixes.
Use your Hostinger Email mailbox in Gmail, Outlook, Apple Mail, or any IMAP client. hPanel's **Connect apps & devices** page (under your email domain) has guided tabs per app plus the raw server settings.
## Server settings
| Protocol | Host | Port | Security |
| ------------------------------------ | -------------------- | ----- | -------- |
| **IMAP** (incoming) | `imap.hostinger.com` | `993` | TLS/SSL |
| **SMTP** (outgoing) | `smtp.hostinger.com` | `465` | TLS/SSL |
| **POP3** (incoming, not recommended) | `pop.hostinger.com` | `995` | TLS/SSL |
Username is the full email address; password is the mailbox password — or an [app password](/emails/mailboxes#app-passwords) if the mailbox uses 2FA or the app doesn't support your regular login.
> **Tip:** Prefer IMAP over POP3 — IMAP keeps mail in sync across all devices; POP3 downloads and typically removes it from the server.
## Guided setup per app
The **Connect apps & devices** page walks through Gmail, Outlook, and Apple Mail on mobile step by step. For Apple devices it also offers a downloadable configuration profile (via QR code or link) that fills in all settings automatically.
## Automatic setup (autoconfig)
Enable **automatic email app setup** so that mail clients discover the right settings from just your address. This adds two DNS records:
| Type | Name | Target |
| ----- | -------------- | --------------------------------- |
| CNAME | `autodiscover` | `autodiscover.mail.hostinger.com` |
| CNAME | `autoconfig` | `autoconfig.mail.hostinger.com` |
If your DNS is hosted at Hostinger, the page can add them for you; otherwise create the records at your DNS provider. The page shows a status check for both.
> **Note:** The `webmail` subdomain is reserved on email-enabled domains and can't be used for your own records.
## Troubleshooting
**Client rejects the login** Confirm the full email address is the username, and re-enter the password. If the mailbox has 2FA enabled, use an app password instead of the mailbox password.
**Can receive but not send (or vice versa)** Check the SMTP/IMAP hosts and ports against the table above, and confirm SSL/TLS is on. If sending fails from a correct setup, check your domain's [DNS records](/emails/domain-settings) and the [Email Logs](/emails/email-logs).
***
*Last updated: July 22, 2026*
# Email Domain Settings
Check and fix the MX, SPF, DKIM, and DMARC records that make Hostinger email work, verify external domains, and generate custom DKIM keys in hPanel.
Four DNS records make your domain's email work and keep it out of spam folders. hPanel's **Domain settings** page (under your email domain) checks each one, shows what it found vs what it expects, and fixes them automatically when your DNS is hosted at Hostinger.
## The four records
| Record | What it does | Symptom when missing |
| --------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------- |
| **MX** | Routes incoming mail to your mailbox (`mx1.hostinger.com`, `mx2.hostinger.com`) | Your mailbox doesn't receive emails |
| **SPF** | Stops others from sending fake emails from your domain (`v=spf1 include:_spf.mail.hostinger.com ~all`) | Your emails are easier to spoof and more likely to be flagged |
| **DKIM** | Cryptographically signs your outgoing mail | Emails more likely to land in spam |
| **DMARC** | Tells receivers how to treat mail that fails SPF/DKIM | No policy for handling spoofed mail |
## Checking and fixing records
Open **Domain settings** under your email domain. Each record shows a status — connected, missing, or incorrect (conflicting or pointing to another provider) — with a side-by-side view of the **detected records** and the **Hostinger records** they should match.
* **DNS at Hostinger:** the page can apply the correct records for you.
* **DNS elsewhere:** copy each Hostinger record into your DNS provider, then click **Check status**.
DNS changes can take up to about 12 hours to propagate, though most apply much sooner.
## Custom DKIM
The **Custom DKIM** page lets you generate your own DKIM key for the domain:
1. Click **Generate** — hPanel creates the key and shows the DNS record to add.
2. Add the record (automatic if DNS is at Hostinger).
3. Verification can take up to 6 hours; the record shows **Unverified → Verifying → Verified** (or **Verification failed** — check the record value and retry).
## Domain verification (external domains)
Adding an email plan to a domain that isn't managed at Hostinger requires proving ownership: hPanel gives you a **TXT record** to add at your DNS provider, then verifies it. Changes usually take 5–15 minutes to become visible, rarely up to 24 hours.
## Domain-level warnings
The email pages surface domain problems that affect mail: domain expiring or expired, suspended, registration still in progress, or **pending owner verification** — sending and receiving pause until the domain owner's details are verified. Each banner links to the fix.
## Related
* [DNS Management](/domains/dns) — editing records on Hostinger nameservers
* [Setting Up Apps & Devices](/emails/setup-devices) — the autoconfig CNAME records
***
*Last updated: July 22, 2026*
# Forwarders, Aliases & Auto-Replies
Set up email forwarders, aliases, catch-all addresses, and automatic replies for your domain in hPanel to route Hostinger mail without extra mailboxes.
Route and shape your domain's mail without extra mailboxes. All four tools live in the sidebar under your email domain, and can also be created from a mailbox's row actions on the [Mailboxes](/emails/mailboxes) page.
How many forwarders and aliases you get depends on your plan — free plans include one of each; paid plans include more. See **Mailboxes** → **View limits** for your numbers.
## Forwarders
Redirect incoming mail from one address to another — including addresses on other domains.
1. Open **Forwarders** under your email domain.
2. Pick the source mailbox and the destination address.
3. Save.
A forwarder requires an active mailbox to forward from. Editing a forwarder's source mailbox affects all forwarders created for that mailbox.
## Aliases
An alias is a secondary address for an existing mailbox — you can send and receive as the alias, and everything lands in the primary inbox. Aliases share the mailbox's storage.
1. Open **Email Alias** under your email domain.
2. Pick the mailbox and the alias address.
3. Save.
Use aliases for role addresses (`billing@`, `support@`) that one person handles, without paying for extra mailboxes.
## Catch-all
A catch-all receives mail sent to **any** address on your domain that doesn't exist — typos, guessed addresses, retired mailboxes.
1. Open **Catch-all email** under your email domain.
2. Choose the existing mailbox that should receive stray mail.
3. Save.
> **Tip:** Catch-alls collect a lot of spam by nature. Point one at a dedicated mailbox you review occasionally, not your primary inbox.
## Automatic replies
Out-of-office and similar autoresponders:
1. Open **Automatic Reply** under your email domain.
2. Pick the mailbox, write a subject and body — plain text or HTML with a preview.
3. Start immediately or on a start date; end on a date or **Never end**.
4. Save.
Each sender receives the automatic reply once after they email you, not on every message.
## Related
* [Mailboxes](/emails/mailboxes) — plan limits and mailbox management
* [Email Logs](/emails/email-logs) — see forwarder and reply activity in the audit log
***
*Last updated: July 22, 2026*
# Email Import
Import mail from a previous provider into a Hostinger mailbox over IMAP using hPanel's Email Import tool, with progress tracking, retries, and tips.
Bring your mail history over from a previous provider. hPanel connects to your old mailbox over IMAP and copies its contents into your Hostinger mailbox — no desktop client juggling.
## What you need
* Your old mailbox's **email address and password**
* Its **IMAP server** name — the wizard suggests it for popular providers (Gmail, Titan, GoDaddy, OVH, Zoho, Namecheap, IONOS, and many more); for others, find it in your provider's help pages
> **Note:** Providers like Gmail may require an app-specific password for IMAP access instead of your regular login. Check your old provider's security settings if the connection fails.
## Run an import
1. Open **Email Import** under your email domain and add a new import request.
2. **Import from** — the old address, password, and IMAP server.
3. **Import to** — the destination Hostinger mailbox.
4. Review the summary and start.
## Track progress
The requests table shows each import with its status — **Scheduled**, **Importing** (with progress and an ETA), **Completed**, **Failed**, or **Cancelled** — and refreshes automatically. You can cancel a running import or retry a failed one.
Import time depends on how much data the old mailbox holds; large mailboxes can take a while.
## Tips
* Make sure the destination mailbox has enough [storage](/emails/mailboxes#storage) for the incoming data.
* Keep the old mailbox active until the import completes and you've confirmed everything arrived.
* Migrating a whole team? Run one import per mailbox — they can run in parallel.
## Related
* [Mailboxes](/emails/mailboxes) — create the destination mailbox first
* [Migrate Website](/websites/migrate-website) — website migration is separate; it never includes email
***
*Last updated: July 22, 2026*
# Email Logs
Use Hostinger's Email Logs page to review message delivery statuses, sign-in attempts per protocol, and an audit trail of mailbox setting changes.
Answer "did it send?", "who logged in?", and "who changed that?" from the **Email Logs** page under your email domain. Three tabs, all filterable by mailbox and date range, with pagination.
## Delivery
Every message your domain sent or received, with sender, recipient, time, and status:
| Status | Meaning |
| ---------------------- | ---------------------------------------------------------- |
| **Delivered** | Accepted by the receiving server |
| **Sent** | Handed off for delivery |
| **Pending / Deferred** | Queued — the receiving server asked to retry later |
| **Soft Reject** | Temporarily refused; delivery will be retried |
| **Bounced / Failed** | Permanently refused — check the detail view for the reason |
Click an entry for the full detail. This is the first place to look when someone says "your email never arrived."
## Access
Sign-in attempts per protocol (Webmail, IMAP, SMTP, POP3) with the result — successful, failed, or rejected. Useful for spotting a forgotten device hammering an old password, or unauthorized access attempts.
## Actions
An audit trail of administrative changes: mailbox created or deleted, password changed, settings updated, aliases/forwarders/catch-all/auto-replies created or removed — each with the actor's role and IP address, and the failure reason where applicable.
## Troubleshooting with logs
**Recipient says the mail never arrived** Find it in **Delivery**. Delivered means it's on their side (spam folder, filters). Bounced shows the receiving server's reason — commonly a typo'd address or a DNS/reputation issue; check your [domain settings](/emails/domain-settings).
**Mailbox keeps getting locked or flooded with failures** Check **Access** for repeated failed logins, then change the mailbox password and switch devices to [app passwords](/emails/mailboxes#app-passwords).
**A forwarder or reply changed and nobody admits it** The **Actions** tab shows who did what, from which IP, and when.
***
*Last updated: July 22, 2026*
# Agentic Mail
Give AI agents programmatic access to Hostinger Email with API tokens, webhooks, outgoing mail allow and block lists, and a dedicated MCP server.
Give AI agents and applications programmatic access to your mailboxes — an email API, event webhooks, sending guardrails, and an MCP server. Find it under **Agentic Mail** in your email domain's sidebar (available on Hostinger Email plans).
## API access
Create API tokens for the email API (documented at [api.mail.hostinger.com](https://api.mail.hostinger.com)):
1. Open **Agentic Mail** → **API access**.
2. Create a named token.
3. Scope it to **all mailboxes** or a selected set, and choose its permissions — SMTP/IMAP actions and/or webhook management.
4. Copy the token immediately — it's shown only once.
Tokens are revocable individually, and there's a limit on how many you can hold at once.
To call the API from your own code, the official [Email SDKs](/api-reference/email-sdks) wrap it in PHP, Python, and TypeScript classes, and a `hostinger-mail` CLI covers the same operations from a terminal.
## Webhooks
Get an HTTPS `POST` with a JSON payload whenever something happens in a mailbox:
1. Open **Agentic Mail** → **Webhooks**.
2. Add your endpoint URL (HTTPS only).
3. Pick the mailboxes and trigger events.
4. Store the **secret key** shown at creation — use it to verify request signatures. It's shown once but can be regenerated.
The page includes a **Test** button and a **Recent deliveries** table with the last 20 attempts and their response times. Webhooks that fail repeatedly are paused automatically — fix the endpoint and re-enable.
## Allow and block lists
Guardrails for **outgoing** mail — especially useful when an AI agent can send on your behalf:
* **Allow list** — when non-empty, mail can only be sent to the listed addresses or domains.
* **Block list** — sending to listed addresses or domains is rejected.
Entries can be full addresses or whole domains. If an address matches both lists, the block list wins.
## MCP server
Connect AI assistants to your mailboxes via the Model Context Protocol:
* Server URL: `https://mcp.mail.hostinger.com/mcp`
* Setup instructions are provided for Claude Code, Claude Desktop, Cursor, Windsurf, and JetBrains IDEs, plus a ChatGPT integration under **Apps & integrations**.
* Capabilities: read and search mail, send and manage messages, manage folders and webhooks.
> **Note:** This is a separate MCP server from the [Hostinger Connector](/hostinger-connector/overview), which covers hosting, domains, and the rest of the platform. Run both if your assistant should manage hosting *and* email.
## Security notes
* Treat API tokens and webhook secrets like passwords — store them in a secrets manager, never in code.
* Scope tokens to the fewest mailboxes and permissions that work.
* Use the allow list when an autonomous agent sends mail — it turns "the agent emailed the wrong person" into a rejected send.
***
*Last updated: August 6, 2026*
# Reach Overview
Overview of Hostinger Reach, the AI-powered email marketing product — workspaces, the main sections of the app, built-in AI tools, and how plans and AI credits work.
**Hostinger Reach** is an email marketing product: build a contact list, design emails, and send campaigns or automated flows. It's separate from mailbox hosting — Reach sends marketing email *to* your audience, while [Hostinger Email](/emails/overview) gives you mailboxes to read and write your own mail.
Reach lives at [reach.hostinger.com](https://reach.hostinger.com), reachable from **Email marketing** in hPanel.
## Workspaces
Each Reach plan is an independent **workspace** with its own contacts, campaigns, settings, sending domain, and limits. Nothing is shared between workspaces.
If you manage several brands or sites, buy a separate Reach plan for each and move between them with **Switch workspace** in the account menu. When you have more than one, Reach asks which to open at sign-in.
> **Note:** A workspace connects to one sending domain at a time. Plan your workspaces around domains rather than around campaigns.
## What's inside
| Section | What it's for |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Home** | Starting point — campaign recommendations, deliverability warnings, recent activity |
| **Automations** | Emails that send themselves when something happens ([Automations](/reach/automations)) |
| **Audience** | [Contacts](/reach/contacts) and [Segments](/reach/segments) — who you send to |
| **Campaigns** | One-off sends and their results ([Campaigns](/reach/campaigns)) |
| **WhatsApp** | Connect a WhatsApp number, manage message templates, and send WhatsApp campaigns ([WhatsApp](/reach/whatsapp)) |
| **Templates** | Reusable email designs and the editor ([Templates & Editor](/reach/templates)) |
| **Forms** | Signup forms to collect contacts ([Forms](/reach/forms)) |
| **Integrations** | Contact sync from your site or store, and the Hostinger Connector for managing Reach from AI agents ([Integrations](/reach/integrations)) |
| **Settings** | Domain, sender details, brand details, double opt-in, notifications ([Settings](/reach/settings)) |
> **Note:** WhatsApp campaigns need a connected WhatsApp number. Open **WhatsApp** in the sidebar and choose **Connect WhatsApp** to set one up.
## AI in Reach
AI is woven through the product rather than sitting in one place:
* **Email and template generation** — describe what you want and Reach writes the copy, builds the layout, and applies your brand.
* **Campaign recommendations** — ideas grouped by topic (**Welcome**, **Educational**, **Promotional**, **Seasonal**, **eCommerce**), based on your brand details and the time of year. eCommerce ideas also draw on your store's products and coupons. Browsing them is free.
* **Campaign drafts** — turn an idea, or your own description on **Home**, into a full draft: strategy, email, a suggested audience, and a suggested send time.
* **Subject lines** — generated from the template you've chosen.
* **Segments from a description** — describe an audience in plain language and Reach proposes the matching conditions.
* **Automations from a description** — describe the flow and Reach drafts it.
* **Form generation** — build a signup form from a prompt.
* **Image generation** — create images for your email from a prompt in the editor's image gallery.
* **Brand capture** — enter your website and Reach fills in your logo, colors, keywords, and selling points.
* **Spam checker** — reviews a finished email and flags what could be improved before you send.
* **Smart sending** — sends to each contact at the hour they're most likely to open, within 24 hours of your scheduled time.
* **Agent** — an assistant in the header you can ask for help while you work.
The quality of AI output depends heavily on your [brand details](/reach/settings#brand-details), which is where Reach reads your tone, colors, logo, and what you sell.
## Plans and AI credits
Reach has a free plan and several paid tiers. Plans differ in how many people you can reach each month, how many emails you can send, and how many AI credits you get. Some features — including activating automations, scheduling campaigns, smart sending, the HTML editor, removing Reach branding, and [collaborators](/reach/settings#collaborators) — need a paid plan. On the free plan, the spam checker and AI subject lines work while you have AI credits.
AI actions consume **AI credits**. Each plan includes a monthly allowance that resets at the start of the month and does not roll over; the free plan includes no monthly credits, though new accounts get a one-time welcome batch. You can buy more credits or upgrade when you run out.
Your current usage and remaining credits are under **Plan & limits** in the account menu. For what each tier includes, see the [Reach product page](https://www.hostinger.com/reach).
## Related pages
* [Contacts](/reach/contacts) — statuses, sources, custom fields, tags, CSV import
* [Campaigns](/reach/campaigns) — building, sending, and measuring a campaign
* [Sending Domain](/reach/sending-domain) — the DNS records that get your mail delivered
* [Integrations](/reach/integrations) — sync contacts from WordPress, a store, or the API
***
*Last updated: September 30, 2026*
# Contacts
Manage your Hostinger Reach audience — subscription statuses, where contacts come from, custom fields, tags, and importing contacts from a CSV file.
Your audience. Every campaign and automation sends to contacts, filtered through [segments](/reach/segments). Find them under **Audience** → **Contacts**.
## Subscription status
Status decides whether a contact can be emailed at all.
| Status | Meaning | Receives email |
| ---------------------- | ---------------------------------------------------------------------------------------------- | -------------- |
| **Subscribed** | Opted in and mailable | Yes |
| **Waiting for opt-in** | Signed up but hasn't confirmed, when [double opt-in](/reach/settings#subscribe-settings) is on | No |
| **Unsubscribed** | Opted out, or removed by you | No |
Unsubscribed contacts are excluded from every send automatically — you don't need to filter them out yourself.
Contacts you add by hand or import from a CSV are **Subscribed** straight away. Double opt-in applies only to people who sign up through your [forms](/reach/forms).
> **Note:** Contacts that bounce are **not** unsubscribed automatically. They stay subscribed and keep receiving mail, which hurts your sender reputation. Clean them up periodically from a campaign's **Recipients** tab — see [Sending Domain](/reach/sending-domain#bounces-and-list-hygiene).
## Where contacts come from
Reach records how each contact arrived, shown as an icon in the list:
* **Manual** — added one at a time
* **Import** — uploaded from a CSV file
* **Sync** — pulled from a connected site or store ([Integrations](/reach/integrations))
* **Form** — submitted one of your [forms](/reach/forms)
Contacts also arrive through the API and at store checkout.
To find a contact, search the list by email address or phone number.
## Contact details
Opening a contact shows its consent status — when it subscribed or unsubscribed, and whether it came in through single or double opt-in — along with its details, source, note, custom field values, and tags. Choose **Edit** to change the details. From **Actions** you can subscribe, unsubscribe, or delete the contact; **Unsubscribe** isn't available while a contact is still waiting for opt-in.
Phone numbers are entered with a country selector and stored in international format, so the same number is recognized however it was typed.
## Custom fields
Beyond the built-in name, surname, email, and phone, you can define your own fields under **Audience** → **Contacts** → **Manage** → **Custom fields**.
| Type | Holds |
| ------------------- | -------------------------------------- |
| **Text** | Short free text |
| **Number** | Whole numbers |
| **Date** | A single date |
| **Single choice** | One option from a list you define |
| **Multiple choice** | Several options from a list you define |
Custom fields are usable in three places: as [segment](/reach/segments) conditions, as personalization tokens in emails, and as extra fields on a [form](/reach/forms).
## Tags
Tags are free-form labels for grouping contacts — a signup source, an interest, an event. Manage them under **Manage** → **Tags**, apply them in bulk from the contacts list, and build a [segment](/reach/segments) from a tag in one click.
## Importing from CSV
Choose **Add contact** → **Upload .CSV** to import a file. The import walks through four steps: **Upload**, **Map columns**, **Review**, and **Organize**.
* Accepted formats are `.csv` and `.txt`, up to **10 MB**.
* Map each column to email, first or last name, phone, subscribe date, or a note — or to one of your custom fields. If a column has no matching field, choose **Create custom field** to add one without leaving the import. Each field can be mapped to only one column, and unwanted columns can be skipped.
* Email is the only required column.
* **Review** reports valid rows, invalid addresses, and duplicates. Choose **Skip duplicates** to leave existing contacts unchanged, or **Update existing** to overwrite them with the file's values. Rows with an invalid phone number or other invalid optional fields show under **Warnings** and are imported without those values, and duplicate rows inside the file are skipped. Choose **Download report** to get a list of the rows that need attention.
* In **Organize** you can tag the contacts, add a short note, and group them into a new [segment](/reach/segments) — **Create segment** is on by default. If you don't choose a tag, Reach tags the contacts with the segment or file name so you can find them later. The import then runs in the background, which can take a while for large files.
> **Note:** Imported contacts don't trigger the "new subscriber" [automation](/reach/automations) — importing a list won't accidentally email everyone in it.
## Exporting
Select contacts in the list and choose **Export** to download them, or export the whole audience at once.
> **Note:** Your plan sets how many contacts you can reach. If your list grows past it, Reach shows an **Upgrade** banner on the contacts page — see the [Reach product page](https://www.hostinger.com/reach) for plans.
## Related pages
* [Segments](/reach/segments) — turn contact data into reusable audiences
* [Forms](/reach/forms) — collect contacts from your site
* [Integrations](/reach/integrations) — sync contacts automatically
***
*Last updated: September 30, 2026*
# Segments
Build reusable audiences in Hostinger Reach from contact attributes, tags, and campaign engagement, using AI suggestions or manual conditions.
A segment is a saved set of conditions that selects part of your audience — recently subscribed contacts, people who opened a campaign but didn't click, customers in one country. Campaigns and [automations](/reach/automations) send to segments rather than to raw contact lists.
Find them under **Audience** → **Segments**.
Segments are evaluated when you use them, not frozen at creation. A contact that starts matching the conditions is included in the next send automatically.
## Ways to create one
* **Describe it** — choose **New segment**, write the audience you want in plain language (or pick a suggested prompt), and Reach proposes matching conditions for you to review and adjust. This is what you see first when you have no segments yet. Each description uses one of your plan's AI messages — see the [Reach product page](https://www.hostinger.com/reach) for plans.
* **Build it by hand** — choose **New segment** → **Create manually** and add conditions yourself.
* **From a tag** — filter [contacts](/reach/contacts) by tag and turn that filter into a segment, or create one directly from the **Tags** page.
* **After a CSV import** — optionally group everything you just imported into a new segment.
* **From an automation** — when a flow needs a segment that doesn't exist yet.
* **From an AI campaign draft** — when Reach drafts a campaign for you, it may create a segment that matches the audience you described.
## Conditions
Each condition combines an attribute, an operator, and a value. A segment can have up to five conditions. Choose **Match all** to include contacts that meet every condition, or **Match any** to include contacts that meet at least one — the choice applies to all conditions in the segment.
| Attribute group | Attributes |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Contact details** | **Email address**, **Site's Domain** (when the contact synced from a connected site), **Note** |
| **Subscription** | **Subscription status**, **Opt-in method**, **Subscribed at**, **Unsubscribed at**, **Created at** (when the contact was added) |
| **Origin** | **Source type** — Manual, Imported, or Synced |
| **Tags** | **Tag** — has, or doesn't have, a given tag |
| **Campaign engagement** | **Opened**, **Clicked**, **Delivered**, **Processed**, **Bounced**, **Soft bounced**, or **Dropped** — and the negative of each |
| **Custom fields** | Any [custom field](/reach/contacts#custom-fields) you've defined |
Operators vary by attribute. Email and text fields support **Equals**, **Not equals**, **Contains**, and **Not contains**; **Site's Domain** and **Note** support only **Equals** and **Not equals**. Numbers support **Greater than or equal** and **Less than or equal**. Dates support **On or after** and **On or before**, plus rolling windows — **Within last days**, **Not within last days**, and **Older than days** — which keep a segment current without editing it.
Engagement conditions look across your sending history by default. To narrow them to one campaign, use **Sent campaigns**, which lists your 20 most recent sent campaigns and also covers whether a contact unsubscribed from it.
> **Note:** Contacts still waiting to confirm a double opt-in are matched through **opt-in method**, not subscription status.
## Using a segment
Pick one or more segments as a campaign's recipients, or as the entry condition for an automation. A campaign can also go to your whole audience without a segment — choose **Exclude some segments** to leave specific segments out of that send.
Choose **View** on a segment to see who currently matches it. From there you can search those contacts and export, tag, or delete them. Each segment's menu in the list also has **Edit segment**, **Rename**, and **Delete**.
## Related pages
* [Contacts](/reach/contacts) — the data segments filter on
* [Campaigns](/reach/campaigns) — choosing recipients for a send
* [Automations](/reach/automations) — segment-entry triggers
***
*Last updated: September 25, 2026*
# Campaigns
Build, schedule, and measure one-off email campaigns in Hostinger Reach — the four-step wizard, AI-drafted campaigns, campaign statuses, smart sending, and performance reporting.
A campaign is a single email sent to a chosen audience at a chosen time — a newsletter, an announcement, a promotion. For email that sends itself in response to an event, use [automations](/reach/automations) instead.
Find them under **Campaigns**.
## Building a campaign
The wizard has four steps, and you can leave and come back — an unfinished campaign stays a **Draft**.
| Step | What you choose |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Template** | The email itself — pick a [template](/reach/templates), start from AI, or upload HTML |
| **Campaign details** | Subject line, preheader, sender name and address, plus an internal title |
| **Recipients** | Your whole audience (optionally with **Exclude some segments**), or one or more [segments](/reach/segments). Only subscribed contacts are included |
| **Summary** | Review, then send now or schedule |
The subject line can be generated by AI from the template you picked, which needs a paid plan or AI credits. You can send a test email to yourself from the template step, and preview how the email looks in an inbox from the details step.
You need a connected [sending domain](/reach/sending-domain) to send a campaign or a test email. Until it's set up, you can only save the campaign as a draft.
### Drafting a campaign with AI
You can also describe the campaign to AI from **Home**. It drafts a plan, and **Create campaign** turns it into a wizard with the template, details, and audience filled in, marked **Built by AI**. This uses AI credits.
## Statuses
| Status | Meaning |
| ------------- | ----------------------------------------------------------- |
| **Draft** | Still being built; not sent |
| **Scheduled** | Queued for a future time — can be unscheduled back to draft |
| **Sending** | Currently going out |
| **Sent** | Finished |
| **Failed** | Stopped before or during sending |
## Scheduling and smart sending
Choose **Send now** or **Schedule send** on the summary step. Scheduling for a later time needs a paid plan. Scheduled times use your computer's local timezone, shown next to the time you pick.
**Smart sending** is a toggle under **Schedule send** that staggers delivery instead of sending everything at once: Reach picks a send time per contact, within 24 hours of your scheduled time, based on when that person has opened mail before. A campaign that's spreading its send shows as **Sending** until the last contact is done, and it can't be cancelled once started.
## When a campaign fails
A failed campaign explains why, and most causes are fixable:
| Reason shown | What to do |
| ----------------------------------- | ----------------------------------------------------------------------------- |
| Monthly send or recipient limit hit | Wait for the reset or upgrade — open **Plan & limits** from your account menu |
| No recipients found | The audience or segment is empty; add contacts and reschedule |
| Problem with your domain | Check [Sending Domain](/reach/sending-domain) |
| Sender mailbox suspended | Check your [sender details](/reach/settings#sender-details) |
| Sending stopped, high drop rate | Too many addresses rejected early; clean your list before retrying |
| Technical issue | Select **Review & reschedule** and send it again |
To protect your reputation, larger campaigns go out in a small first batch. If too much of that batch is rejected, Reach stops the campaign rather than burning your domain on a bad list.
## Reporting
Open a sent campaign for its results. The headline figures are:
* **Open rate** — how many recipients opened it
* **Click rate** — how many clicked a link
* **CTOR** — clicks as a share of opens, showing whether the content landed with people who actually read it
* **Unsubscribe rate** — how many opted out
* **Bounce rate** — how many addresses rejected the message permanently
Below them are four tabs:
| Tab | Shows |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Email details** | The email as it was sent |
| **Click map** | Every link, with how many clicks each got |
| **Recipients** | Per-person delivery outcome, filterable by **Hard-bounced**, **Soft-bounced**, **Not delivered**, or **Unsubscribed**. From **Hard-bounced** you can remove those contacts from your audience in one go |
| **Devices** | Which devices and operating systems opened it |
> **Note:** Opens and device data depend on the recipient's email client loading images, so treat them as indicative rather than exact. Privacy features in some clients inflate opens and obscure devices.
## Related pages
* [Templates & Editor](/reach/templates) — designing the email
* [Segments](/reach/segments) — choosing who receives it
* [Sending Domain](/reach/sending-domain) — deliverability and bounces
* [WhatsApp](/reach/whatsapp) — campaigns sent over WhatsApp instead of email
***
*Last updated: September 30, 2026*
# WhatsApp
Send marketing campaigns on WhatsApp from Hostinger Reach — connecting a number through Meta, building and submitting message templates, choosing opted-in recipients, and paying per delivered message
WhatsApp campaigns let you broadcast promotions and product updates from your own business number, straight to the chat app your customers already check. They sit alongside email [campaigns](/reach/campaigns) and use the same [contacts](/reach/contacts) and [segments](/reach/segments).
Find it under **WhatsApp** in the sidebar.
## Before you start
WhatsApp is available on selected Reach plans — see the [Reach product page](https://www.hostinger.com/reach) for which tiers include it. You'll also need:
* **A dedicated number** that isn't active in the WhatsApp app. Your everyday chat number stays untouched. A prepaid SIM or a VoIP number works, or you can request a new number during Meta signup.
* **Admin access to your Meta business account.** Any personal Facebook account works for signing in — your Facebook page or profile isn't linked to your campaigns.
* **Your business name and website.**
> **Warning:** Due to Meta's restrictions, WhatsApp marketing messages can't be sent to US phone numbers. The restriction applies to the recipient's number, not your business location.
## Connecting your number
Open **WhatsApp** and choose **Connect WhatsApp**. Setup runs in three stages:
1. **Before you start** — confirm you have what's listed above, then choose **Continue**.
2. **Connect number** — choose **Continue with Facebook**. Meta's secure signup opens in its own window, where you log in, pick your business portfolio and WhatsApp account, add and verify your marketing number, and set the display name customers see. Reach never sees your Facebook password.
3. **All set** — Reach registers the number for messaging and shows the connected number and display name.
After you connect, Meta reviews new business accounts. Most are approved within minutes, but it can take up to 24 hours.
## The WhatsApp workspace
Once connected, **WhatsApp** opens a workspace with two tabs, **Campaigns** and **Templates**, plus two panels:
* **Credits** — your available and reserved credit balance, with **Top up**
* **Activity** — delivered, read, and opt-out counts across your campaigns
## Templates
WhatsApp requires marketing messages to use templates that Meta has approved. You create a template in Reach, submit it, and once Meta approves it you can use it in any number of campaigns.
### Building a template
Choose **Create template**. A template has:
| Part | What it holds |
| ---------------------------------- | --------------------------------------------------------------------------------- |
| **Template name** and **Language** | For your reference; the name can't change after submission |
| **Header** | Optional — either text or an image (JPEG or PNG) |
| **Body** | The message itself, with bold, italic, strikethrough, and emoji |
| **Footer** | A short opt-out line, required on marketing templates |
| **Buttons & links** | Quick replies, website links, a phone number, or an offer code customers can copy |
Buttons share one limit per message. Within it, you can add up to two links, one phone number, and one offer code. Link buttons must use HTTPS and can't use link shorteners.
To personalize a message, add a variable from **Personalization** to the header or body. Each variable needs a fallback value, used when a contact has no value for that field. Meta rejects templates that start or end with a variable or place two variables side by side, so keep text around them.
The preview beside the editor shows the message as it will appear in a WhatsApp chat.
### Creating a template with AI
The editor also has an AI tab. Describe the message — its purpose, audience, and key details — or pick a starting point such as a limited-time offer, a new product announcement, or a feedback request, and choose **Generate template**. You can then ask AI to refine the draft, for example to make it more concise or strengthen the call to action. AI actions consume [AI credits](/reach/overview#plans-and-ai-credits).
### Submitting for approval
Choose **Save as draft** to keep working later, or **Submit for approval** to send the template to Meta. Review is handled entirely by Meta and can take 1–48 hours.
| Status | Meaning |
| -------------------- | ---------------------------------------------------------- |
| **Draft** | Not submitted yet — the only status you can edit or rename |
| **Pending approval** | Meta is reviewing it |
| **Approved** | Ready to use in campaigns |
| **Rejected** | Meta declined it, with a reason you can fix |
A submitted template is read-only. To change one, or to fix and resubmit a rejected template, **Duplicate** it and edit the copy.
## Creating a campaign
Choose **Create campaign**. The wizard has three steps, and an unfinished campaign stays a **Draft**:
| Step | What you choose |
| ----------------- | ------------------------------------------------------------------------------------------------------------ |
| **Template** | One of your approved templates. If none are approved yet, you can finish the campaign once Meta approves one |
| **Recipients** | One or more [segments](/reach/segments), with a summary of who can receive the message |
| **Review & send** | The campaign name (only you see it), the estimated cost, and whether to send now or schedule for later |
From **Recipients** you can also send a test to your own WhatsApp number. A test is billed like a normal message.
### Who receives the message
The recipient summary breaks your chosen segments down so you know who will be messaged before you pay:
* **Opted in to WhatsApp** — these contacts receive the campaign
* **No opt-in stored** — skipped, unless you tick the option to include them
* **Can't be messaged** — contacts with no phone number or an invalid one
Contacts in more than one selected segment are counted once. From each segment you can jump to **View contacts** to check who's in it.
> **Warning:** Only include contacts without a stored opt-in if they've agreed to receive WhatsApp messages from you. Anyone who replies with stop, cancel, or unsubscribe is unsubscribed automatically.
## Credits and billing
WhatsApp campaigns are paid with **Hostinger Credits** — one balance shared across Hostinger products — not with Reach AI credits. Eligible plans come with a one-time batch of welcome credits for your first campaigns.
* **You pay only for delivered messages.** Credits for messages that fail to deliver return to your balance automatically.
* **Prices depend on the recipient's country.** The review step shows a per-message breakdown and the estimated total against your available credits before you send.
* **The estimate is reserved when you send.** Reserved credits show separately from your available balance in the workspace until the campaign's final cost is settled.
* If the estimate exceeds your balance, Reach asks you to **Top up credits** or **Reduce audience** before sending. Recipients that can't be priced — usually because of an invalid phone number — are skipped and not charged.
For current rates, see the [Reach product page](https://www.hostinger.com/reach).
## Statuses and reporting
| Status | Meaning |
| ------------- | ----------------------------- |
| **Draft** | Not sent yet — still editable |
| **Scheduled** | Waiting for its send time |
| **Sending** | Going out now |
| **Sent** | Finished |
| **Failed** | Couldn't be sent |
Filter the **Campaigns** tab by any of these. Open a campaign for its results:
* **Sent** and **Delivered** — how many messages went out and how many reached a phone
* **Read rate** — read messages as a share of delivered ones
* **Credits used** — the final cost, or the estimate while the campaign is still sending
Below them are a preview of the message and a **Recipients** list showing, for each phone number, whether it was delivered and read. While a campaign is sending, the figures update as Meta reports delivery events.
> **Note:** Customer replies aren't shown in Reach — there's no WhatsApp inbox. Tell customers in the message how else they can reach you if they need to.
## Settings
**Settings** in the WhatsApp workspace shows your connected number. Account details live in your Meta Business account, and changes you make there sync to Reach automatically:
* **WhatsApp account settings** — display name, profile, and phone numbers. Choose **Open in Meta** to change them
* **Business verification** — choose **Check status**. A verified business unlocks higher sending limits
* **Disconnect from Reach** — removes the number from Reach so it stops sending campaigns. Your WhatsApp account itself isn't affected, and you can reconnect anytime
## Related pages
* [Contacts](/reach/contacts) — phone numbers and opt-in
* [Segments](/reach/segments) — choosing who receives a campaign
* [Campaigns](/reach/campaigns) — email campaigns
***
*Last updated: September 30, 2026*
# Automations
Set up automated email flows in Hostinger Reach — triggers, delays and conditions, ready-made templates for welcome and ecommerce journeys, statuses, and reporting.
An automation is an email flow that runs on its own when something happens: someone subscribes, submits a form, buys something, or leaves a cart behind. Unlike a [campaign](/reach/campaigns), you set it up once and it keeps running.
Find them under **Automations**. Activating an automation requires a paid plan.
## Triggers
Every automation starts with one trigger.
| Trigger | Starts when |
| ----------------------------------- | ------------------------------------------------------ |
| **Contact subscribes** | Any contact is added to your audience |
| **Contact joins a segment** | A contact enters a [segment](/reach/segments) you pick |
| **Contact submits a Reach form** | A contact submits a [form](/reach/forms) you pick |
| **Campaign is sent** | A [campaign](/reach/campaigns) you pick goes out |
| **Subscriber completes a purchase** | A customer completes an order in your connected store |
| **Subscriber abandons their cart** | A shopper leaves items without checking out |
The segment trigger can watch several segments and fire **Every time a contact joins** or for **New contacts only**. The form trigger can fire for everyone who submits, or only for people who are new contacts. The purchase trigger can apply to any product or to a specific list of product URLs.
> **Note:** Contacts added by CSV import don't fire the **Contact subscribes** trigger, so importing a list won't email everyone in it.
## Steps
After the trigger, a flow is built from three kinds of step, ending in **Exit flow**.
* **Email** — sends a template. Each email step reports separately.
* **Delay** — waits, either for a duration in hours, days, or weeks, or until a specific date and time. The date option suits event reminders: contacts who arrive after that date skip the email rather than receiving something stale.
* **Condition** — splits the flow on engagement. Choose **Didn't open email** or **Opened but didn't click**, then build the **Yes** and **No** branches. A condition can test an **Email in this automation** or a **Campaign** you've sent, so a follow-up can react to the message before it.
## Drafting an automation with AI
Choose **New automation** and **Describe your automation** to have AI draft one. Review **Your automation plan** — its goal, when it starts, and the flow — then select **Create automation** to build it. This uses AI credits.
## Ready-made flows
Reach offers a set of starting points, grouped by purpose. Each opens as a complete flow you can edit.
| Group | Flows |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **First steps** | A single welcome email, a multi-email welcome series, a promotional series, a trust-building series, and an email for form submissions |
| **Ecommerce** | Abandoned cart, product recommendations after a purchase, a review request, and a repeat-purchase discount |
| **Follow-up** | Re-engage contacts who didn't open a campaign, or who opened without clicking |
| **Re-engagement** | Win back inactive contacts, an anniversary reward, and a feedback request |
**Build from scratch** starts with an empty flow and the trigger picker.
The ecommerce flows need a connected store — see [Integrations](/reach/integrations). Abandoned-cart timing is set by the store integration, not by a delay step: the store waits about an hour after checkout is abandoned before telling Reach, so the email typically arrives one to two hours later. Each contact gets at most one abandoned-cart email every eight hours.
## Statuses
| Status | Meaning |
| ---------- | ---------------------------- |
| **Draft** | Being built; not running |
| **Active** | Live and processing contacts |
| **Paused** | Set up but not running |
An active automation opens read-only so a live flow can't be changed underneath the contacts moving through it. Choosing **Edit automation** pauses it first.
Use **Resume automation** to restart a paused one. Reach also pauses an automation automatically, for example if your account has no active plan, and the report explains why.
## Reporting
The report for any non-draft automation shows how many contacts have **Started**, are **In progress**, have **Completed**, or have **Failed**, with failures explaining why.
Below that, **Step analysis** lists each email in the flow. Opening one shows the same performance figures and tabs as a [campaign report](/reach/campaigns#reporting), so you can see which message in a series is losing people.
## Related pages
* [Segments](/reach/segments) — segment-entry triggers
* [Forms](/reach/forms) — form submission triggers
* [Integrations](/reach/integrations) — connecting a store for ecommerce flows
***
*Last updated: September 25, 2026*
# Templates & Editor
Design emails in Hostinger Reach — create templates with AI or from the gallery, edit sections, set template styles, personalize content, and run the spam checker.
A template is a reusable email design. Campaigns and [automations](/reach/automations) both send templates, and the same editor builds [forms](/reach/forms).
Find them under **Templates**.
## Creating a template
* **Describe it** — write what the email should say and Reach generates the copy, layout, and imagery, styled from your [brand details](/reach/settings#brand-details).
* **Browse templates** — pick a ready-made design, filtered by category. Use it as is with **Use without changes**, or turn on **Apply my brand details** to restyle it with your logo, colors, and fonts and optionally describe other changes. Applying brand details uses AI credits.
* **Upload HTML** — bring your own markup. Requires a paid plan.
## The editor
An email is a stack of **sections** — a header, some text, an image, a button, a footer. Select a section to edit it, drag to reorder, or insert a new one from **Add section**: text, buttons, images, video, headings, and layout or spacing blocks. You can also describe a section and let AI build it, which uses AI credits.
You can also edit by asking: describe a change in the chat and Reach applies it to the template.
Editing a template that campaign drafts or automations already use changes all of them. Reach warns you first, so you can choose **Edit anyway** or **Create a duplicate instead**.
### Template styles
**Template styles** set the look of the whole email at once, rather than section by section: heading and body fonts, text and link colors, page background, and button appearance including color, text color, border, and corner radius. **Apply brand details styles** resets them to your [brand details](/reach/settings#brand-details).
### Personalization
Insert a contact's details into the text and each recipient sees their own values:
* Built-in: first name, last name, email address, phone number
* Any [custom field](/reach/contacts#custom-fields) you've defined
Personalization tokens take a fallback for contacts with that field empty, so an email opens with "Hi there" rather than "Hi ,". The built-in name tokens come with sensible fallbacks already.
### Dynamic cart link
Emails used by an abandoned-cart [automation](/reach/automations) can include a link back to the shopper's own cart. Set a fallback URL for recipients whose cart can't be resolved, so the button always goes somewhere useful.
### HTML editing
The code editor gives direct access to the email's HTML. It requires a paid plan.
## Spam checker
The **Spam checker** reviews a finished email and groups its findings by severity, from things that could be better to things needing major work — covering the content, structure, and choices that tend to land mail in spam. Run it before sending. Apply suggestions one by one with **Fix selected**, or all at once with **Apply all fixes**. It requires a paid plan or AI credits.
## Reach branding
Emails and forms on the free plan include a small Reach signature. Removing it requires a paid plan.
## Testing before you send
Send a test email to yourself from a campaign's template step, and use the inbox preview to check the subject line, preheader, and sender name as they'll appear in a crowded inbox.
## Related pages
* [Campaigns](/reach/campaigns) — sending a template
* [Settings](/reach/settings#brand-details) — the brand details AI generation draws on
* [Forms](/reach/forms) — the same editor in form mode
***
*Last updated: September 25, 2026*
# Forms
Create signup forms in Hostinger Reach to collect contacts, choose the fields and consent options, style them, and embed them on your website.
Forms collect contacts from your website into your Reach [audience](/reach/contacts). A submission creates or updates a contact, and can start an [automation](/reach/automations).
Find them under **Forms**.
## Form types
**Full page/embedded** forms sit inside a page on your site or open from their own link. Pop-up forms are coming soon.
To create a form, choose what it offers visitors — a newsletter, a PDF or eBook, a discount code, a checklist, webinar access, or no incentive — and Reach prefills a prompt for it. Edit the prompt if you like, then generate the form.
## Building a form
The editor works like the [email editor](/reach/templates), with a sidebar for fields and styling.
* **Fields** — email is always required. Add first name, last name, phone number, and any [custom field](/reach/contacts#custom-fields) you've defined, and mark each as **Required** if you need it.
* **GDPR consent** — an optional consent checkbox for jurisdictions that require explicit opt-in.
* **After submit** — either show a thank-you message or redirect to a URL of your own.
* **Styling** — background (or transparent), body text, input text, button, button text, and border colors, plus any images in the form, so it matches the page it sits on.
On the free plan, forms carry Reach branding; removing it needs a paid plan.
## Statuses
| Status | Meaning |
| ---------- | ---------------------------------------- |
| **Draft** | Not published; not collecting |
| **Active** | Live and collecting submissions |
| **Paused** | Published previously, not collecting now |
A live form opens read-only, so its fields can't shift under visitors mid-submission. Choosing to edit pauses it first, and it stops collecting until you select **Activate form** again.
Pause, activate, duplicate, or delete a form from its menu in the forms list.
## Publishing
The publish screen offers several routes, depending on where your site lives:
| Option | How it works |
| ------------------------ | --------------------------------------------------------------- |
| **AI Builder (Manual)** | Connect your Hostinger site and place the form from the builder |
| **AI Builder (Agentic)** | Copy a prompt that adds the form to your site's AI chat |
| **WordPress** | Connect your WordPress site and place the form from the plugin |
| **Embed** | Paste two snippets into any site's HTML |
| **Share** | Use the form's own public URL, with nothing to embed |
Manual and Agentic are the two modes of Hostinger AI Builder — see [Integrations](/reach/integrations#sites-and-stores).
Embedding takes a script tag, once per page, plus a placeholder where the form should appear:
```html
```
The publish screen shows both snippets with your form's ID already filled in.
## What happens on submission
A submission creates the contact. If the address is already in your audience, it fills in any details that are missing without overwriting what's there.
If [double opt-in](/reach/settings#subscribe-settings) is on, the new contact is set to **Waiting for opt-in** and receives a confirmation email; it isn't mailable until confirmed. With double opt-in off, the contact is **Subscribed** immediately.
To send a welcome email, or anything else in response, pair the form with a form-submission [automation](/reach/automations).
## Related pages
* [Contacts](/reach/contacts) — where submissions land
* [Automations](/reach/automations) — reacting to a submission
* [Settings](/reach/settings#subscribe-settings) — double opt-in
***
*Last updated: September 25, 2026*
# Sending Domain
Connect and verify a sending domain in Hostinger Reach with SPF, DKIM, and DMARC records, and keep campaigns landing in the inbox rather than in spam.
Reach sends from your own domain, which means proving to receiving mail servers that you're allowed to. That's what the sending domain setup does. Until it's verified, campaigns can't go out and automations can't be switched on.
Find it under **Settings** → **Domain**. Each [workspace](/reach/overview#workspaces) connects one sending domain at a time. A domain can only be connected to one workspace, and temporary domains aren't supported. To use a different domain, select **Disconnect domain** first.
## The records
Three DNS records do the work, and Reach checks each one:
| Record | What it does |
| --------- | ------------------------------------------------------------------------------------ |
| **SPF** | Lists Reach as allowed to send for your domain, so your mail isn't treated as forged |
| **DKIM** | Signs each message cryptographically, letting receivers confirm it wasn't altered |
| **DMARC** | Tells receivers what to do with mail that fails the checks above |
The page shows the exact records to add. They depend on whether you send from your main domain or a subdomain, and the SPF value already includes anything your current SPF record allows, so copy them from there rather than from anywhere else.
A domain can have only one SPF record. If you already have one for another service, replace it with the combined record Reach shows rather than adding a second.
Your domain also needs at least one **A** or **MX** record — a sign to receivers that it's a real, active domain. A site gives you the A record and a mailbox gives you the MX record; without one of them, campaigns can't be sent. For a main domain these appear under **Recommended records**. When you send from a subdomain, the same check appears as **Make your subdomain look real**.
## Connecting
* **DNS managed by Hostinger** — Reach can add the records for you with **Set up automatically**.
* **DNS hosted elsewhere** — copy each record into your DNS provider, then select **Check status**. Propagation is usually quick but can take several hours.
* **Domain from another provider** — select **Add a domain from another provider** and enter your main domain. Reach first asks you to prove you own it: add the TXT record shown to your DNS settings, wait 5–15 minutes, then select **I've updated DNS records**. Once ownership is confirmed, add the sending records.
Each record shows whether it passed, so a partial setup is easy to spot. A domain that isn't fully verified reports which record is still missing.
### Main domain or subdomain
When you choose a domain, Reach recommends sending marketing email from a **Separate subdomain** (for example, `mail.yourdomain.com`) rather than the **Main domain**. Marketing mail goes to many people at once, and keeping it on its own subdomain protects the reputation of your other email, such as order confirmations and support replies. The main domain suits small, infrequent campaigns.
You can change this later from the domain card with **Use a subdomain instead**, **Change**, or **Remove**.
> **Note:** This is separate from the DNS setup for [mailboxes](/emails/domain-settings). A domain can send marketing mail through Reach and host mailboxes at the same time, but the records serve different purposes and both need to be right.
## Deliverability warnings
Reach watches how receivers treat your mail and warns you in the app when something's wrong. Warnings fall into two kinds:
* **Needs attention** — a lot of mail isn't arriving as expected. Sending still works, but it may be suspended if the pattern continues.
* **Sending blocked** — too much of your mail was treated as spam or generated complaints. Sending stops until the problem is reviewed.
Both name the affected domain. A blocked domain needs a review request through Customer Support, after you've addressed the underlying cause: the content, the list, or how the addresses were collected.
A sender mailbox or domain can also be suspended outright following high bounce rates, spam reports, or policy violations.
## Bounces and list hygiene
A bounce is a message the receiving server refused.
* **Hard-bounced** — permanent. The address doesn't exist or rejects you outright.
* **Soft-bounced** — temporary. A full mailbox, a rate limit, a server having a bad day.
* **Not delivered** — Reach stopped the message before sending it, to protect your sender reputation.
A campaign's **Recipients** tab breaks these out per contact with the reason given.
> **Note:** Hard-bounced contacts are **not** unsubscribed automatically. They stay subscribed and keep being mailed, which pushes your bounce rate up and your reputation down. Delete them periodically from the campaign's **Recipients** tab.
Reach also stops a large campaign mid-send if too much of the first batch is rejected, so one bad list doesn't damage your domain for everything that follows.
## Keeping deliverability healthy
* Send to people who asked for it — turn on [double opt-in](/reach/settings#subscribe-settings) if you collect addresses through [forms](/reach/forms).
* Never buy or scrape lists; they generate the complaints that get domains blocked.
* Clear hard bounces after each campaign, or build a [segment](/reach/segments) of **Bounced** contacts and exclude it when choosing a campaign's recipients.
* Make unsubscribing easy. An unsubscribe is far better for you than a spam complaint.
* Run the [spam checker](/reach/templates#spam-checker) before sending.
## Related pages
* [Campaigns](/reach/campaigns) — send failures caused by domain problems
* [Settings](/reach/settings#sender-details) — the name and address your mail comes from
* [Email Domain Settings](/emails/domain-settings) — the equivalent records for mailboxes
***
*Last updated: September 25, 2026*
# Settings
Configure Hostinger Reach — sender name and address, brand details that guide AI generation, double opt-in, notifications, plan usage and AI credits, and team collaborators.
Workspace-level configuration. Find it under **Settings**. The sending domain has its own page — see [Sending Domain](/reach/sending-domain).
## Sender details
The name and address your mail comes from, and what recipients see first in their inbox.
The address uses your connected [sending domain](/reach/sending-domain), so you choose the part before the `@`. A preview shows how the sender name and address appear in an inbox.
Pick something recognizable — a company name, or a person at the company. Recipients decide whether to open based largely on the sender, and an unfamiliar one gets ignored or reported.
If you haven't connected a domain yet, connect one first to customize sender details. To let subscribers reply to you, use **Create mailbox** to set up a mailbox on the same domain.
## Brand details
Brand details are the single biggest lever on AI output quality. Templates, campaign drafts, and forms are all built from what Reach finds here.
To start quickly, use **Capture your brand details**: enter your website, select **Get brand details**, and Reach fills in your logo, colors, keywords, and selling points for you to review.
| Section | What it covers |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Logo** | Your logo |
| **Font** | **Headings** and **Body text and buttons** fonts |
| **Colors** | **Template background**, **Text**, **Button color**, **Button text**, **Accent color**, **Link color**, and button corner style |
| **Social links** | Links shown in email footers |
| **Business description** | What your business does |
| **Business details** | Business name, address, privacy policy URL, website URL |
| **Keywords**, **Selling points**, **Topics** | What you sell and what you talk about |
Filling in **Business description**, **Selling points**, **Topics**, and **Keywords** properly is what separates generic AI copy from something that sounds like your business. Colors and fonts are reused as the defaults for [template styles](/reach/templates#template-styles) in the editor. In an existing template, select **Apply brand details styles** to use them.
## Double opt-in
**Double opt-in** decides what happens when someone signs up through a [form](/reach/forms) or is synced from an [integration](/reach/integrations).
With it **off**, a new contact is **Subscribed** straight away and can be emailed immediately.
With it **on**, the contact is created as **Waiting for opt-in** and Reach emails them a confirmation link. Clicking it makes them **Subscribed**. Until then they receive no campaigns or automations. You can set the confirmation email's subject and sender address, and preview both the email and the confirmation page.
You need a connected [sending domain](/reach/sending-domain) before you can turn double opt-in on. Confirmation emails don't count against your plan's email limits.
> **Note:** Confirmation links don't expire and aren't resent automatically. Contacts who never confirm stay pending indefinitely without being mailed — clear them out after a few weeks.
Double opt-in costs you some signups but is worth it: a confirmed list bounces less, complains less, and protects the domain reputation every future campaign depends on. Some jurisdictions require it.
## Notifications
Turn on **Monthly performance overview** to get a monthly email comparing last month with the month before: campaigns sent, emails delivered, new subscribers, and your best performing campaign.
## Plan & Limits
Open **Plan & limits** from the account menu to see usage against your plan's monthly allowances, when they reset, and links to **Billing details** and **Change plan**:
* **Unique recipients** — how many different people you've emailed this month. Emailing the same person again doesn't add to this.
* **Emails** — total sent this month.
* **AI credits** — remaining credits for AI features.
Each shows how much is left. **Unique recipients** and **Emails** warn you as you approach the limit. Running out of recipients doesn't stop you emailing people you've already contacted this month; running out of emails stops sending until the reset.
Your plan's monthly AI credits reset each month and don't roll over. Credits you buy with **Get more credits** stay until you use them, and are used first. To get a larger monthly allowance, upgrade your plan. For what each tier includes, see the [Reach product page](https://www.hostinger.com/reach).
## Collaborators
Collaborators let other people work in your Reach [workspace](/reach/overview#workspaces) — useful when a marketer or agency runs campaigns on your behalf.
Start from **Add collaborators** in the account menu. Access is granted through hPanel's account sharing rather than inside Reach. The person you invite needs their own Hostinger account, accepts an emailed invitation, and then opens your Reach workspace from their own hPanel. What they can do depends on the role you assign.
Collaborators require a paid plan.
## Related pages
* [Sending Domain](/reach/sending-domain) — DNS records and deliverability
* [Templates & Editor](/reach/templates) — where brand details are applied
* [Forms](/reach/forms) — what double opt-in changes about signups
***
*Last updated: September 25, 2026*
# Integrations
Connect Hostinger Reach to your website, online store, WordPress, AI assistants, and your own systems to sync contacts and enable ecommerce automations.
Integrations keep contacts flowing into Reach without manual work, and unlock the ecommerce [automations](/reach/automations) that need to know about orders and carts.
Find them under **Integrations**.
## Available integrations
| Integration | What it gives you |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **AI Builder** | Sync contacts from a Hostinger AI Builder site, and place [forms](/reach/forms) on its pages |
| **Hostinger Ecommerce** | Purchase and abandoned-cart triggers, opted-in contacts from checkout, and store knowledge for AI — mention any product or discount code when creating emails or forms and Reach already knows its details, prices, and images |
| **WordPress** | Collect contacts from WordPress forms and plugins, and keep your site in sync |
| **Hostinger Connector** | Manage Reach by asking an AI assistant, over a single MCP connection |
| **Reach public API** | Build your own integration against contacts and segments |
The AI Builder, Hostinger Ecommerce, and WordPress cards show **Connected** once they're linked.
## Sites and stores
Connecting a site is what makes contact sync and ecommerce triggers work. Once connected, new signups arrive on their own and orders can start an automation.
Hostinger AI Builder sites come in two modes, and Reach connects to both. **Manual mode** (formerly Website Builder) is the drag-and-drop editor, so you connect the site and place forms yourself. **Agentic mode** (formerly Horizons) builds the site from a chat, so you ask its AI to connect Reach and add a form for you. Reach labels the two as **AI Builder (Manual)** and **AI Builder (Agentic)** wherever the choice matters.
Each workspace connects one site of each kind — a WordPress site, a Manual AI Builder site, and an Agentic AI Builder site — and one store. A store can belong to only one workspace; one already in use elsewhere shows **Connected to another profile**.
WordPress sites hosted outside Hostinger connect through **Connect site from another provider**: download the Hostinger Reach plugin, upload it in WordPress, and activate it.
For ecommerce automations on WordPress, the store side matters as well as the site: WooCommerce needs to be installed and active, with the Reach integration enabled inside it. Reach tells you in the automation editor when a trigger can't work because the store isn't ready, and links to where to fix it.
> **Note:** Abandoned-cart timing comes from the store, not from Reach. See [Automations](/reach/automations#ready-made-flows).
## Hostinger Connector
[Hostinger Connector](/hostinger-connector/overview) exposes Reach to AI assistants such as ChatGPT, Claude, and Cursor through the Model Context Protocol, so you can work in natural language instead of clicking through the app:
* *"Show me contacts added this week"*
* *"Create a contact and tag it Webinar"*
* *"Rename the segment Winter leads to Q1 leads"*
* *"How many contacts do I have in total?"*
It covers contacts, tags, segments, custom fields, and imports, and is included with your Hostinger plan.
## Reach public API
The API suits custom setups and syncing from systems with no ready-made integration. Working with it takes three things:
1. **A Hostinger API token**, created from **Generate API token** on the Reach public API page (open it with **Learn more**). One token covers Reach and other Hostinger APIs.
2. **Your profile ID**, which identifies the [workspace](/reach/overview#workspaces) you're operating on.
3. **The endpoints themselves** — create and update contacts, and manage segments.
Pass the token as a bearer token in the `Authorization` header. Full reference documentation is linked from the API page, and the same endpoints work from workflow tools such as n8n if you'd rather not write code.
Treat tokens like passwords: store them in a secrets manager, never in source control, and revoke any that leak.
### API tokens
**API tokens**, at the bottom of the Integrations page, manages tokens that connect this workspace to your own systems, such as the WordPress plugin. Give each token a name. It's shown only once, so copy it straight away. Deleting a token with **Delete token** breaks anything still using it immediately.
## Related pages
* [Contacts](/reach/contacts) — where synced contacts land
* [Automations](/reach/automations) — the flows that ecommerce triggers drive
* [Hostinger Connector](/hostinger-connector/overview) — installing and using the Connector
* [API Reference](/api-reference/overview) — Hostinger's wider API and CLI
***
*Last updated: September 25, 2026*
# WordPress Overview
Overview of WordPress hosting tools on Hostinger, including one-click installs, managed updates, LiteSpeed caching, staging, security, and hPanel features.
One-click installs, managed updates, caching out of the box, and WordPress-specific tools in hPanel.
## Install WordPress
One click during website creation, or any time from your website dashboard. See [Installing WordPress](/wordpress/installing).
## Access the WordPress admin
```
https://yourdomain.com/wp-admin
```
Or open your website dashboard in hPanel and click **WordPress** or **Admin panel**.
## WordPress-specific tools in hPanel
| Feature | What it does |
| ------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Security](/wordpress/security) | Smart auto-updates, update log, plugin/theme update states, PHP compatibility |
| [Staging](/wordpress/staging) | Isolated copy of the site to test changes before pushing live |
| [Copy Website](/wordpress/copy-website) | Duplicate a site into a new hosting slot or another domain |
| [Presets](/wordpress/presets) | Auto-install your saved choice of plugins and templates on new sites |
| [AI Troubleshooter](/wordpress/ai-troubleshooter) | One-click AI diagnosis and fixes for website performance issues |
| [Plugins](/wordpress/plugins) | Install, update, and manage plugins from hPanel |
| [Themes](/wordpress/themes) | Install and manage themes |
## Performance
* **LiteSpeed** — toggle on the WordPress dashboard, with its own **LiteSpeed Settings** page. Page cache, browser cache, image optimization.
* **Object Cache** — separate toggle for database-query caching; requires LiteSpeed to be enabled first. Included on eligible plans.
* **Server-side cache** — cached pages served without executing PHP. See [Cache](/websites/cache).
* **CDN** — static assets served globally. See [CDN](/websites/cdn).
* **PageSpeed** — measure Core Web Vitals and act on recommendations. See [PageSpeed](/websites/pagespeed).
## Maintenance mode
The WordPress dashboard has a **Maintenance mode** toggle — visitors can't access the site while it's on. Use it during risky changes when you don't want half-finished work public.
## Security at a glance
* **SSL** — enable HTTPS for every site. See [SSL Certificates](/websites/ssl).
* **Malware scanning** — automatic file-level detection on your hosting. See [Malware Scanner](/websites/malware-scanner).
* **WordPress Security** — smart auto-updates and update visibility for core, plugins, and themes. See [Security](/wordpress/security).
## FAQ
How do I install WordPress on Hostinger?
Choose WordPress during website creation for a one-click install, or install it any time from your website dashboard in hPanel. See [Installing WordPress](/wordpress/installing).
How do I log in to my WordPress admin panel?
Go to `https://yourdomain.com/wp-admin`, or open your website dashboard in hPanel and click **WordPress** → **Admin panel** to log in without a password.
Does Hostinger update WordPress automatically?
Yes. The Security tool applies smart auto-updates to WordPress core, plugins, and themes, and keeps an update log so you can see what changed. See [Security](/wordpress/security).
Can I test changes before pushing them to my live site?
Yes. Staging creates an isolated copy of your site where you can test updates, plugins, and design changes, then push to live when ready. See [Staging](/wordpress/staging).
How do I make my WordPress site faster on Hostinger?
Enable LiteSpeed caching and Object Cache from the WordPress dashboard, turn on the CDN, and use PageSpeed to measure Core Web Vitals and apply recommendations.
Is SSL included with WordPress hosting?
Yes. Every domain and subdomain hosted on Hostinger gets a free lifetime SSL certificate that renews automatically. See [SSL Certificates](/websites/ssl).
## Related guides
* [Installing WordPress](/wordpress/installing)
* [Plugins](/wordpress/plugins)
* [Themes](/wordpress/themes)
* [Security](/wordpress/security)
* [Staging](/wordpress/staging)
***
*Last updated: July 27, 2026*
# Installing WordPress
Step-by-step guide to installing WordPress on Hostinger via hPanel during website creation, on an existing site, or by importing from another host.
Install WordPress during website creation, on an existing site, or by importing from elsewhere.
## During website creation
Fastest path:
1. In hPanel, go to **Websites** → **Add website**.
2. Choose **Install WordPress**.
3. Select your domain or a free subdomain.
4. Optionally set:
* WordPress admin username and password
* Site title
* Language
5. Complete setup.
WordPress is installed and running within seconds.
## On an existing website
1. Open your website dashboard.
2. Go to **WordPress** or **Auto Installer**.
3. Select **WordPress**.
4. Fill in:
* **Domain** to install on
* **Directory** — root (`/`) or subdirectory (e.g., `/blog`)
* **Admin username and password**
* **Admin email** — for resets and notifications
* **Site title**
* **Language**
5. Click **Install**.
## Import an existing site
### Option A: Migration wizard
1. In hPanel, go to **Migrations** or **Move to Hostinger**.
2. Follow the wizard and provide your current host credentials.
3. Hostinger imports files and database.
### Option B: Manual
1. Export your WordPress database as `.sql` (phpMyAdmin or `mysqldump`).
2. Archive WordPress files as `.zip` or `.tar.gz`.
3. Upload both to your Hostinger site's file storage.
4. Either use the [Import WordPress website](/api-reference/endpoints/wordpress/installations/import-wordpress-website) endpoint, or:
* Extract the archive in File Manager
* Import the SQL via phpMyAdmin
* Update `wp-config.php` with new database credentials
## After installation
* Log in at `https://yourdomain.com/wp-admin`
* [Enable SSL](/websites/ssl) and update your WordPress URL to `https://`
* Install your theme
* Activate the **LiteSpeed Cache** plugin
* Set up [backups](/websites/backups)
## Troubleshooting
**Forgot your WordPress admin password**
* Use the WordPress login page → "Lost your password?"
* Or reset it in hPanel → website dashboard → **WordPress**.
* Or reset via phpMyAdmin by updating the `user_pass` field in `wp_users` with a new MD5-hashed password.
***
*Last updated: July 21, 2026*
# Presets
Learn how Hostinger WordPress presets automatically install your saved plugins and templates on new sites, and how to create and apply them in hPanel.
WordPress presets automatically install your choice of plugins and templates on new sites — skip the "install the same 12 plugins every time" routine when you build sites regularly.
Presets are part of the **WordPress Add-ons** bundle (available with a free trial), together with automated site reports, website monitoring, and 1-click ownership transfers.
## What a preset contains
* Your selected plugins
* Your selected theme or template
You define the contents yourself — a preset is your own saved setup, reusable on every new WordPress site you create.
## Create a preset
1. In hPanel, open the **WordPress presets** management page (under WordPress Add-ons).
2. Click to create a new preset.
3. Pick the plugins and the template to include.
4. Name and save it.
You can edit or delete saved presets from the same page.
## Apply a preset
When creating a new WordPress site, the onboarding flow asks whether you want to use your WordPress preset for the project. Choose the preset and Hostinger installs WordPress with your plugins and template already in place.
## Troubleshooting
**A plugin from the preset failed to install** Install it manually from **Plugins** → **Add New** in the WordPress admin, or check its compatibility with the installed WordPress version.
***
*Last updated: July 22, 2026*
# WordPress Themes
Learn how to install, switch, customize, and update WordPress themes on Hostinger, including uploading zips, using child themes, and API deployment.
Themes control the look of your WordPress site. Install from the WordPress directory, upload a zip, or deploy via API.
## Install a theme
### From the WordPress admin
1. **Appearance** → **Themes** → **Add New**.
2. Browse or search.
3. Click **Install**, then **Activate**.
### Upload a zip
1. **Appearance** → **Themes** → **Add New** → **Upload Theme**.
2. Upload the `.zip`.
3. Click **Install Now**, then **Activate**.
### Via API
Deploy a theme with the [Deploy WordPress theme](/api-reference/endpoints/wordpress/themes/deploy-wordpress-theme) endpoint. Optionally activate automatically.
## Switch themes
1. **Appearance** → **Themes**.
2. Hover over the theme.
3. Click **Activate**.
Switching themes doesn't delete posts, pages, or media — only the presentation changes.
## Customize
### WordPress Customizer
1. **Appearance** → **Customize**.
2. Adjust colors, fonts, layout.
3. Click **Publish**.
### Full Site Editing (FSE)
If your theme is a block theme, go to **Appearance** → **Editor** for drag-and-drop editing.
## Child themes
A child theme inherits from a parent theme but isolates your customizations — so parent updates don't overwrite your changes.
Create a directory in `wp-content/themes/` with a `style.css` that references the parent theme and a `functions.php`.
## Update themes
1. **Appearance** → **Themes**.
2. Click **Update Now** on themes with updates.
> **Tip:** Back up first. See [Backups](/websites/backups).
## Troubleshooting
**Site broken after activating a theme** Switch back to a default theme (e.g., Twenty Twenty-Four) via SSH:
```bash
mysql -u dbuser -p dbname -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name='template' OR option_name='stylesheet';"
```
***
*Last updated: July 21, 2026*
# WordPress Plugins
Learn how to install, update, and manage WordPress plugins from the WordPress admin, Hostinger hPanel, or the API, plus fixes for broken plugin issues.
Install and manage plugins from the WordPress admin or hPanel.
## Install a plugin
### From the WordPress admin
1. Log in at `yourdomain.com/wp-admin`.
2. Go to **Plugins** → **Add New**.
3. Search for the plugin.
4. Click **Install Now**, then **Activate**.
### Upload a zip
1. **Plugins** → **Add New** → **Upload Plugin**.
2. Upload the `.zip`.
3. Click **Install Now**, then **Activate**.
### Via API
Deploy a plugin from an uploaded directory with the [Deploy WordPress plugin](/api-reference/endpoints/wordpress/plugins/deploy-wordpress-plugin) endpoint. Useful for CI/CD pipelines.
## Manage plugins
From **Plugins** in the WordPress admin:
* **Activate / Deactivate**
* **Update**
* **Delete**
Or in hPanel → your website → **WordPress**:
* View installed plugins and versions
* Check for and apply updates
## Update plugins
### Individually
1. Go to **Plugins** in the WordPress admin.
2. Click **Update Now** on the plugin with an update available.
### In bulk
1. **Plugins** → **Installed Plugins**.
2. Check the header checkbox to select all.
3. **Bulk Actions** → **Update** → **Apply**.
> **Tip:** Back up your site before updating. See [Backups](/websites/backups).
## Troubleshooting
**Site broken after installing a plugin** If you can't reach the admin, disable the plugin via FTP/SSH by renaming its directory:
```bash
mv public_html/wp-content/plugins/plugin-name public_html/wp-content/plugins/plugin-name.disabled
```
To disable everything at once, rename `wp-content/plugins` itself — WordPress disables all plugins.
***
*Last updated: July 21, 2026*
# WordPress Security
Manage WordPress security on Hostinger with smart auto-updates for core, plugins, and themes, update logs, PHP compatibility checks, and Patchstack.
Keep WordPress core, plugins, and themes up to date automatically, and see the update state of your whole install at a glance — from the **Security** page of your WordPress site in hPanel.
## What's on the Security page
* **WordPress version** — the installed core version and whether it's current.
* **Smart auto-updates** — managed automatic updates for core, plugins, and themes (see below).
* **Updates log** — a history of updates that were applied.
* **Plugins and themes** — every installed plugin and theme with its update state, so outdated components are visible without logging into wp-admin.
* **PHP compatibility** — whether your site's PHP version suits the installed WordPress version. Change it under [PHP Configuration](/websites/php).
## Automatic updates
Two modes:
* **Smart auto-updates** (recommended) — Hostinger manages the update process.
* **Native auto-updates** — WordPress's built-in update behavior.
You control how much gets updated automatically:
| Level | What updates |
| ------------------------- | ------------------------------------ |
| **No updates** | Nothing — you update manually |
| **Security updates only** | Only security releases |
| **Minor updates only** | Minor and security releases |
| **All updates** | Everything, including major versions |
> **Tip:** Keep at least security updates on. Before allowing major updates automatically, test them on [Staging](/wordpress/staging) so breaking changes get caught before production sees them.
## Vulnerability protection
For dedicated WordPress vulnerability scanning and virtual patching, Hostinger partners with **Patchstack** — offered from the Security page.
Server-level protection is separate and always on: see [Malware Scanner](/websites/malware-scanner) for file-level malware detection on your hosting.
## Troubleshooting
**Auto-update broke my site** Roll back via [Backups](/websites/backups), or switch the offending component to manual updates until a fixed release is out.
***
*Last updated: July 22, 2026*
# Staging
Create a WordPress staging environment in Hostinger hPanel to test plugin, theme, and code changes safely, then push them to production when ready.
An isolated copy of your WordPress site for testing changes before they hit production — plugin updates, theme edits, content drafts, code tweaks.
> **Note:** Staging is available on WordPress sites and is plan-gated — entry-level plans see an upgrade prompt. Creating a staging environment can take up to 15 minutes, and WordPress multisite is not supported.
## Create a staging environment
1. Open your WordPress site in hPanel.
2. Click **Staging** in the left menu.
3. Click **Create staging**.
4. Name it (e.g., `staging-v2`).
5. Click **Create**.
Hostinger clones your files and database. The staging URL appears in the Staging panel (usually a subdomain like `staging-.`).
## Test your changes
Edit on staging freely — install plugins, update themes, try new content, run `wp-cli`. Production stays untouched.
## Push staging to production
> **Warning:** This overwrites your live site. [Create a backup](/websites/backups) of production first so you can roll back.
1. Go to **Staging**.
2. Click **Push to live** (or **Sync to production**).
3. Choose what to sync:
* **Files only** — site files, no database (themes, plugins, uploads)
* **Database only** — posts, settings, users; no files
* **Full sync** — both
4. Confirm.
## Pull production to staging
Refresh staging with a fresh copy of production data:
1. Go to **Staging**.
2. Click **Pull from live**.
3. Confirm.
Staging is overwritten with the current production state.
## Delete staging
1. Go to **Staging**.
2. Click **Delete** next to the environment.
3. Confirm.
Production is unaffected.
## SSL on staging
Staging gets its own SSL certificate automatically — no configuration needed.
## When to use it
* Major plugin or theme updates
* WordPress core version bumps
* Before enabling a new plugin on a live site
* Content rehearsal before a launch
* Testing PHP version changes
## Troubleshooting
**Staging URL is blank** Clear your browser cache; staging uses a different cookie path from production. If still blank, check [AI Troubleshooter](/wordpress/ai-troubleshooter) on the staging site.
**Push to live failed partway** Restore production from [Backups](/websites/backups). Staging remains intact for another attempt.
***
*Last updated: July 22, 2026*
# Copy Website
Learn how to duplicate a WordPress site into a new website slot in Hostinger hPanel, what gets copied, how it differs from staging, and post-copy steps.
Duplicate an existing WordPress site into a new website slot on your account. Useful for spinning up client projects from a template, building a second brand off a known-good setup, or creating a long-lived archive copy before a major overhaul.
## How it differs from Staging
| | Copy Website | [Staging](/wordpress/staging) |
| ----------- | ------------------------------------- | ----------------------------------------------- |
| Result | A separate, permanent website | A temporary environment tied to the source site |
| Lives where | A new website in your hosting account | Subdomain attached to the source site |
| Sync back | No — it's independent | Yes — push to live, pull from live |
| Use for | New projects, long-lived copies | Test changes before pushing |
## Copy a site
1. Open the source WordPress site in hPanel.
2. Click **Copy website** in the left menu.
3. Pick the destination:
* **New website slot** — creates a fresh website in your hosting account (plan limits apply)
* **Existing website** — overwrites another site you manage
4. Choose the domain or free subdomain for the copy.
5. Confirm.
Hostinger clones files and the database, updates `wp-config.php` to point at the new database, and rewrites URLs in the copied database to match the new domain.
## What's copied
* All files in `public_html` (themes, plugins, uploads, `wp-config.php`)
* The full database (posts, users, options, metadata)
* Active theme and plugin list
## What's not copied
* Domain DNS configuration (the copy gets its own domain)
* SSL certificates (a fresh one is issued for the new domain)
* Email accounts
* Cron jobs (you can recreate these under [Cron Jobs](/websites/cron-jobs))
* Server-level redirects defined outside WordPress
## After copying
* Log in to the copied site's `/wp-admin` — user credentials carry over.
* Re-check **General settings** → **Site URL** if you changed the domain.
* Regenerate permalinks (**Settings** → **Permalinks** → **Save**) if links 404.
## Troubleshooting
**URLs in posts still point at the source domain** Run a search-replace via [File Manager](/websites/file-manager) or `wp-cli`: `wp search-replace 'old-domain.com' 'new-domain.com'`.
**"Plan limit reached" when creating a new slot** You've hit the max websites on your plan. Delete an unused site, upgrade your plan, or pick **Existing website** as the destination.
***
*Last updated: July 21, 2026*
# AI Troubleshooter
Use Hostinger's AI Troubleshooter in hPanel to analyze your WordPress site, diagnose performance issues, and apply automatic one-click fixes.
Troubleshoot and automatically fix your website's performance issues with the help of AI — in one click. Find it under **Performance** → **AI Troubleshooter** in your website dashboard.
## What it does
The AI Troubleshooter analyzes your website, identifies what's slowing it down or causing problems, and applies fixes for you where it safely can. It also includes a **Performance Boost** flow focused on speeding the site up.
## Run it
1. Open your website dashboard in hPanel.
2. Go to **Performance** → **AI Troubleshooter**.
3. Start the analysis and review what it finds.
4. Apply the suggested fixes.
## When to use it
* The site has become noticeably slow
* PageSpeed scores dropped and you're not sure why
* After installing plugins or making changes that degraded performance
* As a periodic health check before a traffic-heavy event
## Related tools
* [PageSpeed](/websites/pagespeed) — measure Core Web Vitals and get recommendations
* [Cache](/websites/cache) and [CDN](/websites/cdn) — the usual first fixes for slow sites
* [Backups](/websites/backups) — restore a known-good state if a change broke the site
***
*Last updated: July 22, 2026*
# Node.js Hosting Overview
Overview of managed Node.js hosting on Hostinger: how deployments work, supported Node versions and frameworks, build sources, and entry file requirements.
Run Node.js apps directly on your hosting — full-stack apps, APIs. No separate server to manage.
> **Note:** In hPanel, Node.js apps appear as **Web Apps**. Both names refer to the same feature.
## How it works
1. **Get your code to Hostinger** — connect a GitHub repository so every push deploys automatically, upload an archive of your project, or deploy straight from your code editor with the [Hostinger Connector](/hostinger-connector/overview).
2. **Configure** Node version, root directory, build script, output directory.
3. **Build** — Hostinger installs dependencies and runs your build script.
4. **Run** — Hostinger starts your app and keeps it running at your domain.
If your app crashes, it's automatically restarted.
## Process handling
Node.js apps on Hostinger run on demand. After a period without incoming traffic, your app's process is stopped automatically to free up server resources. The next request — a visitor opening your site, an API call, anything — starts it again, and your app resumes serving traffic. The handover happens in the background; you don't need to configure or restart anything.
## Supported Node.js versions
| Version | Status |
| ------- | --------------- |
| 18 | Supported |
| 20 | Supported (LTS) |
| 22 | Supported (LTS) |
| 24 | Supported |
> **Tip:** Use an LTS version in production for the longest active support window.
## Supported frameworks
Next.js, Nuxt.js, Express.js, NestJS, Fastify, Hono, Nitro, React Router, Astro, SvelteKit, Gatsby, and more — split by frontend (static) vs backend (SSR). See [Supported Frameworks](/node.js/overview-1) for the full list and per-framework setup.
Hostinger auto-detects the framework from your `package.json` — whether you upload an archive or import a GitHub repository.
## Build sources
* **GitHub** — connect a GitHub repo and trigger builds on push. See [GitHub](/node.js/github).
* **Archive** — upload a `.zip`, `.tar`, `.tar.gz`, or `.tgz` and point the build at it.
* **Hostinger Connector** — deploy from VS Code, Cursor, or Claude Code with a prompt. See [Hostinger Connector](/hostinger-connector/overview).
## Entrypoint
Server apps need an **entry file** — the script Node runs to start your server, e.g. `server.js`. It must end in `.js`, `.mjs`, or `.cjs`. Depending on the framework, the path is relative to the root directory or to the output directory — see [Build Settings](/node.js/build-settings#entry-file).
Required for:
* **Backend frameworks** — Express.js, NestJS, Fastify, Hono
* **SSR / dual-mode frameworks when running in server mode** — Nuxt.js, Nitro, React Router, Astro, SvelteKit (with `adapter-node`)
Frontend-only frameworks (React, Create React App, Vue, Angular, Vite, Parcel, Preact, Svelte, Gatsby) serve their output directory directly and don't need an entry file. Same for the dual-mode frameworks above when configured for static output (`nuxt generate`, Astro's static default, SvelteKit with `adapter-static`). Next.js apps don't need one either — they always run in server mode, and Hostinger starts their standalone server for you.
## Next steps
* [Supported Frameworks](/node.js/overview-1)
* [Creating a Node.js App](/node.js/creating-an-app)
* [Build Settings](/node.js/build-settings)
* [Deployments](/node.js/deployments)
* [Environment Variables](/node.js/environment-variables)
* [API reference](/api-reference/endpoints/hosting/nodejs) — start Node.js builds programmatically
***
*Last updated: September 23, 2026*
# Creating a Node.js App
Step-by-step guide to deploying a Node.js app on Hostinger from a GitHub repository, uploaded archive, or code editor, with build settings and troubleshooting.
Deploy a Node.js app (a **Web App** in hPanel) from a GitHub repository, an uploaded archive, or straight from your code editor. Hostinger detects your framework, suggests build settings, runs the build, and keeps the process running.
## Requirements
* A plan that supports Node.js apps in the panel: **Business Web Hosting**, or **Cloud Startup / Professional / Enterprise / Enterprise Plus**. (VPS and dedicated plans run Node.js too, but require manual CLI setup — not the panel flow described here.) Each plan includes a set number of Web Apps — if you hit the limit, remove unused apps or upgrade.
* A Node.js project with a `package.json`. Supported runtimes: **Node.js 18, 20, 22, and 24**.
* The source: a GitHub repository (yours, or any public repo URL), or an archive of your project.
Hostinger auto-detects most popular frameworks: React, Create React App, Vue, Angular, Vite, Parcel, Preact, Next.js, Nuxt, Nitro, Astro, Svelte, SvelteKit, Gatsby, React Router, Express, NestJS, Fastify, Hono. Anything outside that list deploys as **Other** — you fill in build settings manually.
## Deploy from GitHub (recommended)
1. In hPanel, open **Websites** → **Add Website**.
2. Pick **Node.js web app**.
3. Choose **Import Git repository** and click **Connect with GitHub**. A popup asks you to install the Hostinger GitHub App and choose which repositories it can access. One GitHub account is connected at a time — switching accounts replaces the connection.
4. Pick the repo containing your app and click **Deploy**. Use the search box or **Refresh repositories** if a repo is missing.
5. Hostinger detects the framework and pre-fills the deploy settings — framework preset, branch, Node version, build command, output directory, entry file. Review and adjust if needed.
6. Click **Deploy**.
Subsequent updates: push to the connected branch and Hostinger triggers a rebuild automatically. See [GitHub deployments](/node.js/github) for connection management, redeploys, and webhook details.
### Deploy a public repository
Don't own the repo? Paste any **public GitHub repository URL** into the repository picker. Hostinger clones it into a new repository on **your** GitHub account — you pick the repository name and whether it's private (default) — then deploys from your copy. Future pushes to your copy auto-deploy as usual.
## Deploy by uploading an archive
1. Zip your project, omitting `node_modules` and `.git` to keep the archive small:
```bash
zip -r myapp.zip . --exclude "node_modules/*" --exclude ".git/*"
```
2. In hPanel, open **Websites** → **Add Website** → **Node.js web app**.
3. Choose **Upload your files**.
4. Upload your archive — `.zip`, `.tar`, `.tar.gz`, or `.tgz`, one project archive at a time.
5. Confirm or edit the auto-detected deploy settings.
6. Click **Deploy**.
> If the domain you're deploying under is already added to your hosting plan, remove that website first — the Node.js deploy flow expects to create a fresh slot for the domain.
## Deploy from your code editor
The onboarding flow also offers **Build with Hostinger Connector** — an MCP extension for VS Code, Cursor, and Claude Code. Type a prompt in your editor and the Connector deploys the app for you. See [Hostinger Connector](/hostinger-connector/overview).
## Deploy settings
When the framework can't be auto-detected, or you want to override the defaults, fill in:
| Field | What it is |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Framework preset** | Your framework, or **Other** for custom apps. |
| **Branch** | Git deploys only — the branch that triggers builds. Defaults to the repo's default branch. |
| **Node.js version** | 18, 20, 22 (default), or 24. Projects targeting anything older run on Node 18. |
| **Build command** | npm script Hostinger should run after install (e.g. `npm run build`), picked from your `package.json` scripts. |
| **Package manager** | npm (default), yarn, or pnpm — auto-detected from your lockfile. |
| **Output directory** | Folder containing build artifacts — common values: `dist`, `build`, `out`, `.next`. Required for static frontend apps. |
| **Entry file** | Server apps only — the script that starts your app, e.g. `server.js`. Must end in `.js`, `.mjs`, or `.cjs`. Relative to the root directory or the output directory, depending on the framework — see [Build Settings](/node.js/build-settings#entry-file). |
| **Environment variables** | Anything your app reads from `process.env` at build or runtime. See [Environment Variables](/node.js/environment-variables). |
If you're not sure what to put, check your project's `package.json` `scripts` block. Full field reference: [Build Settings](/node.js/build-settings).
## After deploy
Build artifacts land in:
* `~/domains/{domain}/hbuilds/current/nodejs` — server-side apps.
* `~/domains/{domain}/public_html` — frontend / static-output apps.
`current` is a symlink to the live build. Full layout, timestamps, and manual-edit rules: [File Structure](/node.js/file-structure).
Hostinger generates an `.htaccess` in `public_html` to route requests to your Node.js process. Redeploying regenerates it, so don't hand-edit.
For server-side apps (Express, Next.js, NestJS, …), click the **Running** badge in the dashboard to **Restart** the process. Static frontend apps don't expose Restart — there's nothing live to restart.
## Logs
* **Build logs** — deploy-time output, streamed live during a deploy. Find past builds under **Deployments**. See [Deployments](/node.js/deployments).
* **Runtime Logs** — what your running app prints to stdout/stderr. See [Runtime Logs](/node.js/runtime-logs).
If a build fails, Hostinger generates an AI analysis of the failure with a diagnosis and suggested fix — see [Deployments](/node.js/deployments#failed-builds).
## Connect a database
The Web App dashboard includes a guided **Connect a database** wizard — currently **Supabase** and **MongoDB Atlas**:
* **Supabase** — one-click connect via Supabase authorization (link an existing database or create a new one), or enter the **Project URL** and **Anon key** manually. Sets `SUPABASE_URL` and `SUPABASE_ANON_KEY`.
* **MongoDB Atlas** — paste your **Connection string**; the guide walks through allowlisting your hosting IP. Sets `MONGODB_URI`.
The wizard merges the variables into your app's [environment variables](/node.js/environment-variables), shows sample client code, and redeploys the app. Disconnecting removes the variables and redeploys.
## Vulnerability monitoring
Hostinger automatically scans the npm packages your app installs for known vulnerabilities after every deployment. For Git-connected apps, flagged packages can be fixed with an auto-generated GitHub pull request. See [Vulnerability Scanning](/node.js/vulnerabilities).
## Resource usage
The dashboard plots live CPU, RAM, and I/O against your plan's limits. If a metric is sitting near the red dotted line, optimize the app or move up a plan.
## Programmatic deploys
For CI/CD, skip the panel entirely:
1. Call the [Generate Upload URL](/api-reference/endpoints/hosting/files/generate-upload-url) endpoint to get a one-time URL.
2. `PUT` your archive to it.
3. Trigger a build via the [Start Node.js build](/api-reference/endpoints/hosting/nodejs/start-node-js-build) endpoint.
## Troubleshooting
**Build failed** Open the failed deployment under **Deployments** — the AI-generated analysis explains the failure with a diagnosis and solution, and offers **Fix and redeploy**. Otherwise, check the build logs: verify your `package.json` `scripts`, the declared output directory, and that your Node.js version matches what your dependencies need.
**Repository is missing a package.json** The Node.js flow needs a `package.json` at the app root. Add one, or use the **Deploy as static** option to serve the repo contents as a static site via [Git deployment](/websites/git).
**App not responding after a green build** For server apps, check Runtime Logs — a build can succeed while the process crashes on startup. Most common causes: missing env vars, or binding to the wrong port.
**403 after a redeploy** The `.htaccess` in `public_html` is stale or was hand-edited. Redeploy to regenerate it.
***
*Last updated: September 23, 2026*
# File Structure
Node.js app file structure on Hostinger — the hbuilds directory, build versions, the current symlink, and file timestamps.
## Directory layout
```
/home/{username}/domains/{domain}/
├── hbuilds/ ← Managed by deployments — do not edit
│ ├── source/ ← Working copy of your source while a build runs
│ ├── last-source/ ← Source of the last successful deployment
│ ├── config/ ← Environment variables, package.json and lockfile
│ ├── logs/ ← Build logs, one folder per deployment
│ ├── versions/
│ │ └── {build-id}/ ← The live build
│ │ ├── nodejs/ ← Server app files
│ │ └── public_html/ ← Static output of this build
│ └── current → versions/{build-id} ← Symlink to the live build
└── public_html/ ← Public docroot, synced from the live build
```
`source/` is removed after a successful deployment. `last-source/` is kept and reused when you redeploy an archive app with **Use previous files** — see [Deployments](/node.js/deployments#redeploy).
## Live files
| App type | Live location |
| ----------------------------------------- | ------------------------------------------- |
| Server apps (Express, NestJS, Next.js, …) | `~/domains/{domain}/hbuilds/current/nodejs` |
| Static output (frontend builds) | `~/domains/{domain}/public_html` |
`current` is a symlink. Each successful deployment creates a new `versions/{build-id}` folder and re-points `current` to it. Failed builds don't change it.
The live build is labeled **Current** on the [Deployments](/node.js/deployments) page.
### Apps deployed before `hbuilds`
Apps last deployed before `hbuilds/` was introduced may still run from `~/domains/{domain}/nodejs`, with build data in a hidden `.builds` folder. The next deployment moves the build data to `hbuilds/` and switches the app to `hbuilds/current/nodejs`.
## File timestamps
Archive extraction keeps the modification time stored inside the archive — **"Last modified" in File Manager shows when you edited the file, not when it was deployed.** Verify deployments on the [Deployments](/node.js/deployments) page, not by timestamps.
## Manual edits
> **Warning:** Files in `hbuilds/` and `public_html` are overwritten on every deployment. Direct edits via File Manager, FTP, or SSH are not supported — change your source and redeploy. Use [environment variables](/node.js/environment-variables) for configuration.
## Version retention
Only the live build is kept in `versions/` — older builds are removed after each successful deployment. To roll back, push the older code or upload the older archive.
***
*Last updated: September 23, 2026*
# GitHub
Connect a GitHub repository to Hostinger for automatic Node.js deployments on every push, covering the build pipeline, connection status, and troubleshooting.
Connect a GitHub repository and have Hostinger install dependencies, run your build script, and start (or restart) your Node.js app on every push.
> **Note:** This is a separate integration from the generic [Git](/websites/git) feature in the Websites section. This one runs the full Node.js build pipeline (install → build → start). The generic one just copies files into a directory. Use this one whenever your project needs `npm install` or a build step.
## What it does
On each connected push, Hostinger:
1. Pulls the latest code from GitHub
2. Runs `npm install` (or `yarn` / `pnpm`, auto-detected from lockfiles)
3. Runs your build script (if one is configured)
4. Starts or restarts your app
Build progress streams to the deployment details page in real time.
## Git deployment vs archive upload
| | Git deployment | [Archive upload](/node.js/creating-an-app) |
| ---------------------- | ----------------------------------------- | ------------------------------------------ |
| Trigger | Push to a branch | Manual upload or API |
| Source | GitHub repo | `.zip` / `.tar` / `.tar.gz` |
| Dependencies | Installed on Hostinger | Your choice (can ship `node_modules`) |
| Vulnerability auto-fix | [Pull requests](/node.js/vulnerabilities) | Manual |
| Best for | Ongoing projects | One-off deploys, external CI/CD |
## Requirements
* Active Hostinger hosting plan with a Node.js-capable website
* A GitHub repository with a Node.js project (`package.json` at the app root)
* A supported framework — see [Supported Frameworks](/node.js/overview-1) — or **Other** with manual build settings
## How the connection works
Hostinger connects through a **GitHub App** installed on your GitHub account. During installation you choose which repositories Hostinger can access — all of them, or a hand-picked list. You can change this later in GitHub under **Settings** → **Applications**.
* **One GitHub account** is connected at a time. **Switch GitHub account** replaces the connection — deployments from the previous account stop.
* Adding or removing repository access on GitHub syncs to hPanel automatically. Click **Refresh repositories** if a repo isn't showing.
## Connect a repository
1. Create the app via **Websites** → **Add Website** → **Node.js web app** → **Import Git repository** (see [Creating a Node.js App](/node.js/creating-an-app)).
2. Click **Connect with GitHub** and install the Hostinger GitHub App in the popup.
3. Pick a repository — private repos are marked with a lock icon. You can also paste a **public GitHub repository URL** to clone it into your own account and deploy the copy.
4. Confirm or adjust the auto-detected settings:
| Setting | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------- |
| **Framework preset** | Auto-detected from `package.json` |
| **Branch** | The branch that triggers deployments (defaults to the repo's default branch) |
| **Node.js version** | 18, 20, 22, or 24 |
| **Root directory** | Path to the app (repo root, or a subdirectory for monorepos — auto-detected) |
| **Build command** | npm script to run (e.g. `build`) |
| **Output directory** | Where built files land (e.g. `.next`, `dist`) |
| **Entry file** | For server apps (e.g. `server.js`) — path rules in [Build Settings](/node.js/build-settings#entry-file) |
5. Click **Deploy** to run the first build.
For per-framework defaults, see [Supported Frameworks](/node.js/overview-1).
## Automatic builds
Auto-deployment is enabled automatically when you deploy from Git. On every push:
1. You push to the connected branch.
2. GitHub sends a webhook to Hostinger.
3. Hostinger pulls the code at the pushed commit.
4. Dependencies install, build runs, app restarts.
5. Logs stream to **Deployments** → deployment details.
The dashboard shows an **Auto-deployment** chip when this is active. Only one deployment runs at a time per site; additional pushes queue up.
## Manual builds
Click **Redeploy** on the website dashboard or the **Deployments** page. Same pipeline, triggered by you — it reuses the saved settings and pulls the latest code from the connected branch.
## Connection status
The dashboard and Deployments page show the state of the GitHub link:
| Status | Meaning | Fix |
| -------------------------------------- | ----------------------------------------------------- | -------------------------------------------------- |
| **Connected with GitHub** | Auto-deployment active; links to the repo | — |
| **GitHub is not connected** | No installation on this account | Click **Connect GitHub** |
| **Different GitHub account connected** | The site's repo belongs to another account | Click **Switch account** |
| **Repository access missing** | The Hostinger app can no longer access this repo | Click **Manage access** and grant access on GitHub |
| App suspended | The Hostinger app is suspended in your GitHub account | Re-enable it on GitHub |
## Disconnecting
From the menu next to the connection status:
* **Disconnect from repository** — unlinks this site only. Your GitHub account stays connected; auto-deployments for this site stop.
* **Disconnect GitHub** — removes the whole installation. All sites connected to that GitHub account stop deploying; already-deployed sites stay live.
## Build logs and history
Every deployment is recorded with its branch, commit hash and message, author, timestamp, and status, plus the full build log. See [Deployments](/node.js/deployments). Logs are also available via the [API](/api-reference/endpoints/hosting/nodejs).
## Environment variables
Values set under **Environment variables** are injected into both build and runtime. They persist across deployments — no need to re-apply on every push. See [Environment Variables](/node.js/environment-variables).
## Monorepos
For apps that live in a repo subdirectory, Hostinger detects the **Root directory** (where the app's `package.json` lives) and builds from there — only that subdirectory is built. Deploy separate subdirectories as separate Hostinger Node.js apps.
## Branch strategy
* Deploy `main` for always-live workflows.
* Use `production` or `release/*` to batch changes and control what ships.
* For QA before merging, deploy a preview branch as a separate Node.js app on a free subdomain, then point the main site's branch at the release once it's verified.
## Vulnerability auto-fix pull requests
For Git-connected apps, Hostinger can open a pull request on your repository that bumps vulnerable npm packages. You review and merge — nothing goes live until you do. See [Vulnerability Scanning](/node.js/vulnerabilities).
## Troubleshooting
**Build fails during dependency install** Check the first error in the log. Common causes: missing native dependencies, peerDependencies conflicts, Node version mismatch with `engines` field. npm installs automatically retry with `--legacy-peer-deps` before failing.
**Build succeeds but site shows old version** Static/SSG output: clear browser cache and [Hostinger cache](/websites/cache). Server apps: verify the new process started in **Runtime Logs**.
**Deployments not triggering on push** Confirm the branch name matches the connected branch, and that the connection status shows **Connected with GitHub** — a revoked installation or repository access shows a warning state instead.
**"Could not access the repository" when deploying by URL** URL-based deploys work with public GitHub repositories only. For private repos, connect the owning account instead.
**Repository is empty** Push at least one commit with a `package.json` before importing.
**GitHub access revoked** Reconnect from the dashboard's GitHub status → **Connect GitHub**, or restore the Hostinger app's access in GitHub → **Settings** → **Applications**.
***
*Last updated: September 23, 2026*
# Build Settings
Reference for every Node.js build configuration option on Hostinger, covering Node version, framework, build script, output directory, entry file, and limits.
Every Node.js build configuration option, available in hPanel and the API.
## Node.js version
| Value | Description |
| ----- | -------------------------- |
| `18` | Node.js 18 |
| `20` | Node.js 20 (LTS) |
| `22` | Node.js 22 (LTS) — default |
| `24` | Node.js 24 |
Pick the version in your project's `engines` field in `package.json`, or the one you develop with. LTS recommended for production. Projects declaring a version older than 18 build on Node 18 instead.
## Application type
The framework. Helps Hostinger pick sensible defaults. Full list with per-framework setup: [Supported Frameworks](/node.js/overview-1).
| Value | Use for |
| ------------------ | --------------------------------------- |
| `next` | Next.js (always server mode) |
| `nuxt` | Nuxt.js (static or SSR) |
| `nitro` | Nitro |
| `astro` | Astro (static or SSR) |
| `svelte-kit` | SvelteKit (static or SSR) |
| `svelte` | Svelte |
| `react` | React + Vite |
| `create-react-app` | Create React App |
| `react-router` | React Router (framework mode) |
| `gatsby` | Gatsby |
| `vue` | Vue + Vite |
| `angular` | Angular |
| `vite` | Vite (framework-agnostic, incl. Preact) |
| `parcel` | Parcel |
| `express` | Express.js |
| `nest` | NestJS |
| `fastify` | Fastify |
| `hono` | Hono |
| `other` | Any other Node.js project |
| (auto-detect) | Detect from `package.json` |
## Root directory
Directory containing `package.json`, relative to the source root.
* Use `/` or leave empty if it's at the root.
* Use a subdirectory (`apps/web`) for monorepos — auto-detected on import; only that subdirectory is built.
## Build script
The npm script to run during the build phase (e.g., `build`). Matches a script in `package.json`:
```json
{
"scripts": {
"build": "next build"
}
}
```
Leave empty for apps without a build step.
## Output directory
Where built files land, relative to the root directory.
| Framework | Typical output |
| ------------------------------- | ------------------------------------------------- |
| Next.js | `.next` |
| Nuxt.js / Nitro | `.output` (SSR) or `dist` (generate) |
| Astro | `dist` |
| SvelteKit | `build` (adapter-node) or `dist` (adapter-static) |
| Svelte | `dist` |
| React / Vue / Preact (Vite) | `dist` |
| Create React App / React Router | `build` |
| Gatsby | `public` |
| Angular | `dist/` |
| Parcel | `dist` |
| NestJS | `dist` |
| Express / Fastify / Hono | — (leave empty) |
For server apps, this is the compiled server code. For static sites, the HTML/CSS/JS to serve.
Express, Fastify, and Hono deploy the whole root directory, including `node_modules`, so leave the output directory empty — hPanel doesn't show the field for these frameworks. With **Other** (`other`), the output directory is ignored when an entry file is set.
## Entry file
For server apps, the file Node runs to start your server. hPanel accepts files ending in `.js`, `.mjs`, or `.cjs`.
Where the path starts from depends on the framework:
| Framework | Entry file is relative to | Example |
| ------------------------------------------- | ------------------------- | --------------------------------- |
| Express, Fastify, Hono, React Router, Other | Root directory | `server.js`, `dist/server.js` |
| NestJS, Astro, SvelteKit, Nuxt.js, Nitro | Output directory | `main.js` (NestJS, output `dist`) |
| Next.js | — (ignored) | — |
Don't repeat the output directory in the entry file. For NestJS with output directory `dist`, enter `main.js` — `dist/main.js` points to `dist/dist/main.js`, which doesn't exist, and the build fails. Per-framework values: [Supported Frameworks](/node.js/overview-1).
Leave empty for static sites. For Astro, SvelteKit, Nuxt.js, Nitro, and React Router, an empty entry file deploys the build as a static site — no Node server runs.
## Package manager
| Value | Description |
| ------ | ----------- |
| `npm` | Default |
| `yarn` | Yarn |
| `pnpm` | pnpm |
Auto-detected from lockfiles (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`). Override if needed.
## Source type
| Value | Description |
| --------- | ------------------------- |
| `archive` | From an uploaded archive |
| `git` | From a connected Git repo |
## Archive path
When `source_type` is `archive`, path to the archive relative to `public_html`.
Supported: `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.gz`, `.7z`. (The hPanel uploader accepts `.zip`, `.tar`, `.tar.gz`, `.tgz`.)
Example: `myapp.zip` or `uploads/myproject.tar.gz`.
## Auto-detecting settings
Not sure what to fill in? Let Hostinger detect from your `package.json`.
* **hPanel:** settings are detected automatically when you import a repository or upload an archive; review them on the deploy settings screen.
* **API:** use the Get Build Settings from Archive / from Repository endpoints (see the [API reference](/api-reference/endpoints/hosting/nodejs)) — they return framework, Node version, output directory, and available scripts.
## Build limits
* One deployment runs at a time per site; additional builds queue (up to 20 pending).
* Dependency installation and the build script each have a **15-minute** time limit.
* Logs from the **last 10 builds** are kept.
## Build logs
Every build produces a log:
* Dependency installation
* Build script output
* Errors and warnings
* Success/failure status
View them under **Deployments** in hPanel (see [Deployments](/node.js/deployments)), or fetch them via the [API](/api-reference/endpoints/hosting/nodejs).
***
*Last updated: September 23, 2026*
# Deployments
How Hostinger records every Node.js build under Deployments in hPanel: history, per-build logs, redeploys, failed-build AI analysis, and deployment settings.
Every build of your Node.js app is recorded under **Deployments** in your website dashboard — history, per-build logs, redeploys, and the settings applied to future builds.
## Deployments list
The overview card shows where your app deploys from — **From pushes to** your connected repo (Git), or **Manually uploaded** (archive) — plus the GitHub connection status and a **Redeploy** button.
Below it, the deployment history table:
| Column | Git deploys | Archive deploys |
| ------ | ----------------------------------- | ----------------------------------- |
| Author | GitHub author with avatar | — |
| Branch | Deployed branch | — |
| Commit | Short hash + commit message | — |
| File | — | Archive filename |
| Time | When the build ran | When the build ran |
| Status | Building / Completed / Build failed | Building / Completed / Build failed |
The build currently serving traffic is labeled **Current**. The table is searchable and paginated. Click a row for full details.
## Deployment details
Each deployment's page shows:
* **State, time, and duration**
* **Source** — repository, branch, commit, and author (Git), or the uploaded file (archive)
* **Configuration** — root directory, framework, build and output settings (default or custom), Node version
* **Build logs** — the full log with line count; polls every few seconds while the build runs
## Redeploy
**Redeploy** opens **Deployment settings**, where **Save and redeploy** re-runs the build:
* **Git apps** — pulls the latest code from the connected branch. History shows it as a manual deployment (no new commit).
* **Archive apps** — with **Use previous files**, rebuilds from the source of the last successful deployment, kept in `hbuilds/last-source`. No re-upload needed. If your last upload failed to build, this rebuilds the older, successful source — to build a new archive, choose **Upload new files**.
Only one deployment runs at a time per site — buttons are disabled with "Another deployment is still running" until it finishes.
There is no per-commit rollback: to ship an older version, revert or reset in Git and push, or upload the older archive.
## Deployment settings
**Deployments** → **Deployment settings** edits the configuration applied to upcoming builds: framework preset, branch (Git), Node version, build command, package manager, output directory, entry file, and [environment variables](/node.js/environment-variables). Field reference: [Build Settings](/node.js/build-settings).
* **Git apps** — **Save** (applies on next push) or **Save and redeploy** (applies now).
* **Archive apps** — choose **Use previous files** or **Upload new files**, then **Save and redeploy**.
## Failed builds
When a build fails, the deployment is marked **Build failed** and Hostinger generates an **AI analysis** of the log — a diagnosis of what went wrong and a suggested solution — with a **Fix and redeploy** shortcut. Open it from the "Previous build failed. More details" link or the failed deployment's details page.
Common causes and fixes: [Creating a Node.js App — Troubleshooting](/node.js/creating-an-app#troubleshooting).
## On disk
Each deployment builds into a new `hbuilds/versions/{build-id}` folder and, on success, re-points the `hbuilds/current` symlink to it; static output is synced to `public_html`. See [File Structure](/node.js/file-structure) for the full layout and why file timestamps don't reflect deploy time.
## Related
* [File Structure](/node.js/file-structure) — where deployed files live
* [GitHub](/node.js/github) — automatic deployments on push
* [Build Settings](/node.js/build-settings) — every configuration field
* [Runtime Logs](/node.js/runtime-logs) — output from the running app, not the build
***
*Last updated: September 23, 2026*
# Environment Variables
How to set environment variables for Node.js apps on Hostinger: adding and importing .env values in hPanel, validation rules, and applying changes via redeploy.
Set the values your Node.js app reads from `process.env`. Variables are injected into **both the build and the running app**, and persist across deployments — set them once, not on every push.
## Where to manage them
* **During onboarding** — the deploy settings screen has a **Set environment variables** section.
* **After deploy** — open **Environment variables** in your website dashboard sidebar.
## Adding variables
Add variables one at a time with **Add environment variable**, or bulk-import with **Import .env** — upload a `.env` file and Hostinger parses it (comments are skipped, surrounding quotes stripped).
Validation rules:
| Rule | Limit |
| ----------------- | -------------------------------------------------------------------- |
| Key format | Uppercase letters, numbers, and underscores only (`A–Z`, `0–9`, `_`) |
| Key length | Up to 255 characters |
| Key uniqueness | Duplicate keys are rejected |
| Value length | Limited — extremely long values are rejected with an error |
| Variables per app | Up to 1,000 |
## Editing and deleting
Values are **masked** in the table — use the show/hide toggle to reveal one. Edit inline, or delete with confirmation.
Some variables are **system-managed** (created by Hostinger features, e.g. the database connect wizard) and marked with an explanatory tooltip; locked variables can't be edited.
## Applying changes
Changes are staged until you save — the page tracks an "Unsaved changes" count and warns if you navigate away. Saving **redeploys the application** so the new values take effect in both build and runtime.
## Notes
* Values are stored encrypted and written to a protected file on your hosting, readable only by your app.
* Don't commit secrets to your repository — set them here instead.
* Variables needed at **build time** (e.g. `NEXT_PUBLIC_*`, API URLs baked into a static bundle) must be set **before** the build that uses them.
## Related
* [Creating a Node.js App](/node.js/creating-an-app#connect-a-database) — the database wizard sets connection variables for you
* [Deployments](/node.js/deployments) — how redeploys work
***
*Last updated: July 22, 2026*
# Runtime Logs
Guide to Runtime Logs in hPanel, the live view of what your Node.js app on Hostinger prints to stdout and stderr, with filters, live mode, and export options.
Live view of what your Node.js app prints to **stdout** and **stderr** while it's running. Use it to debug crashes after a deploy, watch incoming traffic, and confirm env vars are loading.
Runtime Logs cover the running process only. For deploy-time output (npm install, your build script), see the build logs under [Deployments](/node.js/deployments) instead.
## Where to find it
In hPanel, open your website's dashboard and pick **Runtime Logs** in the sidebar. The viewer shows logs from your **latest deployment only** — every redeploy starts a fresh log buffer.
## What's in each entry
| Field | Notes |
| ------------- | ------------------------------------------------------------------------------------------------- |
| **Timestamp** | `HH:MM:SS` of when the line was emitted. |
| **Severity** | `INFO`, `LOG`, `WARN`, `ERROR`, `DEBUG`, or `TRACE`. Errors are highlighted red, warnings yellow. |
| **Message** | The line itself. Multi-line messages preserve their line breaks. |
The header above the viewer shows running counts of warnings and errors in the active window, plus the timestamp of the latest deployment so you can tell at a glance whether what you're looking at is from before or after a code change.
## Live mode vs refresh
The toolbar has a **Live** toggle.
* **Live on** — the panel polls for new lines every five seconds and appends them to the bottom. Best for watching a deploy come up or reproducing a bug interactively.
* **Live off** — click **Refresh** to fetch the current state on demand. Better when you're investigating a known issue and don't need a continuous stream.
## Filters
Three controls sit above the log viewer:
* **Time range** — last hour, last day, last week, or last month.
* **Severity** — multi-select checkboxes (`ERROR`, `WARN`, `LOG`, `DEBUG`, `INFO`, `TRACE`). Unchecked levels are hidden from view.
* **Search** — case-insensitive substring match across the message column.
All three apply instantly without refetching from the server, so it's safe to toggle them while live mode is on.
## Jump between issues
When the visible window contains two or more `WARN` or `ERROR` entries, the toolbar shows up/down arrows that jump the viewport between them. Useful for tracing a single bad deploy through a flood of harmless `INFO` lines.
## Volume graph
Above the viewer, a stacked bar graph plots how many entries were emitted per time bucket, split into neutral / warning / error counts. Bucket size scales with the time range — one-minute buckets for the last hour, larger buckets for longer ranges. Use it to spot bursts of errors that line up with traffic spikes.
## Download or copy
The three-dot menu on the toolbar exposes:
* **Download logs** — saves the currently visible logs as `{domain}-runtime-logs.txt`.
* **Copy to clipboard** — copies the visible message lines.
Both respect the active filters, so you can search and filter first, then export just the slice that matters.
## Log limit
The viewer holds up to **5,000 lines**. When your app exceeds that, a banner appears with two options: open **File Manager** to inspect the full log file on disk, or **Clear logs** to reset the buffer and keep streaming fresh entries.
## "No logs to show — Redeploy"
Apps that haven't been deployed (or redeployed) since Runtime Logs was enabled for the site won't have a log buffer yet. The panel surfaces a redeploy prompt in this state — push a new deploy and the buffer starts populating immediately.
## Troubleshooting
**Logs are empty during live mode** Confirm your app actually writes to `stdout` / `stderr`. Direct file logging (e.g. `winston` writing to a file) bypasses the runtime-log capture; switch the transport to console output to see it here.
**Static frontend app shows no logs** Static builds don't have a running Node.js process — there's no stdout to capture. Runtime Logs is for server apps (Express, Next.js, NestJS, Fastify, etc.).
**Live polling stops unexpectedly** Filter or time-range changes pause polling for a moment, then resume if Live mode is still on. If polling stays paused, toggle **Live** off and on again.
***
*Last updated: July 22, 2026*
# Vulnerability Scanning
How Hostinger scans your Node.js app's npm dependencies for known vulnerabilities and fixes them via auto-generated GitHub pull requests or manual patching.
Hostinger scans the npm packages your Node.js app installs against known-vulnerability advisories and flags anything that needs patching. Find it under **Security** → **Vulnerabilities** in your website dashboard.
## When scans run
* **After every deployment** — each successful build records your dependency tree and scans it.
* **Periodically** — deployed apps are re-scanned on a regular schedule, so new advisories surface even without a deploy.
An app that hasn't been deployed since the feature was enabled shows "Not scanned yet — your next deployment will trigger a scan."
## What you see
The **Unpatched dependencies** table lists each affected package with:
* Package name and installed version
* Whether it's a **direct** dependency (in your `package.json`) or **transitive** (pulled in by another package)
* The version that fixes the issue
* Advisory ID (CVE), CVSS score, severity, and publish date
Severity levels: **critical**, **high**, **moderate**, **low** (and **unknown** when no score is available). Filter by severity or search by package name or CVE. Expand a row for details.
## Email notifications
When new vulnerabilities are found in your app, Hostinger emails you. Unchanged findings aren't re-notified more than once a week.
## Fixing vulnerabilities
### Git-deployed apps: Auto-fix pull requests
If your app deploys from a [connected GitHub repository](/node.js/github), select the vulnerabilities to fix and click **Auto-fix**:
1. Hostinger creates a **pull request on your GitHub repository** that bumps the affected packages to patched versions.
2. You review and merge it yourself — **nothing goes live until you merge**.
3. Merging triggers the usual auto-deployment, and the next scan confirms the fix.
The PR includes a table of each package, its old and new version, and the advisory it addresses. After merging, run an install locally to refresh your lockfile if you work on the project elsewhere.
Auto-fix requires an active GitHub connection — if the button is disabled with "GitHub is not connected", reconnect first.
### Archive-deployed apps: manual patching
Update the flagged packages in your project (`npm update ` or bump the version in `package.json`), rebuild your archive, and redeploy via **Deployments** → **Deployment settings**.
## Related
* [GitHub](/node.js/github) — connecting a repository
* [Deployments](/node.js/deployments) — redeploying after a fix
***
*Last updated: July 22, 2026*
# Supported Frameworks
Overview of frontend, backend, and dual-mode Node.js frameworks supported on Hostinger, with links to per-framework build settings and app\_type values.
Your Node.js app must be built with one of the frameworks below. Pick the page for your framework to see `app_type`, build settings, and mode-specific configuration.
Hostinger auto-detects most frameworks from `package.json` — whether you import a GitHub repository or upload an archive. You can override the choice in hPanel or via the API.
## Frontend (static / client-rendered)
Builds to a directory of files; Hostinger serves them directly — no running server process.
* [Angular](/node.js/overview-1/angular)
* [Create React App](/node.js/overview-1/create-react-app)
* [Gatsby](/node.js/overview-1/gatsby)
* [Parcel](/node.js/overview-1/parcel)
* [Preact](/node.js/overview-1/preact)
* [React](/node.js/overview-1/react)
* [Svelte](/node.js/overview-1/svelte)
* [Vite](/node.js/overview-1/vite)
* [Vue.js](/node.js/overview-1/vue)
## Backend (server-rendered)
Keeps a long-lived Node.js process alive to handle requests — SSR, APIs, full-stack.
* [Express.js](/node.js/overview-1/express)
* [Fastify](/node.js/overview-1/fastify)
* [Hono](/node.js/overview-1/hono)
* [NestJS](/node.js/overview-1/nest)
* [Next.js](/node.js/overview-1/next)
## Dual-mode (static or server)
Support both, depending on your project configuration:
* [Astro](/node.js/overview-1/astro)
* [Nitro](/node.js/overview-1/nitro)
* [Nuxt.js](/node.js/overview-1/nuxt)
* [React Router](/node.js/overview-1/react-router)
* [SvelteKit](/node.js/overview-1/sveltekit)
## Not on the list?
Pick **Other** (`other`) as the application type. You provide the build script, output directory, and entry file — Hostinger runs them without framework-specific defaults. For a server app, set the entry file relative to the root directory; the output directory is then ignored and the whole root directory is deployed.
## Related
* [Creating a Node.js App](/node.js/creating-an-app) — step-by-step walkthrough
* [Build Settings](/node.js/build-settings) — every configuration field explained
* [API reference](/api-reference/endpoints/hosting/nodejs) — programmatic deployment
***
*Last updated: September 23, 2026*
# Angular
Deploy Angular apps on Hostinger Node.js hosting, covering static build settings, output directories, and Angular Universal SSR via the other app type.
Opinionated TypeScript framework with batteries included. Hostinger runs Angular as static bundles by default; Angular Universal (SSR) is also supported via the `other` application type.
**`app_type`:** `angular`
## Static mode
Default Angular mode — client-side rendering, routes hydrate in the browser.
### `package.json`
```json
{
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test"
}
}
```
### hPanel settings
| Field | Value |
| ---------------- | -------------------------------------------------------------------- |
| Application type | `angular` |
| Build script | `build` |
| Output directory | `dist/` or `dist//browser` (Angular 17+) |
| Entry file | — (static) |
> **Note:** Angular 17+ splits build output into `browser/` and `server/` subdirectories. Point the output directory at `browser/`. The project name comes from `angular.json` → `projects.`.
## Server mode (Angular Universal / SSR)
Angular Universal pre-renders and serves with a Node server.
### Enable SSR
```bash
ng add @angular/ssr
```
This adds `server.ts` and updates `angular.json` with a server build target.
### Build
```bash
ng build
```
### Application type
Use `other` — Hostinger's `angular` preset defaults to static output.
### hPanel settings
| Field | Value |
| ---------------- | --------------------------------------- |
| Application type | `other` |
| Build script | `build` |
| Output directory | — (leave blank) |
| Entry file | `dist//server/server.mjs` |
With `other`, the entry file is relative to the root directory and the output directory is ignored.
Angular's server adapter listens on `process.env.PORT` by default.
## Notes
* Node 20 or newer for Angular 17+.
* Build output locations change between major Angular versions; check `angular.json` → `architect.build.options.outputPath` to be sure.
***
*Last updated: September 23, 2026*
# Create React App
Deploy Create React App projects as static sites on Hostinger, covering build settings, output directory, routing fallback, and REACT\_APP\_ env variables.
Classic React tooling built on `react-scripts`. Builds to a static bundle that Hostinger serves directly — no server process.
**`app_type`:** `create-react-app`
> **Note:** Create React App is deprecated upstream. For new projects, prefer [React + Vite](/node.js/overview-1/react) — but existing CRA projects deploy fine.
## Static mode
CRA is static-only.
### `package.json`
```json
{
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build"
},
"dependencies": {
"react": "^18.3.0",
"react-dom": "^18.3.0",
"react-scripts": "5.0.1"
}
}
```
Hostinger detects CRA from the `react-scripts` dependency.
### hPanel settings
| Field | Value |
| ---------------- | ------------------ |
| Application type | `create-react-app` |
| Build script | `build` |
| Output directory | `build` |
| Entry file | — |
## Server mode
Not applicable. For SSR with React, use [Next.js](/node.js/overview-1/next) or [React Router](/node.js/overview-1/react-router).
## Notes
* Client-side routing (React Router in library mode) works out of the box — unknown paths fall back to `index.html`.
* Environment variables baked into the bundle must be prefixed `REACT_APP_` and set **before** the build. See [Environment Variables](/node.js/environment-variables).
***
*Last updated: July 22, 2026*
# Gatsby
Deploy Gatsby static sites on Hostinger, including build script and public output directory settings, redeploys for CMS data, and GATSBY\_ env variables.
React-based static site generator with a GraphQL data layer. Builds to static files that Hostinger serves directly — no server process.
**`app_type`:** `gatsby`
## Static mode
Gatsby deploys on Hostinger as a static site.
### `package.json`
```json
{
"scripts": {
"develop": "gatsby develop",
"build": "gatsby build",
"serve": "gatsby serve"
},
"dependencies": {
"gatsby": "^5.13.0",
"react": "^18.3.0",
"react-dom": "^18.3.0"
}
}
```
### hPanel settings
| Field | Value |
| ---------------- | -------- |
| Application type | `gatsby` |
| Build script | `build` |
| Output directory | `public` |
| Entry file | — |
## Server mode
Not supported — Gatsby's SSR/DSG page modes need Gatsby's own hosting adapters. Pages using `getServerData` or Deferred Static Generation won't work; keep pages statically generated.
## Notes
* The output directory is `public` (not `dist`).
* Data sourced at build time (CMS, APIs) is baked in — trigger a redeploy to refresh content.
* Environment variables read in `gatsby-config.js` or prefixed `GATSBY_` must be set **before** the build. See [Environment Variables](/node.js/environment-variables).
***
*Last updated: July 22, 2026*
# Parcel
Deploy Parcel-bundled static sites on Hostinger, covering the source entry HTML, build script, dist output directory, and multi-page app configuration.
Zero-config bundler. Point it at an HTML entry and it produces a production bundle.
**`app_type`:** `parcel`
## Static mode
Parcel on Hostinger is always static.
### `package.json`
```json
{
"source": "src/index.html",
"scripts": {
"start": "parcel",
"build": "parcel build"
},
"devDependencies": {
"parcel": "^2.0.0"
}
}
```
`"source"` tells Parcel where your entry HTML lives. Alternatively, pass the path as an argument to the script:
```json
{
"scripts": {
"build": "parcel build src/index.html"
}
}
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `parcel` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
Parcel builds static bundles only. For SSR, use a framework that includes a server (e.g. [Next.js](/node.js/overview-1/next)) or write a custom Node server and use `other` as the application type.
## Notes
* Parcel caches builds in `.parcel-cache/` — safe to keep out of your archive (it's regenerated).
* For multi-page apps, list additional entries in `"source"` as an array.
***
*Last updated: July 22, 2026*
# Preact
Deploy Preact apps as static Vite builds on Hostinger, using the vite application type, @preact/preset-vite setup, and hPanel settings for dist output.
React-compatible 3 kB alternative. Hostinger runs Preact apps as static bundles built with Vite — they deploy under the Vite application type.
**`app_type`:** `vite`
## Static mode
Preact on Hostinger is always static via Vite.
### `package.json`
```json
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": {
"vite": "^5.0.0",
"@preact/preset-vite": "^2.8.0"
}
}
```
### `vite.config.js`
```js
import { defineConfig } from 'vite';
import preact from '@preact/preset-vite';
export default defineConfig({
plugins: [preact()],
});
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `vite` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
Preact doesn't ship a built-in server runtime. For SSR, use the `other` application type and follow Preact's [SSR guide](https://preactjs.com/guide/v10/server-side-rendering/) to wire up Express or your own Node entry.
## Notes
* Scaffold a new project: `npm create preact` — picks sensible defaults including TypeScript support.
* Preact is API-compatible with React; you can use most React libraries via `preact/compat` aliases.
***
*Last updated: July 22, 2026*
# React
Deploy React apps as static Vite builds on Hostinger, with package.json scripts, hPanel build settings, and SSR alternatives like Next.js and Astro.
Component library for building user interfaces. Hostinger runs React apps as static bundles built with **Vite**.
**`app_type`:** `react`
> **Note:** Create React App (CRA) was archived by Meta in early 2024 and is no longer supported. Migrate to Vite or use Next.js/Remix for full-stack.
## Static mode
React on Hostinger is always static — Vite builds your app to a directory of files that's served directly.
### `package.json`
```json
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": {
"vite": "^5.0.0",
"@vitejs/plugin-react": "^4.0.0"
}
}
```
### `vite.config.js`
```js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
});
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `react` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
React itself doesn't ship a server runtime. For SSR, use one of:
* [Next.js](/node.js/overview-1/next) — recommended for SSR and full-stack React
* [Astro](/node.js/overview-1/astro) — content-first sites with React components
## Notes
* Scaffold a new project: `npm create vite@latest my-app -- --template react`
* For TypeScript: `--template react-ts`
* For routing, use React Router or Tanstack Router (both work unchanged on Hostinger since routing is client-side).
***
*Last updated: July 21, 2026*
# Svelte
Deploy standalone Svelte apps as static Vite builds on Hostinger, with plugin setup, hPanel build settings, and SvelteKit pointers for SSR needs.
Compile-time framework with no virtual DOM. Hostinger runs standalone Svelte apps as static bundles built with Vite.
**`app_type`:** `svelte`
> **Tip:** If you want routing, server-side rendering, form actions, or API routes, use [SvelteKit](/node.js/overview-1/sveltekit) instead.
## Static mode
Standalone Svelte on Hostinger is always static — Vite bundles your components into a directory of files.
### `package.json`
```json
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": {
"vite": "^5.0.0",
"@sveltejs/vite-plugin-svelte": "^3.0.0"
}
}
```
### `vite.config.js`
```js
import { defineConfig } from 'vite';
import { svelte } from '@sveltejs/vite-plugin-svelte';
export default defineConfig({
plugins: [svelte()],
});
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `svelte` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
Standalone Svelte doesn't have a server runtime. For SSR, use [SvelteKit](/node.js/overview-1/sveltekit) with `adapter-node`.
## Notes
* Scaffold a new project: `npm create vite@latest my-app -- --template svelte`
* For TypeScript: `--template svelte-ts`
***
*Last updated: July 21, 2026*
# Vite
Deploy framework-agnostic Vite projects as static sites on Hostinger, covering hPanel build settings, the dist output directory, and SSR alternatives.
Framework-agnostic bundler and dev server. Use this application type when your Vite project doesn't match a more specific framework (vanilla JS/TS, Lit, Solid, Qwik, etc.).
**`app_type`:** `vite`
## Static mode
Vite on Hostinger is always static.
### `package.json`
```json
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": {
"vite": "^5.0.0"
}
}
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `vite` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
Vite's dev server is for development only. For SSR, use a framework that builds on Vite — [Next.js](/node.js/overview-1/next), [Nuxt.js](/node.js/overview-1/nuxt), [Astro](/node.js/overview-1/astro), [SvelteKit](/node.js/overview-1/sveltekit) — or write a custom Node server and use `other` as the application type.
## Notes
* Scaffold any Vite template: `npm create vite@latest`. Pick from React, Vue, Svelte, Preact, Lit, Solid, Qwik, or Vanilla.
* If your template matches a specific `app_type` (e.g. `react`, `vue`), prefer that — Hostinger picks better defaults.
***
*Last updated: July 22, 2026*
# Vue.js
Deploy Vue.js apps as static Vite builds on Hostinger, with plugin setup, hPanel build settings, and Nuxt.js recommendations for SSR projects.
Progressive JavaScript framework for building UIs. Hostinger runs Vue apps as static bundles built with **Vite**.
**`app_type`:** `vue`
> **Note:** Vue CLI is end-of-life. Use Vite for new projects and migrate existing Vue CLI apps — the Vue team recommends this officially.
## Static mode
Vue on Hostinger is always static — Vite builds the app to a directory served directly.
### `package.json`
```json
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": {
"vite": "^5.0.0",
"@vitejs/plugin-vue": "^5.0.0"
}
}
```
### `vite.config.js`
```js
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
export default defineConfig({
plugins: [vue()],
});
```
### hPanel settings
| Field | Value |
| ---------------- | ---------- |
| Application type | `vue` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — (static) |
## Server mode
Vue itself doesn't ship an SSR runtime. For SSR, use:
* [Nuxt.js](/node.js/overview-1/nuxt) — recommended for SSR and full-stack Vue
* [Astro](/node.js/overview-1/astro) — content-first sites that can embed Vue components
## Notes
* Scaffold a new project: `npm create vue@latest`
* For TypeScript, pick "Add TypeScript" during scaffolding.
* Vue Router works unchanged — routing is client-side.
***
*Last updated: July 21, 2026*
# Astro
Deploy Astro sites on Hostinger in static or SSR mode, including Node adapter setup, hPanel build settings, and per-page hybrid rendering options.
Content-first framework that ships zero JavaScript by default. Hostinger supports both static and server modes.
**`app_type`:** `astro`
## `package.json`
```json
{
"scripts": {
"dev": "astro dev",
"build": "astro build",
"preview": "astro preview"
}
}
```
## Static
Default Astro mode — pre-renders every page at build time.
**hPanel settings:**
| Field | Value |
| ---------------- | ------- |
| Application type | `astro` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | — |
Use when your content is known at build time (blogs, docs, marketing sites).
## Server (SSR)
Runs a Node server that renders pages on each request. Required for dynamic routes, API endpoints, or server-only environment access.
Install the Node adapter:
```bash
npx astro add node
```
Configure `astro.config.mjs`:
```js
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
export default defineConfig({
output: 'server',
adapter: node({ mode: 'standalone' }),
});
```
**hPanel settings:**
| Field | Value |
| ---------------- | ------------------ |
| Application type | `astro` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | `server/entry.mjs` |
The entry file is relative to the output directory — enter `server/entry.mjs`, not `dist/server/entry.mjs`. Hostinger doesn't pre-fill it for Astro; if you leave it empty, the build deploys as a static site and no Node server runs.
## Hybrid rendering
Astro supports per-page opt-in/opt-out of pre-rendering:
```astro
---
// src/pages/dynamic.astro
export const prerender = false; // server-rendered
---
```
```astro
---
// src/pages/static.astro
export const prerender = true; // pre-rendered at build
---
```
Deploy as server mode — Astro handles each page individually based on the `prerender` flag.
## Notes
* Node 20 or newer for Astro 4+.
* For static deployments, no entry file is needed.
* Bind to `process.env.PORT` if using a custom server adapter.
***
*Last updated: September 23, 2026*
# Next.js
Deploy Next.js on Hostinger in server mode, covering hPanel build settings, the standalone output Hostinger applies for you, next.config requirements, and ISR support.
React framework with SSR, static export, API routes, and full-stack capability. Hostinger runs Next.js apps in server mode: every deployment is built with Next's standalone output, and Hostinger starts the bundled server for you.
**`app_type`:** `next`
## Server mode
Pages render on each request, and API routes, Server Actions, and middleware execute at runtime.
### `package.json`
```json
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start"
}
}
```
### hPanel settings
| Field | Value |
| ---------------- | ---------------------- |
| Application type | `next` |
| Build script | `build` |
| Output directory | `.next` |
| Entry file | — (ignored for `next`) |
Keep the output directory as `.next` — that's where Next writes the standalone server Hostinger starts.
### Standalone output
Hostinger applies `output: "standalone"` to your project before the build, so you don't need to set it yourself:
* With a `next.config.js`, `next.config.mjs`, `next.config.ts`, or `next.config.mts` in your project, your file is preserved and imported by a generated config that adds the standalone output. If more than one exists, the first match in that order is used.
* With no Next config at all, Hostinger creates a `next.config.mjs`.
* Any `output` value you set is replaced, including `output: 'export'`.
Standalone builds bundle a minimal copy of `node_modules` into `.next/standalone/`, so the server starts faster and the deployment is smaller.
> **Export a config object, not a function.** `export default { ... }` and `module.exports = { ... }` are merged correctly. A function config (`export default (phase) => ({ ... })`) is not — your settings and the standalone output are both lost, and the deployment fails with *Next.js build produced no standalone server or static output*.
**TypeScript configs are fully supported** — `next.config.ts` is not skipped or converted. The generated config that wraps yours is itself a TypeScript file, and Next.js loads both with its built-in TypeScript config support. Because that support arrived in Next.js 15, a TypeScript config on Next.js 14 or older is ignored by the framework: the standalone setting is lost and the deployment fails with *Next.js build produced no standalone server or static output*. On older Next.js versions, use `next.config.js` or `next.config.mjs` instead. `next.config.mts` is stricter still: it only works on Next.js 16 running on a Node.js version with built-in TypeScript support.
**Unsupported config filenames are silently ignored.** If your config uses any other filename — most commonly `next.config.cjs` — the deployment does not fail. Hostinger creates a default `next.config.mjs` and the build continues with default settings, so everything in your file is ignored without any warning in the build logs. (`next.config.cjs` is never read by Next.js itself either.) Rename the file to one of the four supported names before deploying.
## Static mode
Not applicable. Because Hostinger always builds `next` apps with standalone output, `output: 'export'` in your Next config has no effect and no `out/` directory is produced.
To host a Next.js site as static files, build the export on your machine and upload the generated `out/` directory to `public_html` with [File Manager](/websites/file-manager) instead of deploying it as a Node.js app.
## Notes
* Node 20 or newer required.
* ISR (Incremental Static Regeneration) and on-demand revalidation work out of the box.
* Image optimization works out of the box — no custom loader needed.
***
*Last updated: September 11, 2026*
# Nitro
Run standalone Nitro apps on Hostinger using the node-server preset, with hPanel build settings, .output entry file path, and static pre-rendering options.
Universal server toolkit (the engine behind Nuxt). Hostinger runs Nitro apps in server mode using the Node.js server preset.
**`app_type`:** `nitro`
## Server mode
### `package.json`
```json
{
"scripts": {
"dev": "nitro dev",
"build": "nitro build"
},
"dependencies": {
"nitropack": "^2.10.0"
}
}
```
Build with the default `node-server` preset (or set it explicitly):
```ts
// nitro.config.ts
export default defineNitroConfig({
preset: 'node-server',
});
```
### hPanel settings
| Field | Value |
| ---------------- | ------------------ |
| Application type | `nitro` |
| Build script | `build` |
| Output directory | `.output` |
| Entry file | `server/index.mjs` |
The entry file path is relative to the output directory contents — Nitro's Node build always produces `.output/server/index.mjs`.
## Static mode
Pre-render your routes (`nitro build --preset static` or `prerender` config) and deploy the generated `public` output as a static site — no entry file needed.
## Notes
* Nuxt projects should use the [Nuxt](/node.js/overview-1/nuxt) application type instead; `nitro` is for standalone Nitro apps.
* Apps exported from AI site builders that produce a Vite + Nitro setup are configured to the Node server preset automatically during the build.
* Listen port is provided via `process.env.PORT` — Nitro's Node preset respects it automatically.
***
*Last updated: July 22, 2026*
# Nuxt.js
Deploy Nuxt.js on Hostinger in static generation or SSR mode, with hPanel build settings, .output entry file, and hybrid rendering via routeRules.
Vue framework with SSR, static generation, and universal rendering. Hostinger supports both static and server modes.
**`app_type`:** `nuxt`
## `package.json`
```json
{
"scripts": {
"dev": "nuxt dev",
"build": "nuxt build",
"generate": "nuxt generate",
"preview": "nuxt preview"
}
}
```
## Static generation
Pre-renders every route at build time. No server code runs at request time.
Run `nuxt generate` instead of `nuxt build`:
**hPanel settings:**
| Field | Value |
| ---------------- | ---------- |
| Application type | `nuxt` |
| Build script | `generate` |
| Output directory | `dist` |
| Entry file | — |
Use when your data is known at build time and you want zero-cost hosting.
## SSR / universal
Default Nuxt mode. Runs a Node server that renders pages on each request.
**hPanel settings:**
| Field | Value |
| ---------------- | ------------------ |
| Application type | `nuxt` |
| Build script | `build` |
| Output directory | `.output` |
| Entry file | `server/index.mjs` |
The entry file is relative to the output directory — enter `server/index.mjs`, not `.output/server/index.mjs`.
Use when pages depend on per-request data, user sessions, or server APIs.
## Hybrid rendering
Nuxt 3 supports per-route rendering rules via `routeRules` in `nuxt.config.ts`:
```ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true }, // static at build
'/blog/**': { isr: 3600 }, // ISR, 1 hour
'/admin/**': { ssr: false }, // client-only SPA
'/api/**': { cors: true }, // API routes
},
});
```
Deploy as SSR (`build` + `.output`) — Nuxt handles the per-route mode internally.
## Notes
* Set `NITRO_PORT` or `PORT` env var if you need a specific port; Hostinger assigns one automatically.
* Node 20 or newer required.
***
*Last updated: September 23, 2026*
# React Router
Deploy React Router framework mode apps on Hostinger in server mode with the Express adapter, covering server.js setup and hPanel build settings.
React Router in **framework mode** (the successor to Remix) — file-based routing, loaders/actions, and SSR. Hostinger runs it in server mode with the Express adapter.
**`app_type`:** `react-router`
> Using React Router as a client-side routing **library** inside a React/Vite app? That's just a [React](/node.js/overview-1/react) deployment — this page is for framework mode.
## Server mode
Hostinger detects a React Router app from `react-router` + **`@react-router/express`** in dependencies.
### `package.json`
```json
{
"scripts": {
"build": "react-router build",
"dev": "react-router dev",
"start": "node server.js"
},
"dependencies": {
"react-router": "^7.1.0",
"@react-router/express": "^7.1.0",
"@react-router/node": "^7.1.0",
"express": "^4.21.0"
}
}
```
### Minimal `server.js`
```js
import { createRequestHandler } from '@react-router/express';
import express from 'express';
const app = express();
app.use(express.static('build/client'));
app.all(
'*',
createRequestHandler({
build: await import('./build/server/index.js'),
})
);
app.listen(process.env.PORT ?? 3000);
```
### hPanel settings
| Field | Value |
| ---------------- | -------------- |
| Application type | `react-router` |
| Build script | `build` |
| Output directory | `build` |
| Entry file | `server.js` |
An entry file is **required**.
## Static mode
For a fully static site, disable SSR (`ssr: false` in `react-router.config.ts`) and deploy `build/client` as the output directory — or use plain [React + Vite](/node.js/overview-1/react).
## Notes
* Listen on `process.env.PORT` — don't hard-code a port.
* Loaders and actions run on the server; put secrets in [environment variables](/node.js/environment-variables), not client code.
***
*Last updated: July 22, 2026*
# SvelteKit
Deploy SvelteKit on Hostinger in static or server mode using adapter-static or adapter-node, with hPanel settings and per-route prerendering tips.
Full-stack Svelte framework with adapters for different deployment targets. Hostinger supports both static and server modes via adapters.
**`app_type`:** `svelte-kit`
## `package.json`
```json
{
"scripts": {
"dev": "vite dev",
"build": "vite build",
"preview": "vite preview"
}
}
```
## Static (adapter-static)
For fully pre-rendered sites with no server code.
Install the adapter:
```bash
npm install -D @sveltejs/adapter-static
```
Configure `svelte.config.js`:
```js
import adapter from '@sveltejs/adapter-static';
export default {
kit: {
adapter: adapter({ fallback: 'index.html' }),
},
};
```
**hPanel settings:**
| Field | Value |
| ---------------- | ------------ |
| Application type | `svelte-kit` |
| Build script | `build` |
| Output directory | `build` |
| Entry file | — |
> **Note:** adapter-static requires either full pre-rendering (`export const prerender = true` in your root layout) or a SPA fallback (`fallback: 'index.html'`).
## Server (adapter-node)
Runs a Node server that renders pages on each request and handles form actions, load functions with fetch, etc.
Install the adapter:
```bash
npm install -D @sveltejs/adapter-node
```
Configure `svelte.config.js`:
```js
import adapter from '@sveltejs/adapter-node';
export default {
kit: { adapter: adapter() },
};
```
**hPanel settings:**
| Field | Value |
| ---------------- | ------------ |
| Application type | `svelte-kit` |
| Build script | `build` |
| Output directory | `build` |
| Entry file | `index.js` |
The entry file is relative to the output directory — enter `index.js`, not `build/index.js`. If you leave it empty, the build deploys as a static site and no Node server runs.
## Per-route prerendering
Mix static and server rendering by setting `prerender` per-route:
```ts
// src/routes/about/+page.ts
export const prerender = true; // static
// src/routes/dashboard/+page.ts
export const prerender = false; // server
```
Deploy as `adapter-node` — SvelteKit pre-renders the marked routes at build and serves the rest on demand.
## Notes
* Node 20 or newer.
* Default adapter is `adapter-auto` which picks based on the host; replace it with `adapter-static` or `adapter-node` for explicit control on Hostinger.
***
*Last updated: September 23, 2026*
# Express.js
Run Express.js apps in server mode on Hostinger Node.js hosting, with package.json setup, hPanel settings for JavaScript and TypeScript, and PORT binding.
Minimal, unopinionated Node.js HTTP framework. Hostinger runs Express apps in server mode — a long-lived Node process handles every request.
**`app_type`:** `express`
## Server mode
Express is server-only; there's no static mode.
### `package.json`
```json
{
"scripts": {
"start": "node server.js",
"dev": "node --watch server.js"
},
"dependencies": {
"express": "^4.21.0"
}
}
```
For TypeScript:
```json
{
"scripts": {
"build": "tsc",
"start": "node dist/server.js"
}
}
```
### Minimal `server.js`
```js
import express from 'express';
const app = express();
const port = process.env.PORT ?? 3000;
app.get('/', (_req, res) => res.send('Hello from Express'));
app.listen(port, () => {
console.log(`Listening on ${port}`);
});
```
### hPanel settings
**Plain JavaScript:**
| Field | Value |
| ---------------- | --------------- |
| Application type | `express` |
| Build script | — (leave blank) |
| Output directory | — (leave blank) |
| Entry file | `server.js` |
**TypeScript:**
| Field | Value |
| ---------------- | ------------------------------------------- |
| Application type | `express` |
| Build script | `build` — detected from your `package.json` |
| Output directory | — (leave blank) |
| Entry file | `dist/server.js` |
hPanel doesn't show the build script or output directory fields for Express. The `build` script from your `package.json` still runs, and the whole root directory is deployed, so the entry file is relative to the root directory — `dist/server.js`.
## Static mode
Not applicable. If you want to serve static assets alongside Express, use `express.static('public')` inside your server.
## Notes
* **Bind to `process.env.PORT`, not a hardcoded port.** Hostinger assigns a port at runtime; hardcoding causes conflicts.
* For production, enable gzip and security headers:
```js
import compression from 'compression';
import helmet from 'helmet';
app.use(compression());
app.use(helmet());
```
* Process auto-restart: if your app crashes, Hostinger restarts it.
***
*Last updated: September 23, 2026*
# Fastify
Run Fastify apps in server mode on Hostinger Node.js hosting, covering hPanel build settings, 0.0.0.0 host binding, PORT configuration, and logging tips.
High-performance Node.js HTTP framework. Lower overhead than Express, schema-based validation out of the box. Hostinger runs Fastify apps in server mode.
**`app_type`:** `fastify`
## Server mode
Fastify is server-only.
### `package.json`
```json
{
"scripts": {
"start": "node server.js",
"dev": "node --watch server.js"
},
"dependencies": {
"fastify": "^4.28.0"
}
}
```
For TypeScript:
```json
{
"scripts": {
"build": "tsc",
"start": "node dist/server.js"
}
}
```
### Minimal `server.js`
```js
import Fastify from 'fastify';
const fastify = Fastify({ logger: true });
fastify.get('/', async () => ({ hello: 'world' }));
const start = async () => {
try {
await fastify.listen({
port: process.env.PORT ?? 3000,
host: '0.0.0.0',
});
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();
```
### hPanel settings
**Plain JavaScript:**
| Field | Value |
| ---------------- | --------------- |
| Application type | `fastify` |
| Build script | — (leave blank) |
| Output directory | — (leave blank) |
| Entry file | `server.js` |
**TypeScript:**
| Field | Value |
| ---------------- | ------------------------------------------- |
| Application type | `fastify` |
| Build script | `build` — detected from your `package.json` |
| Output directory | — (leave blank) |
| Entry file | `dist/server.js` |
hPanel doesn't show the build script or output directory fields for Fastify. The `build` script from your `package.json` still runs, and the whole root directory is deployed, so the entry file is relative to the root directory — `dist/server.js`.
## Static mode
Not applicable. To serve static files, use `@fastify/static`:
```js
import fastifyStatic from '@fastify/static';
fastify.register(fastifyStatic, { root: path.join(__dirname, 'public') });
```
## Notes
* **Listen on `0.0.0.0` and `process.env.PORT`** — Fastify's default host is `127.0.0.1`, which isn't reachable from outside the container.
* Use Fastify's built-in logger (`logger: true`) so request logs show up in Hostinger's build/runtime logs.
***
*Last updated: September 23, 2026*
# Hono
Run Hono apps on Hostinger Node.js hosting using the @hono/node-server adapter, with package.json setup, hPanel build settings, and PORT configuration.
Small, fast web framework built on Web Standards. On Hostinger, Hono runs in server mode via the Node.js adapter.
**`app_type`:** `hono`
## Server mode
Hono is server-only on Hostinger. The project must use **`@hono/node-server`** — that's how Hostinger detects a Hono app (`hono` + `@hono/node-server` in dependencies).
### `package.json`
```json
{
"scripts": {
"build": "tsc",
"start": "node dist/index.js"
},
"dependencies": {
"hono": "^4.6.0",
"@hono/node-server": "^1.13.0"
}
}
```
### Minimal `src/index.ts`
```ts
import { serve } from '@hono/node-server';
import { Hono } from 'hono';
const app = new Hono();
app.get('/', (c) => c.text('Hello from Hostinger!'));
serve({
fetch: app.fetch,
port: Number(process.env.PORT ?? 3000),
});
```
### hPanel settings
| Field | Value |
| ---------------- | ------------------------------------------- |
| Application type | `hono` |
| Build script | `build` — detected from your `package.json` |
| Output directory | — (leave blank) |
| Entry file | `dist/index.js` |
An entry file is **required** for Hono apps. hPanel doesn't show the build script or output directory fields for Hono. The `build` script from your `package.json` still runs, and the whole root directory is deployed, so the entry file is relative to the root directory — `dist/index.js`.
## Static mode
Not applicable. Serve static assets from your Hono app with `serveStatic` from `@hono/node-server/serve-static`.
## Notes
* Listen on `process.env.PORT` — don't hard-code a port.
* Deploying to Cloudflare Workers, Deno, or Bun targets won't run here; use the Node.js adapter entry shown above.
***
*Last updated: September 23, 2026*
# NestJS
Run NestJS apps in server mode on Hostinger Node.js hosting, with nest build script, dist output, main.ts PORT binding, and static file serving notes.
Progressive TypeScript framework built on top of Express (or Fastify). Opinionated, uses decorators and dependency injection. Hostinger runs Nest apps in server mode.
**`app_type`:** `nest`
## Server mode
NestJS is server-only.
### `package.json`
```json
{
"scripts": {
"build": "nest build",
"start": "nest start",
"start:prod": "node dist/main"
},
"dependencies": {
"@nestjs/core": "^10.0.0",
"@nestjs/common": "^10.0.0",
"@nestjs/platform-express": "^10.0.0"
}
}
```
### `src/main.ts`
Make sure your bootstrap listens on `process.env.PORT`:
```ts
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(process.env.PORT ?? 3000);
}
bootstrap();
```
### hPanel settings
| Field | Value |
| ---------------- | --------- |
| Application type | `nest` |
| Build script | `build` |
| Output directory | `dist` |
| Entry file | `main.js` |
The entry file is relative to the output directory — enter `main.js`, not `dist/main.js`.
## Static mode
Not applicable. Nest can serve static files via `ServeStaticModule`:
```ts
import { ServeStaticModule } from '@nestjs/serve-static';
import { join } from 'path';
@Module({
imports: [
ServeStaticModule.forRoot({
rootPath: join(__dirname, '..', 'public'),
}),
],
})
export class AppModule {}
```
## Notes
* **Bind to `process.env.PORT`.** Don't hardcode a port number.
* For Fastify as the underlying HTTP adapter, use [Fastify](/node.js/overview-1/fastify)'s notes too — switch via `NestFactory.create(AppModule, new FastifyAdapter())`.
* TypeScript config (`tsconfig.json`) should emit to `dist/`, so the compiled bootstrap lands at `dist/main.js`.
***
*Last updated: September 23, 2026*
# Agency Hosting Overview
Overview of Hostinger Agency Hosting plans for freelancers and agencies, covering cloning, access sharing, staging, WordPress add-ons, and the Partner Program.
Hostinger's Agency plans are built for freelancers, developers, and agencies running many client sites from a single account: higher resource limits than regular Web Hosting, more websites per plan, and tooling for building and handing off client sites.
Three tiers are available — **Agency Startup**, **Agency Professional**, and **Agency Growth**. For current resource limits and pricing, see [hostinger.com/pro](https://www.hostinger.com/pro) — the published plan matrix is the source of truth and changes over time.
## What Agency plans add
* **One dashboard for all sites** — manage every client site from a single hPanel account.
* **Website cloning at scale** — the Add Website flow includes **Clone websites**, which clones sites from this or another hosting plan. Useful for spinning up client projects from a template setup. See [Website Cloning](/agency-hosting/cloning).
* **Access sharing** — grant collaborators access to your account, or request access to a client's account, without sharing passwords. See [Access Sharing](/agency-hosting/access-sharing).
* **Staging** — test changes on a copy of a WordPress site before pushing live. Staging is plan-gated; Agency-level plans include it. See [Staging](/wordpress/staging).
* **Migrations** — submit migration requests from hPanel and Hostinger's migration team performs the transfer. See [Migrate Website](/websites/migrate-website).
## WordPress Add-ons
Agencies building on WordPress can add the **WordPress Add-ons** bundle (free trial available), which includes:
* **WordPress presets** — auto-install your choice of plugins and templates on new sites. See [Presets](/wordpress/presets).
* **Automated site reports** — recurring reports for client sites, branded with your logo and colors.
* **Website monitoring** — email alerts when a site goes offline.
* **1-click ownership transfers** — hand a finished site over to the client's own Hostinger account.
## Partner Program
The **Agency hub** in hPanel hosts Hostinger's Partner Program for web professionals: recurring commissions on referred plans, a discount on your own Agency plan, and a listing in the Agency Directory that sends client leads your way.
## Related guides
* [Access Sharing](/agency-hosting/access-sharing)
* [Website Cloning](/agency-hosting/cloning)
* [Staging](/wordpress/staging)
* [Migrate Website](/websites/migrate-website)
***
*Last updated: July 22, 2026*
# Access Sharing
Share hPanel access with Admin or Collaborator roles, grant or request access to client Hostinger accounts, and revoke it without sharing passwords.
Share access to your Hostinger account — or get access to a client's — without exchanging passwords. Managed from **Profile** → **Account sharing** in hPanel.
## Roles
When you grant someone access to your account, you pick their role:
| Role | What they can do |
| ---------------- | ----------------------------------------------------------------- |
| **Admin** | Manage services and make purchases using the added payment method |
| **Collaborator** | Manage services — can't make purchases |
## Grant access
Give a developer, designer, or teammate access to manage services on your account:
1. In hPanel, go to **Profile** → **Account sharing**.
2. Choose **Grant access**.
3. Enter the recipient's email — they need a Hostinger account, or they'll be prompted to create one.
4. Pick the role (**Admin** or **Collaborator**).
5. Send the invite. The recipient accepts, and your account appears in their hPanel.
Website onboarding also offers a **Grant developer access** step, so a client can hand a new site to their developer during setup.
## Request access
Working on a client's hosting? Instead of asking for their password, request access:
1. Go to **Profile** → **Account sharing** → **Request access**.
2. Enter the client's account email.
3. The client approves the request from their account, choosing your role.
You then manage their services from your own hPanel login — with your own credentials and 2FA.
## Revoke access
Either side can end the arrangement at any time from **Account sharing** — the owner removes the person's access, or the invitee leaves the account. Revocation doesn't delete any work done on the sites; only the access goes away.
## Handing a site over entirely
Access sharing shares management of *your* account. To permanently transfer a finished site to the client's own account, use **1-click ownership transfers** from the WordPress Add-ons bundle — see [Agency Hosting Overview](/agency-hosting/overview#wordpress-add-ons). For moving a site to a different host, see [Migrate Website](/websites/migrate-website).
## Notes
* Sharing access never transfers ownership of the plan or its billing.
* Recipients act under their role's limits, enforced by hPanel — Collaborators can't make purchases.
* Prefer granting access over sharing passwords: it's auditable, scoped, and revocable, and your client keeps their own 2FA.
***
*Last updated: July 22, 2026*
# Website Cloning
Clone a website's files and database into a new independent site on Hostinger Agency Hosting, and learn when to use cloning versus staging in hPanel.
Duplicate a website — files and database — into a new, independent site. Available on **Agency Hosting**.
## When to use cloning
* Start a new project from an existing site as a template
* Create a dev copy while the original stays live
* Duplicate a client site for consistent setups
* Rebuild a site without touching the original
## Clone a website
1. In hPanel, go to **Websites** → **Add Website**.
2. Choose **Clone websites** — clone sites from this or another hosting plan.
3. Pick the source site and the domain for the new site.
4. Confirm.
Copy time depends on site size — usually a few minutes.
## After cloning
The clone is fully independent. You can:
* Point it at a different domain
* Edit files and content without affecting the original
* Configure its own SSL, cache, CDN
For WordPress sources, WordPress is copied over and `siteurl`/`home` are updated to the clone's domain automatically.
## Cloning vs. staging
| | Clone | Staging |
| ---------------------- | ---------------------- | ---------------------- |
| **Independence** | Fully independent | Linked to production |
| **Sync with original** | No | Yes (push/pull) |
| **Use case** | New site from template | Test before going live |
| **Domain** | Own domain | Preview/subdomain URL |
Use **cloning** for a new, separate copy. Use **staging** to test changes and push them back to production.
***
*Last updated: July 22, 2026*
# Account Overview
Manage your Hostinger account from hPanel, including profile settings, subscriptions and billing, payment methods, account sharing, and developer tools.
Manage subscriptions, billing, and account settings from hPanel.
## Account profile
In **hPanel** → **Profile** (top right):
* Update name, email, and contact info
* Change your password
* Manage 2FA
* Set language and timezone
## Hosting plans and subscriptions
In **hPanel** → **Billing** or **My subscriptions**:
* View active plans and renewal dates
* Upgrade or downgrade
* Cancel renewals
## Payment methods
In **Billing**:
* Add or remove cards and PayPal
* Set a default payment method
* Download invoices
## Account sharing
Invite people (e.g., clients) to your hPanel with specific permissions.
In **Profile** → **Account sharing**:
* Invite users by email
* Assign access levels
## Developer tools
* **API tokens** — generate tokens for the [Public API](/api-reference/overview) on the **API** page ([hpanel.hostinger.com/api](https://hpanel.hostinger.com/api)).
* **MCP / IDE connectors** — the same page includes setup for connecting AI assistants and code editors. See [Hostinger Connector](/hostinger-connector/overview).
## Related guides
* [Security & Access](/account/security)
* [API Reference](/api-reference/overview)
***
*Last updated: July 22, 2026*
# Security & Access
Secure your Hostinger account with password changes, two-factor authentication, backup codes, API token management, and account activity review in hPanel.
Password, 2FA, SSH keys, API tokens, and active sessions.
## Password
1. Go to **Profile** in hPanel.
2. Click **Change Password**.
3. Enter your current and new password.
4. Confirm.
> **Tip:** Use a password manager and pick something long and unique.
## Two-factor authentication (2FA)
Requires both your password and a one-time code. Two methods:
* **Authenticator app** — scan a QR code with Google Authenticator or a compatible app; enter codes from the app at login.
* **Email code** — receive a one-time code by email at login.
### Enable
1. Go to **Profile** → **Security**.
2. Enable two-factor authentication and pick the method.
3. Confirm with a code, then save the **backup codes** generated during setup.
### Backup codes
One-time codes for when you lose access to your authenticator or email.
> **Warning:** Lose both your 2FA method and backup codes and account recovery requires manual intervention. Store backup codes somewhere safe (password manager, offline vault).
### New device protection
A separate toggle under **Profile** → **Security** that asks for extra verification when a sign-in looks risky (e.g., a new device). Changing it requires confirming your password.
### Disable
1. **Profile** → **Security**.
2. Disable two-factor authentication.
3. Confirm with your current 2FA code.
## SSH keys
See [FTP & SSH Access](/websites/ftp-ssh).
## API tokens
API tokens give programmatic access via the [Public API](/api-reference/overview).
### Create
1. Open the **API** page in hPanel ([hpanel.hostinger.com/api](https://hpanel.hostinger.com/api)).
2. Click **Generate new token**.
3. Name it.
4. Copy the token — it's shown only once.
The same page includes MCP configuration for connecting AI assistants and code editors — see [Hostinger Connector](/hostinger-connector/overview).
> **Warning:** Treat API tokens like passwords. Never commit them to Git.
### Revoke
Delete the token from the same **API** page. Revoked tokens stop working immediately.
## Account activity
1. Go to **Profile** → **Account activity**.
2. Review recent sign-ins and the devices used.
3. If anything looks unfamiliar, change your password — that logs you out of all devices except the current one. You can also log out of any device from the list.
## Troubleshooting
**Unfamiliar login or unexpected changes** Change your password (this logs out all other devices), enable 2FA and New device protection, and rotate any API tokens you've issued.
**Password-reset email you didn't request** Change your password immediately — someone may be probing your account.
***
*Last updated: July 22, 2026*
# Overview
Overview of Hostinger Connector, the official code editor extension that lets AI assistants deploy and manage Hostinger websites, domains, DNS, and VPS via MCP.
**Hostinger Connector** is an official Hostinger extension for your code editor that lets you deploy, monitor, and manage Hostinger services without leaving your code. It connects your AI assistant (such as GitHub Copilot, Cursor, or Windsurf) directly to your Hostinger account, so you can manage websites, domains, VPS, and more using natural-language prompts.
Instead of switching to hPanel, you can simply ask your assistant:
* *"Deploy my Node.js app to Hostinger"*
* *"List all my Hostinger domains"*
* *"Add a DNS record pointing blog.mydomain.com to my server"*
* *"Show the build logs for my latest deployment"*
## What you can do
Once connected, your AI assistant gets access to 372 Hostinger tools across these product areas:
| Product area | Tools | Capabilities |
| ---------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------- |
| **VPS** | 63 | Start, stop, and restart virtual machines; manage firewalls, SSH keys, snapshots, and metrics |
| **Websites** | 58 | Deploy static sites and Node.js apps; list deployments; view build logs; manage databases, cron jobs, and caching |
| **Email Marketing** | 49 | Manage contacts, groups, segments, campaigns, and forms in [Hostinger Reach](/reach/overview) |
| **Domains** | 40 | Search and register domains, manage forwarding, domain lock, WHOIS profiles, and verification |
| **Agency Hosting** | 38 | Provision Agency Plan websites, deploy PHP and Node.js apps, manage PHP versions and extensions |
| **Mailboxes** | 38 | Create mailboxes, manage aliases, forwarders, catch-alls, autoreplies, webhooks, and logs |
| **WordPress** | 38 | Install WordPress, plugins, and themes; manage posts, pages, users, menus, and WooCommerce |
| **Ecommerce** | 29 | Manage stores, products, variants, orders, discounts, and sales channels |
| **Subscriptions & Payments** | 9 | View subscriptions, manage auto-renewal, list payment methods, create orders |
| **DNS** | 8 | Create, update, and delete DNS records; take and restore DNS snapshots |
| **Horizons** | 2 | Create a Horizons website from a prompt and check its status |
## Supported editors and tools
Hostinger Connector works with:
| Editor / tool | AI assistant |
| ------------------------------ | -------------- |
| **Visual Studio Code** (1.99+) | GitHub Copilot |
| **Cursor** | Cursor AI |
| **Windsurf** | Cascade |
| **Devin Desktop** | Devin |
| **Antigravity** | Google Gemini |
| **Claude Code** (CLI) | Claude |
| **OpenAI Codex** (CLI) | Codex |
| **Gemini CLI** | Google Gemini |
The extension is installed once in your editor and automatically configures the AI tools you have available, including the Claude Code and Codex command-line tools.
Any other MCP-compatible client can reach the same tools in one of two ways:
* **Hosted remote server** at `https://mcp.hostinger.com`, which signs you in with OAuth 2.1 — nothing to install and no token to manage.
* **Local server** via the [`@hostinger/mcp`](https://www.npmjs.com/package/@hostinger/mcp) npm package, run as `npx -y @hostinger/mcp` over stdio.
The npm package also ships one server per product area — `hostinger-mail-mcp`, `hostinger-vps-mcp`, `hostinger-reach-mcp`, and so on — so a client can load a single product's tools instead of all 372.
See [Manual Configuration](/hostinger-connector/manual-configuration) for the config files, authentication, and where an API token is written.
## How it works
Hostinger Connector is built on the **Model Context Protocol (MCP)** — an open standard that lets AI assistants securely call external tools.
1. You install the extension and connect your Hostinger account (one-click browser sign-in or an API token).
2. The extension registers Hostinger's official MCP servers with your AI assistant.
3. When you ask your assistant to do something with Hostinger, it calls the appropriate tool. The tool talks to the [Hostinger API](/api-reference/overview) using your credentials and returns the result to your chat.
You stay in control: you choose which Hostinger product areas your assistant can access, and your assistant asks for confirmation before running tools (depending on your editor's settings).
The MCP servers always fetch the latest Hostinger API definition on startup, so new Hostinger features become available to your assistant automatically — no extension update needed.
## Security
* **OAuth sign-in (recommended)** uses OAuth 2.1 through your browser. No password ever passes through the editor.
* **API tokens** are stored in your editor's encrypted secret storage. They are also written into the MCP configuration the extension manages, which is how the MCP server receives them — see [Manual Configuration](/hostinger-connector/manual-configuration#where-your-api-token-ends-up).
* All API communication happens over HTTPS directly between your machine and Hostinger.
* You can disconnect at any time with the **Hostinger: Disconnect** command, which removes all stored credentials and configuration.
## Next steps
* [Installation & Setup](/hostinger-connector/installation-and-setup) — Install the extension and connect your account
* [Using the Connector](/hostinger-connector/using-the-connector) — Enable products, example prompts, and command reference
* [Troubleshooting](/hostinger-connector/troubleshooting) — Fix common issues
***
*Last updated: September 8, 2026*
# Installation & Setup
Guide to installing the Hostinger Connector extension in VS Code, Cursor, or other editors and connecting your Hostinger account via OAuth or an API token.
This guide walks through installing the Hostinger Connector extension and connecting it to your Hostinger account.
## Prerequisites
* A [supported editor](/hostinger-connector/overview#supported-editors-and-tools) — Visual Studio Code 1.99+, Cursor, Windsurf, Devin Desktop, or Antigravity
* **Node.js 18 or later** installed on your machine (the Connector can install it for you — see below)
* A Hostinger account
## Step 1: Install the extension
1. Open the **Extensions** panel in your editor (`Ctrl+Shift+X` / `Cmd+Shift+X`).
2. Search for **"Hostinger Connector"**.
3. Click **Install**.
After installation, a **Hostinger** icon appears in the Activity Bar (the vertical bar on the side of your editor).
## Step 2: Check Node.js
The Hostinger Connector runs Hostinger's MCP servers using Node.js, so Node.js 18+ is required. The sidebar shows your Node.js status automatically:
* **Node.js X.Y.Z ✓** — you're ready to connect.
* **Node.js Required** (red banner) — Node.js is missing or older than 18. Click **Install** (or **Update**) in the banner and the Connector installs it for you using your system's package manager (Homebrew on macOS, winget or Chocolatey on Windows, apt/dnf/pacman on Linux). The sidebar updates automatically once installation finishes — no restart needed.
If automatic installation isn't possible, the Connector opens the [Node.js download page](https://nodejs.org) so you can install it manually. After a manual install, restart your editor.
## Step 3: Connect your Hostinger account
There are two ways to connect. OAuth sign-in is recommended for most users.
### Option A: One-click sign-in (recommended)
1. Click the **Hostinger** icon in the Activity Bar.
2. Click **1-Click Connect**.
3. Your browser opens the Hostinger sign-in page. Log in and approve the connection.
4. Return to your editor — the sidebar status turns green: **Connected** (via OAuth).
Sign-in must be completed within 3 minutes. If the browser doesn't open automatically, the sign-in link is printed in the editor's terminal so you can open it manually.
### Option B: API token (advanced)
Use an API token if you prefer explicit credentials, or if you're connecting in an environment where a browser sign-in isn't possible.
1. In [hPanel](https://hpanel.hostinger.com/api), go to the **API** page and click **Generate new token**. Copy the token.
2. In the Hostinger sidebar, expand **Advanced: Connect with API token**.
3. Paste your token and click **Connect with API token**.
Alternatively, open the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`) and run **Hostinger: Set API Token (Optional)**.
Your token is stored in the editor's encrypted secret storage. Only one connection method can be active at a time — setting a token while signed in with OAuth signs you out of OAuth first.
## Step 4: Restart if needed
* **Visual Studio Code:** tools become available immediately (reload the window if you don't see them).
* **Cursor, Windsurf, Devin Desktop, Antigravity:** fully quit and reopen the editor once after connecting, so it picks up the new MCP configuration.
## Step 5: Try it out
Open your AI assistant's chat and ask something like:
> List my Hostinger websites
If the assistant responds with your websites, you're all set. See [Using the Connector](/hostinger-connector/using-the-connector) for more examples and configuration options.
## Disconnecting
To disconnect your account, either:
* Click **Disconnect** in the Hostinger sidebar, or
* Run **Hostinger: Disconnect** from the Command Palette.
This signs you out, deletes stored credentials, and removes the Hostinger MCP configuration from all managed editors and tools.
> **Tip:** If you plan to uninstall the extension, disconnect first. Uninstalling without disconnecting can leave stale MCP configuration entries behind.
***
*Last updated: July 21, 2026*
# Using the Connector
How to use Hostinger Connector in your editor: enabling product groups, example AI prompts, how deployments work, commands, and where credentials are stored.
Once [installed and connected](/hostinger-connector/installation-and-setup), Hostinger Connector works through your AI assistant. This page covers choosing which products your assistant can access, how to use it in each editor, example prompts, and the full command reference.
## Choosing what your assistant can access
The Hostinger sidebar lists the available product groups with a checkbox for each. Only the products you enable are exposed to your AI assistant.
| Product group | Enabled by default | What it covers |
| ---------------------------- | ------------------ | ----------------------------------------------------------------------------------- |
| **Websites** | Yes | Deployments (static, Node.js, WordPress), build logs, caching, databases, cron jobs |
| **Domains** | Yes | Domain registration and management, plus DNS records and snapshots |
| **Subscriptions & Payments** | Yes | Subscriptions, auto-renewal, payment methods |
| **Email Marketing** | Yes | [Hostinger Reach](/reach/overview) contacts, groups, and segments |
| **Ecommerce** | No | Stores, products, sales channels |
| **VPS** | No | Virtual machines, firewalls, SSH keys, snapshots, metrics |
Each product card shows a short description and the number of tools it provides. Toggle a checkbox and the change applies to your assistant right away (fork-based editors like Cursor may need a restart to pick it up).
Enabling only what you need keeps your assistant's tool list focused and reduces what it can act on.
> **Note:** Product selections reset to the defaults when you disconnect.
## Using it in your editor
| Editor | How to use |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **VS Code (Copilot)** | Open Copilot Chat, click the **Tools** button, and make sure Hostinger tools are enabled. Then prompt normally. |
| **Cursor** | Open chat (`Cmd+L` / `Ctrl+L`). Hostinger tools are available to the agent automatically. |
| **Windsurf** | Open Cascade. Hostinger tools appear in its tool list. |
| **Claude Code / Codex (CLI)** | The Connector writes their configuration automatically when you connect. Just run the CLI and prompt. |
## Example prompts
**Websites & deployments**
* "Deploy this project to Hostinger as a static site"
* "Deploy my Node.js app to Hostinger"
* "Show the build logs for my latest deployment"
* "List all my websites and their status"
* "Clear the cache for mydomain.com"
**Domains & DNS**
* "Is mydomain.dev available? If so, how much does it cost?"
* "List all my Hostinger domains"
* "Add an A record for blog.mydomain.com pointing to 203.0.113.10"
* "Take a snapshot of my DNS zone before I make changes"
**VPS** (enable the VPS product first)
* "Show CPU and memory usage for my VPS"
* "Restart my VPS"
* "Add a firewall rule allowing port 8080"
**Billing**
* "Which of my subscriptions renew this month?"
* "Turn off auto-renewal for my VPS plan"
## How deployments work
Deployments are performed by your AI assistant calling Hostinger tools — there is no separate deploy button. Supported project types:
* **Static websites** — HTML/CSS/JS, or the built output of frameworks like React, Vue, or Astro. Deploys pre-built files only — no build step runs.
* **Node.js applications** — Express, Next.js, NestJS, and other Node.js apps. The uploaded archive is capped at **50 MB** and should exclude `node_modules` and build output — the build runs on Hostinger.
* **WordPress** — sites, plugins, and themes. Site imports take an archive plus a `.sql` dump and can run for several minutes.
When you ask your assistant to deploy, it selects the right tool, uploads your project through the Hostinger API, and reports the result — including build logs if a build is involved. For details on what happens on the hosting side, see [Node.js Hosting](/node.js/overview) and [Git](/websites/git).
## Command reference
All commands are available from the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`):
| Command | Description |
| --------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Hostinger: Set API Token (Optional)** | Connect using an API token instead of OAuth sign-in |
| **Hostinger: Disconnect** | Sign out, delete stored credentials, and remove all Hostinger MCP configuration |
| **Hostinger: Refresh** | Refresh the sidebar status (also available as the refresh icon in the sidebar title bar) |
The extension adds no editor settings — everything is managed from the Hostinger sidebar.
## Where credentials are stored
* **OAuth:** tokens are stored by the Hostinger MCP server in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or `%APPDATA%\hostinger-mcp\credentials.json` (Windows). Nothing is written into your editor's MCP configuration.
* **API token:** stored in your editor's encrypted secret storage, and also written as `HOSTINGER_API_TOKEN` into the MCP configuration of every editor the Connector manages — that's how the MCP server receives it. Treat those config files as secrets.
Disconnecting removes both. See [Manual Configuration](/hostinger-connector/manual-configuration) for the file formats and what the entries look like.
***
*Last updated: August 21, 2026*
# Manual Configuration
Configure Hostinger's MCP server by hand for clients the Connector extension doesn't manage — the hosted remote server, the local npm package, where your API token is written, and how to load a single
[Hostinger Connector](/hostinger-connector/overview) configures your editor for you. Configure MCP by hand when your client isn't one the extension manages, or when you're running in CI, a container, or a script.
There are two ways to reach the same tools.
## Option A: Hosted remote server
Nothing to install and no token to manage — you sign in with OAuth 2.1 in the browser.
```json
{
"mcpServers": {
"hostinger": {
"url": "https://mcp.hostinger.com"
}
}
}
```
This is the better choice for most clients. Use the local server instead if your client can't reach a remote MCP endpoint, or if you need an API token rather than an interactive sign-in.
## Option B: Local server
Runs [`@hostinger/mcp`](https://www.npmjs.com/package/@hostinger/mcp) on your machine over standard I/O. Requires **Node.js 20 or later**.
```json
{
"mcpServers": {
"hostinger": {
"command": "npx",
"args": ["-y", "@hostinger/mcp"],
"env": {}
}
}
}
```
Leaving `env` empty is deliberate. With no token set, the server opens a browser and signs you in the first time your assistant calls a Hostinger tool. To use a token instead, put it in `env`:
```json
{
"mcpServers": {
"hostinger": {
"command": "npx",
"args": ["-y", "@hostinger/mcp"],
"env": {
"HOSTINGER_API_TOKEN": "YOUR_API_TOKEN"
}
}
}
}
```
Restart your client after editing its config file.
## Where your API token ends up
Worth knowing whichever route you take, because it isn't obvious.
**If you connect the Connector extension with an API token,** the extension writes that token into the MCP configuration of every editor it manages — the same `HOSTINGER_API_TOKEN` field shown above. You never paste it into a config file yourself, but it does end up there. The token lives in your editor's encrypted secret storage *and* in plain text in those config files, because that's how the MCP server receives it at startup.
**If you connect with browser sign-in,** no token is written anywhere. The configuration contains no credentials at all, and OAuth tokens are kept in a separate credentials file (see below).
Two things follow from that:
* Treat any MCP config file containing `HOSTINGER_API_TOKEN` as a secret. Don't commit it, and strip the token before pasting the file into an issue or a support chat.
* **Hostinger: Disconnect** removes those entries along with the stored credentials. Disconnect before uninstalling the extension — uninstalling on its own can leave the token behind in a stale entry.
Tokens carry the permissions of the account that created them and can be set to expire. Generate and revoke them on the [API page in hPanel](https://hpanel.hostinger.com/profile/api); see [Security & Access](/account/security).
## Authentication
The two methods are not equal: **an API token always wins**. When `HOSTINGER_API_TOKEN` is set, no OAuth code runs at all.
Without a token, the local server uses OAuth 2.0 with PKCE on the first authenticated tool call. Expired tokens refresh on their own; if a refresh token is revoked, the browser flow relaunches. Credentials are stored outside your client's config:
* **macOS / Linux:** `~/.config/hostinger-mcp/credentials.json` (permissions `0600`)
* **Windows:** `%APPDATA%\hostinger-mcp\credentials.json`
They're shared across every Hostinger MCP binary, so signing in once covers all of them. Run the flow up front, or clear it:
```bash
npx -y @hostinger/mcp --login
npx -y @hostinger/mcp --logout
```
> Browser sign-in doesn't work over HTTP transport. Anything started with `--http` must set `HOSTINGER_API_TOKEN`.
## Loading one product instead of all 372 tools
The package ships a server per product area as well as the combined one. Pointing your client at a narrower binary gives your assistant a shorter tool list, which keeps it focused and cheaper to run:
| Binary | Covers |
| ------------------------------ | -------------------------------------------------------- |
| `hostinger-hosting-mcp` | Websites, databases, files, cron jobs, PHP, Node.js |
| `hostinger-agency-hosting-mcp` | Agency plan websites, orders, and metrics |
| `hostinger-wordpress-mcp` | Installations, plugins, themes, caching, maintenance |
| `hostinger-domains-mcp` | Availability, registration, transfers, WHOIS, forwarding |
| `hostinger-dns-mcp` | Zones, records, snapshots |
| `hostinger-mail-mcp` | Mailboxes, aliases, forwarders, autoreplies, webhooks |
| `hostinger-vps-mcp` | Virtual machines, firewalls, snapshots, SSH keys, Docker |
| `hostinger-ecommerce-mcp` | Stores, products, orders, shipping, payments |
| `hostinger-reach-mcp` | Contacts, segments, tags, campaigns, automations |
| `hostinger-horizons-mcp` | Horizons websites |
| `hostinger-billing-mcp` | Catalog, orders, subscriptions, payment methods |
Select one with `--package`:
```json
{
"mcpServers": {
"hostinger-vps": {
"command": "npx",
"args": ["-y", "--package=@hostinger/mcp", "hostinger-vps-mcp"],
"env": {}
}
}
}
```
You can register several at once under different keys.
## Environment variables
| Variable | Purpose |
| --------------------- | --------------------------------------------------------------------------------------------- |
| `HOSTINGER_API_TOKEN` | API token, sent as a bearer header. When set, OAuth is bypassed entirely. |
| `DEBUG` | Enable debug logging (`true` / `false`). Defaults to `false`. |
| `OAUTH_ISSUER` | OAuth server base URL. Defaults to `https://auth.hostinger.com`. Ignored when a token is set. |
| `API_TOKEN` | Deprecated alias for `HOSTINGER_API_TOKEN`. Prefer the prefixed name. |
## Related
* [Installation & Setup](/hostinger-connector/installation-and-setup) — the managed path, for supported editors
* [Using the Connector](/hostinger-connector/using-the-connector) — product groups, prompts, and commands
* [Troubleshooting](/hostinger-connector/troubleshooting) — fixing common issues
* [API Reference](/api-reference/overview) — the API behind these tools
***
*Last updated: September 2, 2026*
# Troubleshooting
Solutions to common Hostinger Connector issues: Node.js requirements, OAuth sign-in failures, missing tools in your AI assistant, and clean uninstall steps.
Solutions to the most common issues with Hostinger Connector.
## Connection issues
**The Connect button is disabled**
The Connector requires Node.js 18 or later. Check the Node.js status in the Hostinger sidebar:
* **"Node.js not detected"** or **"needs 18+"** — click **Install** / **Update** in the red banner, or install Node.js 18+ manually from [nodejs.org](https://nodejs.org) and restart your editor.
* **"npx not found"** — your Node.js installation is incomplete. Reinstall Node.js from the official installer, which includes npx.
**OAuth sign-in fails or times out**
* The sign-in must be completed within 3 minutes. Click **1-Click Connect** and try again.
* If the browser doesn't open, look for the sign-in link printed in the editor's terminal and open it manually.
* On Windows, the sign-in runs in a terminal window named **"Hostinger OAuth"**. Don't close it until sign-in completes — closing it cancels the login.
**API token doesn't work**
* Verify the token was copied fully, with no leading or trailing spaces.
* Tokens can be revoked or expire. Generate a new one in [hPanel → API](https://hpanel.hostinger.com/api) and reconnect.
## Tools not appearing in your assistant
**In VS Code (Copilot)**
* Reload the window (**Developer: Reload Window** from the Command Palette).
* In Copilot Chat, click the **Tools** button and check that Hostinger tools are enabled.
**In Cursor, Windsurf, Devin Desktop, or Antigravity**
* These editors read the MCP configuration on startup. Fully quit and reopen the editor (not just the window).
* Verify the configuration file exists:
* Cursor: `~/.cursor/mcp.json`
* Windsurf / Devin: `~/.codeium/windsurf/mcp_config.json`
* Antigravity: `~/.gemini/antigravity/mcp_config.json`
* If the file is missing, disconnect and reconnect from the Hostinger sidebar.
**A product's tools are missing**
Check that the product group is enabled in the Hostinger sidebar. **Ecommerce** and **VPS** are disabled by default.
## Errors when the assistant uses tools
**Authentication or "unauthorized" errors**
Your session may have expired or the token was revoked. Run **Hostinger: Disconnect**, then reconnect. If you use an API token, generate a fresh one in hPanel.
**Tools fail immediately after connecting**
The MCP servers are downloaded on first use via `npx`, which requires internet access. Check your network and any proxy or firewall that might block npm registry access.
## Windows-specific notes
* OAuth sign-in opens a visible `cmd.exe` terminal — this is expected and required on Windows.
* If you see duplicate Hostinger entries in your assistant's tool list, update to the latest extension version, then disconnect and reconnect.
## Uninstalling cleanly
1. Run **Hostinger: Disconnect** first. This removes credentials and cleans up MCP configuration in all managed editors and CLIs.
2. Then uninstall the extension from the Extensions panel.
Disconnect works even if Node.js has been removed from your system — the Connector deletes the stored credentials file directly.
## Still stuck?
* Check the [Hostinger API reference](/api-reference/overview) for API-level details.
* Contact [Hostinger support](https://www.hostinger.com/contact) — available 24/7.
***
*Last updated: July 21, 2026*
# API Reference
How to authenticate against the Hostinger API, how requests and rate limits work, where to find the full endpoint reference, and the other ways to automate Hostinger — the CLI, the SDKs, the MCP serve
The Hostinger API is a mostly RESTful API over HTTPS. Every endpoint is documented under [**Endpoints**](/api-reference/endpoints), grouped by product — hosting, domains, DNS, email, VPS, WordPress, ecommerce, and billing.
Those pages are rendered from the same OpenAPI specification that produces the CLI, the SDKs, and the MCP server, so the reference cannot drift from the API itself.
## Authentication
1. Generate an API token in [hPanel → API](https://hpanel.hostinger.com/profile/api). Tokens inherit the permissions of the user who created them and can be set to expire. See [Security & Access](/account/security) for how they're managed.
2. Send the token as a bearer header on every request:
```bash
curl https://developers.hostinger.com/api/hosting/v1/websites \
-H "Authorization: Bearer YOUR_API_TOKEN"
```
## Making requests
The base URL is `https://developers.hostinger.com`, and every path is prefixed with `/api/`, the product, and a version — for example `/api/hosting/v1/websites`. Versions are per endpoint, so `v1` paths keep working as new ones are added.
Requests must use `Content-Type: application/json`, and responses are always JSON.
Parameters arrive in three places:
* **Path parameters** identify a resource and are written in curly braces in the reference — `/api/vps/v1/virtual-machines/{virtualMachineId}`. Substitute the value; every path parameter is required.
* **Query parameters** filter, search, and paginate — `?page=2`. All of them are optional. See [Pagination](/api-reference/pagination) for `page` and `per_page`.
* **Request bodies** carry the data for `POST`, `PUT`, and `PATCH` as a single JSON object. Each [endpoint page](/api-reference/endpoints) documents the required structure and shows an example.
A `202 Accepted` means the request was taken but completes asynchronously — the purchase endpoints return it while payment is processing. Poll the resource rather than resending. [Errors](/api-reference/errors) covers the rest of the status codes and what a failed response looks like.
## Rate limits
The API allows **90 requests per minute**. Authenticated requests are counted per user — so the same token used from several machines shares one budget — and unauthenticated requests are counted per IP address. Some accounts have a custom limit; a few endpoints, such as domain availability checks, are metered separately.
Exceeding the limit returns `429 Too Many Requests`. Authenticated responses carry `X-RateLimit-Limit` and `X-RateLimit-Remaining` so you can pace your calls, and a `429` adds `Retry-After`. Repeatedly hitting the limit can get your IP temporarily blocked.
## Trying endpoints from the browser
Each endpoint page has a **Test it** panel. Paste an API token into it and the request runs against the live API from your browser — the same call the code samples show.
> Test requests count against your rate limit and act on your real account. Prefer read-only endpoints while exploring.
## Reference pages
* [**Endpoints**](/api-reference/endpoints) — every endpoint, grouped by product
* [**Pagination**](/api-reference/pagination) — `page`, `per_page`, and the `meta` object on list endpoints
* [**Errors**](/api-reference/errors) — status codes, the error response shape, and correlation IDs
* [**Support & feedback**](/api-reference/support) — where to report a bug or request an endpoint
## Other ways to automate Hostinger
* [**Hostinger CLI**](/api-reference/cli) — the official command-line client, generated from this same specification. Install it and sign in from your browser; no API token needed:
```bash
brew install hostinger/tap/hostinger
hostinger hosting websites list
```
* [**Scripting with the CLI**](/api-reference/cli-scripting) — piping JSON output into scripts and CI
* [**SDKs**](/api-reference/sdks) — official client libraries for PHP, Python, and TypeScript
* [**Email SDKs**](/api-reference/email-sdks) — libraries and a CLI for the separate [Mail API](https://api.mail.hostinger.com), which reads and sends mail from your mailboxes
* [**Hostinger Connector**](/hostinger-connector/overview) — manage Hostinger from your code editor through an AI assistant, powered by this API
* **MCP server** — the [`@hostinger/mcp`](https://www.npmjs.com/package/@hostinger/mcp) npm package exposes the API as 372 Model Context Protocol tools for any AI assistant, or connect to the hosted remote server at `https://mcp.hostinger.com` with no install
[**Tools & integrations**](/api-reference/tools) covers all of the above plus the Terraform provider, Ansible collection, n8n node, WHMCS module, and Postman collection.
***
*Last updated: September 10, 2026*
# Pagination
How list endpoints in the Hostinger API paginate — the page and per\_page query parameters, the meta object in the response, and how to walk every page from a script.
List endpoints that can return large collections are paginated. Instead of one enormous response, you request a page at a time and the response tells you how many items exist in total.
Paginated endpoints are the ones that accept a `page` query parameter — 43 of them across hosting, agency hosting, mail, Reach, VPS and ecommerce. Every [endpoint page](/api-reference/endpoints) lists its own parameters, so check there when you're unsure.
Endpoints that return a small, bounded collection — data centers, OS templates, a website's cron jobs — aren't paginated and return everything at once.
## Requesting a page
| Parameter | Type | Default | Notes |
| ---------- | ------- | ------- | --------------------------------------- |
| `page` | integer | `1` | Which page to return. |
| `per_page` | integer | `25` | How many items per page. Maximum `100`. |
```bash
curl "https://developers.hostinger.com/api/hosting/v1/websites?page=2&per_page=50" \
-H "Authorization: Bearer $HOSTINGER_API_TOKEN"
```
> **Note:** Not every paginated endpoint accepts `per_page`. The VPS and ecommerce list endpoints, along with `GET /api/reach/v1/contacts`, take `page` only and use a fixed page size.
## Reading the response
A paginated response wraps the collection in `data` and adds a `meta` object:
```json
{
"data": [
{ "id": 1, "domain": "example.com" },
{ "id": 2, "domain": "example.net" }
],
"meta": {
"current_page": 2,
"per_page": 50,
"total": 137
}
}
```
| Field | Meaning |
| -------------- | --------------------------------------------------------------- |
| `current_page` | The page you just received. |
| `per_page` | Items per page actually applied. |
| `total` | Total items across all pages — not the number in this response. |
There is no `last_page` field and no `next` link. Calculate the page count yourself: `ceil(total / per_page)`, or keep requesting until a page comes back with an empty `data` array.
## Walking every page
Keep requesting until you've collected `total` items, or until a page comes back empty.
```bash
page=1
while :; do
body=$(curl -s "https://developers.hostinger.com/api/hosting/v1/websites?page=$page&per_page=100" \
-H "Authorization: Bearer $HOSTINGER_API_TOKEN")
count=$(echo "$body" | jq '.data | length')
[ "$count" -eq 0 ] && break
echo "$body" | jq -r '.data[].domain'
page=$((page + 1))
done
```
In Python, the same loop against the [SDK](/api-reference/sdks):
```python
page = 1
while True:
response = websites.list_websites_v1(page=page)
if not response.data:
break
for website in response.data:
print(website.domain)
page += 1
```
> Each page is a separate request and counts against your [rate limit](/api-reference/overview#rate-limits). Use `per_page=100` when you're paging through a large collection — it's the difference between 2 requests and 8 for the same 200 items.
## Pagination and the other tools
The [CLI](/api-reference/cli) and the [SDKs](/api-reference/sdks) expose `page` and `per_page` as ordinary arguments and don't paginate for you — the loop above is yours to write. See [Scripting with the CLI](/api-reference/cli-scripting) for piping paged output into a script.
***
*Last updated: September 10, 2026*
---
[Next Page](https://docs.hostinger.com/llms-full.txt/1)