How to Safely Host an Addon Domain on a Shared VPS (Without Risking Your Main Site)

Hosting multiple websites on a single VPS saves money. However, using standard addon domains creates a shared file tree that risks your main site. If a new WordPress install gets hacked, the attacker gains access to everything in that shared root.

You must isolate the new domain completely to protect your blast radius.

The Danger of Shared File Trees

When you create an addon domain in cPanel, it usually generates a folder inside your public_html directory. This is incredibly dangerous.

If a hacker uploads a malicious script to the secondary site, they can move laterally. They can rewrite your .htaccess files or steal your primary database credentials. You must sever this connection completely.

Step 1: Isolate the Directory Path

Never place an addon domain inside your primary site’s public folder. When adding the domain in cPanel, manually change the document root.

Route it to a completely separate folder in your home directory. For example, use /home/username/newdomain.com instead of /home/username/public_html/newdomain.com. This breaks the direct hierarchical link between the two websites.

Step 2: Enforce Database Isolation

Sharing a single database across multiple sites is an amateur mistake. Sharing a database user is just as bad.

[link: How to Set Up a Secure MySQL Database with Least-Privilege Users]

You must create a completely new MySQL database for the addon domain. Next, create a brand new database user. Assign this user privileges only for the new database.

Never reuse your primary store’s database user. If the new site is compromised, the attacker cannot read your main e-commerce tables.

Step 3: Restrict PHP Execution

Hackers frequently hide malicious PHP scripts inside WordPress upload folders. You must prevent the server from executing PHP in these directories.

Create a .htaccess file inside the wp-content/uploads directory of your new addon domain. Add a rule that blocks all PHP execution in that specific folder. This neutralizes backdoors uploaded through theme or plugin vulnerabilities.

Step 4: Install a Web Application Firewall Immediately

Do not wait to secure a new install. Add a Web Application Firewall the moment the WordPress setup completes.

We install Wordfence on day one. Turn the firewall on and enable login security features. Block aggressive IP addresses automatically.

[link: How to Block Malicious Bot Traffic from Crawling Your Server]

A new domain might not have traffic, but automated bots will find and attack it within hours.

Step 5: Lock Down File Permissions

Incorrect file permissions give attackers the exact access they need to modify your core files. Check your addon domain’s directory via cPanel File Manager or SSH.

Enforce the following strict permissions:

  • Files should be set to 644.
  • Directories should be set to 755.
  • Your wp-config.php file should be set to 600.

Setting wp-config.php to 600 ensures only the direct file owner can read your database credentials.

Step 6: Maintain a Minimal Plugin Footprint

Every plugin you add increases your attack surface. Treat the new addon domain with extreme discipline.

Do not install bundled plugins or visual builders if you do not absolutely need them. Keep the stack minimal. We use an SEO plugin, a caching layer, a firewall, and an internal linking tool.

[link: The Best Lightweight WordPress Themes for Blazing Fast Performance]

Fewer plugins mean fewer vulnerabilities that threaten your shared VPS environment.

Step 7: Automate Minor Security Updates

You cannot afford to forget about a secondary site. Outdated software is the primary cause of server breaches.

Enable automatic background updates for WordPress core minor versions. Turn on auto-updates for your trusted security and caching plugins. You should handle major version updates manually, but security patches must apply instantly.

Takeaway: Adding a domain to your VPS does not have to threaten your main store. Place the directory outside public_html, create isolated database users, and lock down PHP execution. Treat the secondary site with the exact same security discipline as your primary business.

Leave a Comment