Understanding .htaccess on KapsuleHost

Kapsule serves every website with a high performance web server that does not read .htaccess, so rules you add to that file have no effect: this guide explains what that means for a WordPress site and shows the KPanel setting that does each job instead.

If you have moved from a shared cPanel host, .htaccess was probably where you put redirects, HTTPS forcing, custom error pages and bot blocks. All of those things still work on Kapsule. They are simply set in KPanel rather than in a text file, and because they are applied at the server level they are faster and cannot break your site with a typo.

Why .htaccess Does Nothing Here

.htaccess is a per-directory configuration file for the Apache web server. Apache re-reads it on every single request, which is what makes it convenient and also what makes it slow.

Kapsule does not run Apache. Your site is served by an event driven web server that loads its configuration once at startup, which is a large part of why sites here respond faster under load. That server has no equivalent of a per-directory override file, so it never opens .htaccess.

The good news is the reverse of the usual .htaccess horror story: a syntax error in the file cannot take your site down here, because nothing parses it.

What Still Works Without It

Permalinks. The single most common reason a WordPress site needs .htaccess on Apache is pretty permalinks. On Kapsule the rewrite is built into your site's server configuration, so /2026/07/my-post/ resolves through WordPress with no .htaccess block at all. If permalinks are returning 404s, the cause is something else: see Fixing WordPress Permalink Issues.

WordPress writing to the file. WordPress and some plugins still write # BEGIN/# END blocks into .htaccess because they assume Apache. That is harmless. The file is real, it is writable, and you will see it in the file manager. It simply has no reader.

Security plugins that report "hardening applied". Plugins that claim to have locked down xmlrpc.php or wp-config.php by editing .htaccess have not actually protected anything on this platform. Use the site's own Security tab, which applies the equivalent rules at the server.

KPanel Equivalents for Common .htaccess Rules

Every one of these lives on the site itself: Websites, then your site, then the tab shown.

Two of these do more than the .htaccess version ever could. Redirects support exact paths, trailing-slash prefixes and wildcards such as /blog/*, and KPanel verifies the redirect live after you save it. Error pages are served with their true status code, so a custom 404 page is still a real 404 to search engines rather than a 200 with an apology on it.

Finding and Reading the File

You may still want to look at .htaccess, usually to see what a plugin has written into it or to copy rules out before recreating them in KPanel.

From the WordPress tab

1. Sign in to KPanel and click Websites in the left sidebar.
2. Click the site you want.
3. Open the WordPress tab, then the wp-config section.
4. Scroll to the .htaccess panel. The contents are shown read only, with an Edit button if you need to change them.

From the file manager

1. Open the site, then Files, then File Manager.
2. Click Show Hidden in the toolbar. Files beginning with a dot are hidden by default, so .htaccess will not appear until you do this.
3. Click .htaccess to open it in the built in editor.

The file sits at the root of your site, alongside wp-config.php and wp-content. Full detail on the editor and its permissions controls is in Using the File Manager.

The Default WordPress Block

For reference, this is the block WordPress writes for itself. On an Apache host it drives permalinks. On Kapsule it is inert, and deleting it will not break anything:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Leave it in place if you might move the site to an Apache host later. WordPress will rewrite it anyway the next time you save your permalink settings.

If You Are Migrating Rules In

When you bring a site over from cPanel, open the old .htaccess before you cancel the old hosting and work through it line by line:

1. Redirects. Recreate each Redirect or RewriteRule in Advanced, then Redirects. One row per rule. Choose 301 for a permanent move, 302 if the change might reverse.
2. HTTPS forcing. Delete it. Turn on Force HTTPS in the site's Settings instead.
3. IP blocks. Recreate in WordPress, then Security, in the IP blocking panel.
4. Caching and compression headers. Delete them. They are handled for you, and stale mod_expires rules from an old host are a common source of confusing cache behaviour.
5. Anything a plugin wrote. Ignore it. Reinstall the plugin on the new site and let it do its own thing.

Your migration keeps the file itself, so nothing is lost while you work through the list. Full migration walkthrough: Migrating a Website From cPanel.

Troubleshooting

"I added a redirect to .htaccess and nothing happened." Expected. Add it in Advanced, then Redirects. The Status column there tells you whether the redirect was verified live.

"A plugin says my site is hardened but a scanner disagrees." The plugin wrote .htaccess rules that are not being read. Check the site's Security tab for the protections that are genuinely applied.

"My old host's .htaccess had rules I do not understand." Do not copy them over blind. Open a ticket with the file attached and we will tell you which ones have a Kapsule equivalent and which were only ever compensating for a shared Apache host.

"Permalinks are broken." This is not an .htaccess problem here. Go to Fixing WordPress Permalink Issues, or flush the rewrite rules from the site's WordPress tab, then Quick Actions, then Flush Rewrites.