Secure cloud hosting in India: what actually protects your site

How hosted sites really get hacked

Most compromised websites are not broken into by a clever attack on the server. They fall to an outdated plugin or theme, a reused password, an admin account without two-step sign-in, or a file uploaded through a form that should never have accepted it. Once inside, attackers plant small scripts that send spam, redirect search traffic or hide links for search engines only.

We have cleaned sites like this when moving them from other hosts: droppers with random file names, a web shell reading raw input, and rules that showed search engines a different page from visitors. The defences below exist because of exactly those cases.

Isolation: your account is a sandbox

On Cloud Ninza every hosting account runs in its own sandbox. Its PHP, its apps, its cron jobs and its terminal can only see its own home folder; another customer's files are invisible to it, and a compromised site on another account cannot reach yours. Apps run as their own user, with no special privileges, inside the account's memory limit.

That matters even if you trust your own code, because it limits the damage from someone else's mistake.

Access control: SSL, SSH keys and two-step sign-in

Free SSL encrypts every page and renews itself, and "Always use HTTPS" sends visitors to the secure version. SSH is off until you switch it on, and then accepts keys only — no passwords to guess. The hosting dashboard supports two-step verification with Google Authenticator, Microsoft Authenticator or any TOTP app, with one-time recovery codes.

Turn two-step sign-in on for the dashboard and for every WordPress or app administrator. It stops the single most common way accounts are taken over.

• Free SSL with automatic renewal
• Key-only SSH, off by default
• Two-step verification on the dashboard
• phpMyAdmin opens signed in for one database, without sharing a password

Visibility: the activity log and security emails

Security you cannot see is hard to trust. The activity log records sign-ins and failed sign-ins, password changes, SSH key changes, database and cron changes, deployments and plan changes, with the time and IP address, and can be downloaded as a CSV. Security-sensitive changes also send you an email, so a change you did not make reaches you within moments.

Safe deployments

Many sites break — or get exposed — during an update. Git deployments on Cloud Ninza build each release in its own folder, switch to it only when the build succeeds, check that the site answers, and roll back automatically if it does not. The repository itself never sits in your web root, so your Git history and secrets are not downloadable.

For WordPress, theme and plugin file editing from the admin is switched off on migrated sites, which removes a favourite route for planting code.

Recoverability: backups you control

Security is also about how fast you recover. Back up your project from the dashboard before any big change: the site's files and databases go into one archive you can download or keep in your account. Keep at least one copy off the server, on your own computer or in object storage. On cloud servers, continuous backup gives point-in-time recovery.

Your part of the job

Hosting security covers the platform; your habits cover the rest. Keep WordPress, plugins and app dependencies updated. Remove plugins and admin accounts you no longer use. Use unique passwords and a password manager. Give staff their own logins instead of sharing one. Check the activity log after anything unusual.

If something does go wrong, open a ticket: our engineers will help you find what was changed and clean it.

A security checklist for the first week

New hosting is the easiest time to set things up properly, because nothing depends on the old habits yet. Work through this list in the first week and most of the common risks are closed before they matter.

• Turn on two-step verification on the hosting dashboard and save the recovery codes offline.
• Give every person who needs access their own login; never share one.
• Switch on Always use HTTPS once SSL is issued.
• Leave SSH off unless someone needs it; when they do, add their public key, not a password.
• Delete the default and unused WordPress admin accounts and plugins.
• Make a backup from the dashboard and download it.
• Read the activity log once so you know what normal looks like.

What to do if something looks wrong

If you see a sign-in you do not recognise, a file you did not upload, or your site suddenly redirects somewhere strange, act in this order. Change the dashboard password and turn on two-step sign-in if it was off. Check the activity log for what changed and when. Remove SSH keys you do not recognise. Take a backup of the current state for investigation, then restore your last good backup. Update everything, and change every password that lived in the site's configuration.

Then open a ticket. Our engineers can look at what was changed, help remove anything planted and check that it has not come back. Speed matters more than perfection: a site that is cleaned within hours loses far less trust and search ranking than one that keeps serving spam for weeks.

How isolation protects you on shared servers

On a shared server, the biggest risk is a neighbour's problem becoming yours. Each Cloud Ninza account runs as its own Linux user, and every account's home folder is closed to every other account, so one account's PHP, cron jobs, terminal or app cannot read another account's files. Apps run as their own service with extra restrictions: they see only their own home folder, cannot raise their privileges and run inside the account's memory limit.

Secrets such as wp-config.php and app settings files are readable only by the account itself. The browser terminal and SSH run inside a sandbox that shows only the account's own files. None of this replaces good habits, but it means a mistake on another site stays on that site.

Security for teams

When several people work on one site, decide who needs what. A designer may need WordPress admin but never the hosting dashboard. A developer may need Git and SSH but not billing. Keep the hosting dashboard login for the people responsible for the account, protect it with two-step sign-in, and give developers deploy keys and SSH keys of their own rather than a shared password. When someone leaves, remove their keys and WordPress account the same day.

Key takeaways

The short version, for anyone skimming:

• Most hacks come from outdated plugins and weak or reused passwords, not the server.
• Account isolation stops one compromised site from reaching another.
• Use SSL everywhere, key-only SSH and two-step sign-in.
• The activity log and security emails show you what changed and when.
• Keep a downloaded backup and update software regularly.