What sets our shared CLOUD hosting apart:

No renewal price hikes | No upselling | No hidden fees | No overloaded servers | No shared databases | Fixed monthly pricing, even for Cloud Hosting | Expert support | Free 30 day trial | Free website migration

100% Drupal-Compatible Hosting Servers

Drupal Web Hosting Solutions

Economy	Regular	Deluxe	Ultimate
Perfect for customers who only want a simple personal website or a blog.	A good choice for any online store or a fairly complex website.	A reasonably priced shared web hosting package, good for resource-heavy personal websites.	The right solution for high-profile websites with lots of visitors.
Unlimited storage	Unlimited storage	Unlimited storage	Unlimited storage
Unlimited bandwidth	Unlimited bandwidth	Unlimited bandwidth	Unlimited bandwidth
1 website hosted	5 websites hosted	Unlimited websites hosted	Unlimited websites hosted
24/7/365 support	24/7/365 support	24/7/365 support	24/7/365 support
30 Days Money Back Guarantee	30 Days Money Back Guarantee	30 Days Money Back Guarantee	30 Days Money Back Guarantee
30-Day Free Trial	30-Day Free Trial	30-Day Free Trial	30-Day Free Trial
$4.95 / month	$8.75 / month	$17.50 / month	$25.00 / month
Compare All Hosting Plans	Compare All Hosting Plans	Compare All Hosting Plans	Compare All Hosting Plans
Start Free Trial	Start Free Trial	Start Free Trial	Start Free Trial

Questions about Drupal hosting? See our FAQ.

A narrative guide to Drupal hosting.

There is a point in the life of almost every serious website when somebody stops talking about the design and asks a much less glamorous question.

Where is it going to live?

That question can be easy to ignore at the beginning. A new Drupal website may start with a theme, a few pages, a handful of modules, and only a small number of visitors. Everything feels light. The administrator clicks around the dashboard, changes some settings, creates content, and perhaps wonders why anyone would ever need anything more complicated than an ordinary hosting account.

Then the website grows.

More content arrives. More people need access. Editors begin working at the same time. Images multiply. Search becomes important. Forms appear. External services become involved. A development team starts using Composer and Drush. Security updates have to be handled properly. The database gets larger. Traffic becomes less predictable.

At some point, hosting is no longer a background detail.

It becomes part of the website itself.

That is where Drupal hosting enters the story.

This content management system (CMS) is not simply a place to publish a few articles. It is a flexible content management platform that can be used for everything from relatively modest business websites to large, highly structured publishing systems. Its flexibility is one of its greatest strengths, but flexibility also means that the server underneath the website has to be prepared for the way Drupal is actually being used.

And that is where choosing hosting by price, disk space, or the number of email accounts included in the package can become a surprisingly expensive mistake.

In This Story

The Beginning

Imagine a company called Northbridge Consulting.

It is not a giant corporation. There are thirty employees, several departments, hundreds of documents, a growing knowledge base, and a website that needs to do rather more than display a logo and a phone number.

The first version of the website was built quickly.

There was an About page. A Contact page. A few service pages. Somebody added a news section, and another person decided the company needed downloadable reports.

Nothing seemed especially difficult.

Then the company began to expand.

Different departments wanted their own content areas. Editors needed different permissions. Old documents had to remain available while newer versions appeared. Some content needed to be published only after approval. The company wanted better search. The marketing department wanted landing pages. The legal department wanted carefully controlled access to certain information.

Suddenly the website had become a publishing system.

That is exactly the sort of moment when Drupal starts making sense.

But Northbridge discovers something else at the same time.

The software choice and the hosting choice cannot really be separated.

A Drupal website is an application running on a web server, using PHP, a database, storage, and a collection of supporting services. The quality of that environment influences how reliably the site behaves, how easily it can be updated, how much traffic it can handle, and how painful the inevitable problems will be.

The website does not merely need somewhere to exist.

It needs somewhere suitable to operate.

Back to the main menu

What Drupal Actually Is

It is often described simply as a content management system.

That description is correct, but it misses much of what makes Drupal interesting.

The CMS is designed around structured content, permissions, reusable components, configurable workflows, and extensibility. A website can be organized around different content types, taxonomies, user roles, publishing processes, views, fields, and modules rather than treating every page as an isolated piece of text.

That makes it particularly useful when a website starts behaving more like an application than a brochure.

Northbridge may have articles, events, employee profiles, downloadable reports, training materials, locations, product information, and internal resources. Each of those things can have its own structure and rules.

That structure is powerful because it lets the system understand the content instead of merely displaying it.

But the same sophistication changes the hosting requirements.

A very small static website can survive almost anywhere. A complex installation may involve PHP requests, database queries, caches, file operations, cron tasks, search processes, external connections, and administrative activity all happening within the same environment.

The more the system is asked to do, the more important the environment underneath it becomes.

Modern Drupal also brings a development and maintenance workflow that is different from the old image of simply uploading files through FTP. Composer is central to managing Drupal codebases, and Drush is widely used for administration from the command line. Drupal's current documentation specifically points to SSH access as an important requirement for shared hosting environments intended to support Drupal with Composer.

That tells us something important about modern Drupal hosting.

The question is no longer only whether the host can run PHP.

The question is whether the host provides a working environment for the way the CMS is actually developed and maintained.

Back to the main menu

Why Hosting Matters So Much

Northbridge begins its search by doing what many website owners do.

It opens a comparison page and looks at prices.

One company offers huge storage. Another advertises unlimited websites. A third promises a free domain. A fourth includes a large number of email accounts.

Everything looks impressive.

Almost none of it answers the important questions.

How much memory does the account actually have?

How much CPU can the website use?

How many PHP workers are available?

Can Composer be run properly?

Is SSH access available?

Can the server run the required PHP version and extensions?

Which database versions are supported?

Can the document root be configured correctly?

How are backups handled?

What happens when the site outgrows the account?

Those questions are less attractive in an advertisement, but they are much closer to the things that determine whether a Drupal website will be pleasant to operate.

A host can technically support Drupal while still being a poor environment for a demanding Drupal project.

That distinction matters.

Drupal's official requirements currently specify a particular PHP and database environment for Drupal 11, and its documentation also makes clear that the hosting arrangement matters for Composer-based workflows, command-line access, and the web root configuration.

The best Drupal hosting plan is therefore not the one with the longest list of features.

It is the one whose features actually correspond to the way the website will be built and used.

Back to the main menu

The Server Behind This CMS (content management system)

Before Northbridge installs anything, someone has to look underneath the website and inspect the server environment.

Drupal 11 requires PHP 8.3 or newer within the supported range for current Drupal 11 releases, and the database requirements are considerably more specific than the phrase “MySQL hosting” suggests.

For Drupal 11, the official Drupal documentation lists MySQL 8.0 or newer, MariaDB 10.6 or newer, PostgreSQL 16 or newer, or SQLite 3.45 or newer, depending on the database being used. Drupal also requires the appropriate PHP database connector and other PHP extensions used by core.

That is why a hosting company saying “we support PHP and MySQL” is not enough information for a serious Drupal project.

The details matter.

Suppose a company is still using a hosting plan whose PHP options stop below the version required by Drupal 11.

The plan may have wonderful storage.

The server may even be physically fast.

None of that changes the basic problem.

The software cannot run in the required environment.

The same principle applies to the database. A server running an older database release might be perfectly acceptable for another application while being incompatible with a current Drupal installation.

This is one of the reasons a Drupal hosting decision should begin with the application version and its actual requirements rather than with the hosting company's marketing page.

The requirements also evolve over time.

Drupal's minimum versions are not frozen forever. As the Drupal ecosystem moves forward and underlying software reaches the end of its supported life, hosting environments have to keep moving too.

A good host therefore needs to make upgrades possible rather than trapping the customer on yesterday's server stack.

Back to the main menu

PHP Is More Than a Version Number

Northbridge's developer checks the hosting control panel and sees PHP 8.3.

For a moment, everyone relaxes.

Then the developer looks again.

PHP is not just a version number.

The CMS relies on PHP extensions and configurations that support database connections, XML processing, image handling, cryptography, string manipulation, compression, and other functions. Individual modules can also introduce their own requirements.

A hosting account can therefore have the correct PHP version and still be missing something the website needs.

This becomes particularly important when Drupal is expanded with contributed modules.

Northbridge installs a module that requires an extension not enabled on its shared account. The module's documentation says what is needed, but the hosting plan does not offer a way to enable it.

Now the problem is no longer Drupal.

It is the hosting environment.

PHP configuration can also affect performance. Modern Drupal installations commonly benefit from proper PHP opcode caching, and the Drupal documentation notes an important configuration detail for native OPcache: comments need to remain available because Drupal relies on annotations in relevant code.

That may sound like an obscure technical detail.

It is.

But obscure details are precisely the sort of things that separate a genuinely suitable hosting environment from one that merely advertises support for Drupal.

The lesson for Northbridge is simple: never stop at the PHP version. Check the extensions, settings, and ability to adjust the environment when the application requires something different.

Back to the main menu

The Database Quietly Runs the Show

Visitors tend to notice the part of a Drupal website they can see.

The database is one of the parts they never see.

Yet much of what happens on the site depends on it.

Content is stored there. Configuration is stored there. Users, permissions, fields, relationships, taxonomy information, and a great deal of the site's operational information depend on database activity.

Every time somebody opens a page, submits a form, runs a search, logs in, updates an article, changes configuration, or performs some other action, Drupal may need the database.

That makes database performance important even when the website appears visually simple.

Imagine a company directory containing thousands of records. A visitor searches by department, location, language, and job function. Drupal has to retrieve the appropriate data and build the result.

Now imagine hundreds of people doing similar things at the same time.

The database suddenly becomes much more than a storage box.

It becomes part of the site's workload.

Drupal's current documentation recommends InnoDB as the primary storage engine for MySQL and MariaDB environments. PostgreSQL has its own requirements as well, including the pg_trgm extension for supported Drupal versions.

Again, the details may seem far removed from a visitor clicking a menu item.

But the visitor feels the consequences when the database is slow.

A page that seems as though it should appear instantly may hesitate while the content management system waits for data.

The result is an important reminder: fast hosting is not merely fast storage or a powerful processor. The database must be healthy too.

Back to the main menu

Apache, Nginx, and the Web Server

Now Northbridge's developer asks another question.

What web server is underneath Drupal?

Drupal supports web servers such as Apache and Nginx, and both are widely used in production environments.

The choice between them is not automatically a question of which one is “faster.” Much depends on configuration, workload, PHP handling, caching, operating system, deployment practices, and the skills of the people managing the server.

There is, however, one very important point for current Drupal installations.

Drupal 11 no longer supports Microsoft IIS.

That means a hosting company advertising general Windows web hosting is not automatically a suitable Drupal 11 provider.

Northbridge therefore looks for a properly configured Linux environment using a supported web server.

Another detail matters too: the document root.

Modern Drupal projects commonly use the recommended project structure in which the public-facing web root is the /web directory. Drupal's current documentation specifically notes that, since Drupal 11.4, the ability to set the document root correctly to /web is important.

That is easy to miss when comparing hosting plans.

A hosting account can offer PHP, MySQL, SSL, email, and a control panel while still making a modern Drupal deployment awkward because the web root cannot be configured in the way the project expects.

This is a perfect example of why “Drupal-compatible” needs to mean more than “PHP works here.”

Back to the main menu

Composer Changes the Hosting Conversation

Years ago, somebody could describe installing a PHP application by saying, “Download the files, upload them, create a database, and run the installer.”

Modern Drupal deserves a more careful description.

Composer is a major part of contemporary Drupal development and dependency management. Drupal projects use Composer to manage its Core, contributed packages, libraries, and their dependencies in a controlled way.

That changes the relationship between the website owner and the host.

Northbridge's developer wants to update Drupal core.

Instead of manually replacing a collection of files and hoping nothing goes wrong, the developer works with the site's Composer-managed codebase, updates dependencies, tests the result, and deploys the changes.

Suddenly the hosting environment needs to support a proper development workflow.

Can Composer run?

Can PHP's command-line interface be used?

Can the developer connect through SSH?

Are there reasonable process and memory limits?

Can the site's deployment workflow be performed without fighting the hosting control panel?

Those are not luxury questions for a modern Drupal project.

They can determine whether routine maintenance is smooth or frustrating.

Drupal's documentation for small and medium-sized hosting environments specifically discusses shared hosting that supports Drupal through Composer via SSH. That is a useful clue about how Drupal hosting has evolved.

The host is no longer merely the place where the finished website sits.

It is increasingly part of the software maintenance environment.

Back to the main menu

Why SSH Access Matters

Northbridge initially assumes that FTP will be enough.

It soon changes its mind.

SSH access provides a command-line connection to the hosting environment and opens the door to tools that are extremely useful for Drupal administration and deployment.

Composer can be run from the command line. Drush can be used to perform Drupal tasks. Files can be inspected. Logs can be examined. Cache operations can be performed. Scheduled processes can be tested. Deployments can be made in a more controlled way.

That does not mean every site owner needs to become a Linux administrator.

It does mean the hosting environment should not unnecessarily prevent the people responsible for the website from doing their jobs.

Drupal's documentation describes Drush as an important part of the command-line workflow, and current guidance for shared hosting explicitly identifies SSH access as necessary for running Composer-based Drupal projects.

Consider two otherwise similar hosting accounts.

The first allows only browser-based control panel operations.

The second provides SSH access, command-line PHP, Composer support, and a sensible deployment environment.

For a simple personal website, the difference may not matter much.

For a serious Drupal project, it can be enormous.

The second environment gives the developer tools instead of obstacles.

And when a website grows complicated, tools become valuable.

Back to the main menu

Performance Is a Combined Effort

At this point, somebody at Northbridge asks the question that always appears.

“So which host is fastest?”

There is no useful answer without knowing what the website is doing.

Drupal performance is a combined effort.

The CPU matters.

Memory matters.

Storage matters.

The database matters.

PHP workers matter.

The web server matters.

Caching matters.

Modules matter.

Queries matter.

The way the site is built matters.

Even the content itself can matter.

A website serving a few mostly static pages to twenty visitors a day may run beautifully on an environment that would be completely unsuitable for a busy publishing platform.

Then there are simultaneous requests.

One visitor opening a page is easy.

One hundred visitors arriving together is a different story.

Now the server may have to handle many PHP requests, database operations, cache reads, image requests, authentication checks, and other activity simultaneously.

This is where vague hosting claims become unhelpful.

A host might advertise “high-performance servers” without explaining how an individual account is actually limited.

What matters is not the name of the server.

What matters is what Northbridge's Drupal site is allowed to use.

That is why resource limits should be treated as part of the specification rather than hidden fine print.

A website does not benefit from a powerful physical server if its hosting account is prevented from using the resources it needs.

Back to the main menu

Caching Can Change Everything

There is an interesting moment in Northbridge's performance investigation.

The database is not terrible.

The server is not overloaded.

PHP is behaving normally.

Yet the site still feels slower than expected.

Then the developers look closely at caching.

Drupal has several caching mechanisms that can reduce how much work needs to be repeated on every request. Instead of rebuilding everything from scratch each time, the system can reuse information that has already been generated.

That can make an enormous difference.

Imagine a page that thousands of visitors request during a busy afternoon. If Drupal can serve appropriate cached content rather than repeatedly rebuilding the same information, the workload can be reduced substantially.

But caching needs to be understood rather than treated as magic.

Some pages can be cached safely for many visitors. Other pages are personalized and need different handling. Logged-in users may experience a different caching pattern from anonymous visitors. Dynamic content can complicate the picture further.

External caching layers, reverse proxies, content delivery networks, and other technologies can also become part of the architecture as a website grows.

That is why the host needs to cooperate with the caching strategy.

If the provider imposes strange restrictions on PHP, headers, reverse proxies, or server configuration, some performance improvements may become harder to implement.

Good hosting gives the Drupal site room to use the performance mechanisms that make sense for its workload.

Back to the main menu

Images and Files Add Weight

Northbridge's communications department begins uploading high-resolution photographs.

Then it starts adding PDFs.

Then videos.

Then downloadable reports.

The website's file storage begins to grow quietly.

This is common with this content management system because the platform can be used to manage much more than ordinary text.

Storage therefore matters, but so does the way those files are delivered.

A large image takes longer to transfer than a small one. A collection of oversized photographs can turn a page into a heavy download. A large PDF can place more demand on storage and bandwidth than a normal HTML page.

The sensible solution is not simply buying more disk space.

Files should be managed intelligently.

Images should be appropriately sized and compressed. Unnecessary files should not remain on the site forever. Large media collections may eventually benefit from specialized storage or delivery services.

Backups also become much larger as the media library grows.

That introduces another hosting question: does the backup system have enough capacity, and does it allow practical restoration?

There is a big difference between saying “backups are included” and being able to recover a large Drupal website without discovering that the backup is incomplete, inaccessible, or too old to be useful.

Northbridge learns that disk space, bandwidth, backup storage, and site performance are all connected.

A file does not stop mattering just because it sits quietly in a folder.

Back to the main menu

Modules, Themes, and Complexity

One of Drupal's great attractions is its ability to be extended.

That is also where things can get interesting.

Northbridge installs a module to provide advanced search.

Another handles forms.

Another adds integration with an external service.

Another helps with administration.

The theme becomes more sophisticated.

Nothing is wrong.

But every additional piece of software introduces another relationship that may need to be maintained.

A module can require a particular PHP version. It can depend on another package. It can affect database queries. It can interact with caching. A custom module can introduce its own performance problem. A badly designed integration can consume far more resources than expected.

This is why Drupal performance cannot be judged by hosting hardware alone.

Imagine moving a poorly optimized Drupal website from a modest VPS to a much larger server.

The site might improve.

But the underlying inefficiency has not disappeared.

A slow query is still a slow query.

An unnecessary module is still unnecessary.

A badly designed custom function is still badly designed.

Good hosting gives the website enough resources to work properly, but good Drupal administration ensures that those resources are not wasted.

As the site grows, keeping the codebase clean and the module set under control can become just as valuable as upgrading the server.

Back to the main menu

Security Belongs in the Hosting Decision

One morning, Northbridge's administrator receives a notification that a Drupal update is available.

It is tempting to leave it for tomorrow.

Tomorrow becomes next week.

That is how many security problems begin.

Drupal security is a shared responsibility.

The Drupal project maintains the application and publishes security updates. The website owner is responsible for keeping the application, modules, themes, credentials, and configuration properly maintained. The hosting company is responsible for the server environment and the security of the infrastructure it provides.

None of these responsibilities cancels the others.

A secure server does not make an outdated CMS module safe.

A fully updated Drupal site does not make an insecure server configuration acceptable.

Good Drupal hosting should therefore provide a modern and responsibly maintained operating environment, current server software, secure account isolation where appropriate, reliable HTTPS support, and a sensible process for handling incidents.

Drupal also has application-level security settings that deserve attention.

Trusted host configuration is one example. Drupal's documentation explains that trusted host patterns can be configured to protect against certain HTTP Host header attacks.

This is not the sort of setting that appears in a hosting advertisement.

It is part of the less visible work of running a real website.

Security also becomes especially important when administrators and editors have different roles. Drupal's permission system can be powerful, but only when people take the time to configure it properly.

Hosting can provide the foundation.

It cannot make poor administration disappear.

Back to the main menu

Backups Need to Be Real

There is a scene every website owner hopes never happens.

An administrator makes a mistake.

A deployment goes wrong.

A module update causes unexpected behavior.

A server has a serious problem.

The website stops working.

Someone then asks the most important question of the day.

“Do we have a backup?”

A reassuring answer is not enough.

The backup has to be usable.

A Drupal website has more than one important component. There is the codebase. There are configuration files. There is the database. There are uploaded files and media. There may also be customized themes, private files, integrations, and other application-specific information.

A backup strategy that captures only one part of the website is not a complete recovery strategy.

Imagine restoring Northbridge's Drupal database but discovering that years of uploaded documents are missing.

Or restoring the files while the database belongs to an older version of the site.

The pieces have to belong together.

Backup frequency matters too.

A website that changes every day should not rely on a backup from three weeks ago and call that protection.

Restoration matters just as much.

A backup that has never been tested is an assumption, not a proven recovery system.

This is why hosting comparisons should include questions about backup retention, backup location, restoration procedures, and whether customers can actually initiate a restore when necessary.

Cheap hosting often looks attractive until the day someone needs the expensive thing that was never properly included.

Recovery is one of those things.

Back to the main menu

When the Website Starts Growing

Northbridge does not remain small.

At first there are a few thousand content records.

Later there are tens of thousands.

More people work in the administration area.

Traffic increases.

Search becomes more sophisticated.

More modules are introduced.

External services begin communicating with the site.

The original hosting plan still works.

But it is starting to feel crowded.

This is the moment when some site owners make a mistake.

They wait for something to break.

That is rarely the best time to plan an upgrade.

A better approach is to watch the website's behavior before the limits become painful.

Are CPU limits being reached?

Is memory becoming a constraint?

Are PHP workers saturated?

Is database performance declining?

Are background tasks taking longer?

Does the site perform differently during busy periods?

Do deployment operations need more resources than the current account allows?

Those questions provide a much better basis for scaling than simply saying, “We need more power.”

Scaling can mean moving from shared hosting to a VPS.

It can mean moving from a small VPS to a larger one.

It can mean separating the database from the web server.

It can mean adding caching or a content delivery network.

It can also mean doing nothing to the server and fixing an inefficient application instead.

The important point is that growth should be managed rather than feared.

A good host gives the site somewhere to go next.

Back to the main menu

Shared Hosting, VPS, or Dedicated?

There is a persistent belief that serious Drupal websites automatically require dedicated servers.

That is not true.

Nor is the opposite assumption true.

Every Drupal website must use shared hosting because it is cheaper.

The right answer depends on the workload.

A modest Drupal website can run very well on quality shared hosting when the provider supports the required PHP environment, Composer workflow, SSH access, database requirements, document-root configuration, and resource needs.

Shared hosting has a practical advantage.

The customer does not have to manage every part of the underlying server. The provider takes care of much of the infrastructure, which can be attractive to small businesses.

As the website grows, a VPS can provide greater control and more predictable resources.

That can be valuable for a Drupal site with a significant database, more demanding background processes, custom integrations, or higher traffic.

A dedicated server provides still more control and dedicated physical resources.

But dedicated hardware is not automatically the right answer.

There is little benefit in paying for resources the website does not use.

Northbridge eventually chooses a VPS, but only after looking at its real workload.

The decision is based on what the website needs, not on the prestige of the hosting package.

That is the sensible way to approach server selection.

Back to the main menu

Managed or Unmanaged?

Now another question appears.

Who is going to look after the server?

Northbridge has a developer who understands this CMS extremely well.

That does not necessarily mean the developer wants to administer every aspect of a Linux server.

Operating-system updates, firewall rules, web-server configuration, monitoring, service failures, backups, security hardening, and server-level troubleshooting can become a significant responsibility.

Managed hosting can reduce some of that burden, depending on what the provider actually includes.

That last part is important.

“Managed” does not mean exactly the same thing at every hosting company.

One provider may manage the operating system and basic services.

Another may include monitoring and security assistance.

Another may go much further.

Customers therefore need to read the service description rather than relying on the label.

Unmanaged hosting offers greater control, but greater control comes with greater responsibility.

It can be an excellent choice for an experienced technical team.

It can also be a miserable choice for a business that simply wants its Drupal website to work.

The right question is not, “Which type is better?”

The right question is, “Who will be responsible when the server has a problem?”

Once that question is answered honestly, the hosting model often becomes much easier to choose.

Back to the main menu

Moving an Existing Drupal Website

Eventually, Northbridge decides to leave its original hosting company.

The old provider was adequate at the beginning.

It is no longer adequate now.

The website has become larger, the development workflow has changed, and the company wants better control over the environment.

Moving Drupal is not simply a matter of copying the visible pages.

The application needs its codebase.

The database needs to move.

Files and media need to move.

Configuration needs to be correct.

Database credentials need to match.

The PHP environment needs to be compatible.

The web server needs to point to the correct document root.

File and directory permissions need to be appropriate.

Scheduled tasks need to continue functioning.

External integrations need to be tested.

SSL needs to work.

The domain needs to point to the new server.

And the old server should not be turned off until the new installation has been thoroughly tested.

The Composer-based structure of modern Drupal can make migration more systematic because the codebase and dependencies can be managed in a reproducible way, but that does not eliminate the need for careful testing.

A good migration plan also considers the timing of the final database synchronization.

If editors continue adding content while the site is being moved, the two installations can quickly fall out of sync.

This is why a Drupal migration is best treated as a technical project rather than an afternoon spent copying folders.

Sometimes the most valuable hosting service is the support that makes a difficult transition less risky.

Back to the main menu

Common Drupal Hosting Mistakes

Choosing hosting by disk space.

A large storage allowance does not compensate for inadequate CPU, memory, PHP workers, or database performance.

Assuming every PHP host supports current Drupal.

Drupal 11 has specific PHP, database, and web-server requirements. The provider needs to support the actual version being installed.

Ignoring Composer and SSH.

Modern Drupal administration is not always a browser-only activity. A host that prevents proper command-line access can make routine maintenance harder than necessary.

Forgetting the document root.

Modern Drupal projects commonly use /web as the public document root. Hosting that makes the correct configuration difficult can create unnecessary deployment problems.

Buying a VPS without knowing how to administer it.

A VPS gives control, but control creates responsibility. It is not automatically an upgrade in the practical sense.

Installing too many modules without evaluating them.

Every extension adds another piece of software that may affect maintenance, compatibility, security, or performance.

Treating backups as a checkbox.

A backup policy is useful only when it captures the necessary parts of the website and can actually restore them.

Waiting until the site is overloaded before planning the next server.

Scaling is much easier when it is planned before the website reaches its limits.

Assuming the host is responsible for everything.

The host manages the hosting environment. The site owner still has responsibilities for the CMS, modules, themes, accounts, permissions, configuration, and updates.

Assuming the biggest server solves every performance problem.

Sometimes the problem is a query, module, configuration choice, cache strategy, or oversized file rather than a lack of hardware.

Back to the main menu

A Practical Drupal Hosting Setup

By now Northbridge has learned to ignore the marketing adjectives.

It looks at the environment instead.

A practical hosting setup for a modern Drupal website should begin with a supported version of Drupal and then work outward from its actual requirements.

The server should provide an appropriate PHP version and the extensions required by Drupal and the site's contributed modules.

The database should be a supported version and configured appropriately for the chosen Drupal release.

The web server should be supported and correctly configured.

The document root should be capable of pointing to the intended public directory, such as /web in a standard modern Composer-based Drupal project.

SSH access is highly valuable, especially when Composer and Drush are part of the site's maintenance workflow.

Resource limits should be clear rather than hidden behind vague claims of unlimited hosting.

Backups should be reliable and restorable.

SSL should be straightforward to deploy and maintain.

The host should have a sensible upgrade path if the site grows.

And support should be capable of understanding that this system is an application with its own requirements rather than merely a collection of PHP files.

For a small website, that environment may exist on quality shared hosting.

For a larger site, a VPS may provide a better balance of control and resources.

For a demanding enterprise installation, dedicated infrastructure or a more distributed architecture may eventually make sense.

There is no universal Drupal server.

There is only the server that makes sense for a particular Drupal website.

Back to the main menu

The Long-Term View

Three years after its launch, Northbridge's website looks very different.

The design has changed.

The number of content records has multiplied.

New departments have joined the publishing workflow.

The search system is more sophisticated.

There are more editors, more documents, more visitors, and more integrations.

And the hosting has changed too.

That is not a failure.

It is evidence that the website changed.

A hosting plan should not be treated as a permanent marriage made on the day the domain name is registered.

It is infrastructure.

Infrastructure is allowed to evolve.

The small Drupal installation that begins on shared hosting may later move to a VPS. A larger VPS may later be replaced by a more powerful architecture. A site that starts with one application server may eventually use additional caching, external services, or separate database infrastructure.

There is nothing wrong with any of that.

What matters is whether the hosting environment continues to fit the website.

The best long-term strategy is therefore not to guess exactly how large the site will become.

It is to choose a host that makes sensible growth possible.

Back to the main menu

The Ending Is Really a Beginning

Back at Northbridge Consulting, a new employee joins the company and asks why the website has a VPS instead of the inexpensive shared hosting plan they used years ago.

The answer is not complicated.

The website is no longer the same website.

It now contains thousands of pieces of structured content. Editors work on it every day. Search is important. Documents are constantly being added. External systems communicate with it. Updates are performed through a proper development workflow. The database is much larger. The traffic is higher. The consequences of downtime are more serious.

The hosting changed because the job changed.

That is the central idea behind Drupal hosting.

Drupal is capable of being remarkably flexible, but that flexibility does not exist in isolation. It depends on PHP, a database, a web server, storage, command-line tools, permissions, caching, security, backups, and enough resources to perform the work the website is asking it to perform.

A cheap hosting plan can be perfectly suitable for one Drupal website and completely unsuitable for another.

A VPS can be the ideal answer for one company and an unnecessary complication for another.

A dedicated server can be justified by a demanding application and excessive for a small site.

The technology itself does not make that decision.

The workload does.

That is why the right question is not:

“How much does hosting this CMS cost?”

The more useful question is:

“What kind of hosting will give this Drupal website the environment it actually needs, while leaving enough room for the site to grow?”

Once that question is asked, hosting becomes much easier to evaluate.

You start looking beyond disk space.

You check PHP.

You check the database.

You check the web server.

You check Composer and SSH.

You check the document root.

You check resource limits.

You check backups.

You check security.

You check the upgrade path.

And you ask what happens when something goes wrong.

That last question may be the most useful one of all.

Because Drupal hosting is not really about finding a server that can run a website on a good day.

It is about finding an environment that can keep the website running when the site becomes more complicated, the traffic suddenly increases, an update needs to be applied, an editor makes a mistake, a module causes trouble, or the business decides tomorrow that it needs something the website could not do yesterday.

A hosting plan is simply the starting point.

The real goal is to give Drupal enough room to do its job well.

Practical takeaway: When choosing Drupal hosting, compare the provider's actual PHP version and extensions, supported database versions, Apache or Nginx configuration, Composer and SSH support, document-root capabilities, resource limits, backup and restoration process, security practices, and upgrade path against the requirements of the Drupal version you intend to run. For Drupal 11, these details matter far more than headline claims about unlimited storage or low introductory pricing.

Back to the main menu

FAQ

This FAQ covers Drupal web hosting and the practical issues involved in running a Drupal website, including server requirements, PHP, databases, performance, security, backups, updates, DNS, email, caching, development workflows, and day-to-day site management.

FAQ menu

• 1. Drupal Hosting Basics
• 2. Choosing the Right Environment
• 3. Server and Software Requirements
• 4. Installation and Site Setup
• 5. PHP, Databases and Server Configuration
• 6. Performance and Caching
• 7. Security, Backups and Updates
• 8. DNS, Email, SSL and Migration
• 9. Development, Modules and Advanced Use
• 10. Troubleshooting and Practical Questions

1. Drupal Hosting Basics

1. What is Drupal web hosting?

Think of it as a server setup that gives Drupal what it needs to operate normally. PHP and storage alone are not enough. The environment also has to support a suitable database, the right web-server configuration, enough memory and processing capacity, and the way Drupal handles and delivers content.

2. Is Drupal suitable for ordinary websites?

Yes. Drupal is capable of running a straightforward website just as well as a much more involved platform. Where it really comes into its own is when a project needs things such as structured content, different types of users and permissions, several languages, or a high degree of customization.

3. Does Drupal need special hosting?

There is no special class of server that Drupal can only run on. What matters is whether the hosting environment meets the software requirements and gives the site enough resources. A properly configured Linux server is often all that is needed.

4. Can Drupal run on shared hosting?

It can, as long as the account provides the necessary software and controls. PHP settings, database access, file permissions, scheduled tasks and available resources all matter. In practice, the restrictions of the shared environment are usually more important than Drupal itself.

5. Is shared hosting a good choice for a small Drupal site?

For a small site, it can be a sensible and inexpensive option. A modest amount of traffic may place very little demand on the server. Before choosing it, though, make sure the account can provide the required software versions and enough CPU, memory, storage and database capacity during busier periods.

6. When should I consider a VPS?

A VPS becomes attractive when shared hosting starts getting in the way. You gain more predictable resources and considerably more control, which is useful for custom services, unusual configurations, or websites that have grown beyond what a shared account can comfortably handle.

7. Does Drupal work on dedicated servers?

Yes. With a dedicated server, the entire machine is available to the site and you have far more freedom over how the software stack is configured. That can be a good fit for demanding projects, but the extra hardware by itself does not guarantee a faster website.

8. Can Drupal run in the cloud?

Yes. Drupal can be hosted on cloud virtual machines, managed cloud services, containers, and other suitable infrastructure. The word “cloud” does not determine whether Drupal will run well; the important factors are the underlying software, configuration and resources.

9. Is Drupal hosting different from WordPress hosting?

There is plenty of common ground. Both need a web server, PHP, a database, storage, DNS, HTTPS and some form of backup. The differences are more about how the two systems are configured, updated and extended, as well as how they use the server when a site becomes more complex.

10. Can I host Drupal on the same server as other websites?

Yes. Several sites can share one machine quite successfully when it has enough capacity and the individual sites are set up with proper separation. This happens on ordinary shared servers and can also be done through virtual hosts or more advanced multi-site arrangements.

11. Does the location of the server matter?

It can. Physical distance affects network latency, while the data center's location may also matter for legal or support reasons. For many sites, placing the server reasonably close to the main audience is helpful, although server location is only one part of the performance equation.

12. Is Linux the best operating system for Drupal?

Linux is the usual choice for production Drupal installations and is well supported by the Drupal ecosystem. Drupal's system requirements favor Linux or a comparable operating system for production, while Windows is mainly supported for development.

13. Does Drupal need Apache?

No. Apache is widely used, but Drupal can also run with Nginx and other suitable web servers. What matters most is that the web server is set up correctly for PHP and for Drupal's routing, files and security requirements.

14. Can I use a managed Drupal hosting service?

Yes. Managed hosting can take some of the server administration off your hands, including things such as monitoring, backups, maintenance or parts of the update process. You normally pay more for that convenience, but it can be worthwhile when you would rather concentrate on the website than the server.

15. What matters most when choosing a Drupal hosting provider?

Start with the things that affect the actual running of the site, not the biggest numbers in the sales copy. Check software versions, memory limits, database support, cron, backups, server performance, security measures, staging facilities, technical support and how easy it would be to move the website later.

Back to FAQ menu

2. Choosing the Right Environment

16. How much server space does a Drupal site need?

That varies enormously from one site to another. The Drupal code is only one part of the storage picture. Uploaded media, contributed modules, themes, logs, backups and generated files can add up quickly, especially on a site with a large image library.

17. How much RAM does Drupal need?

There is no single amount that suits every installation. A simple website may operate comfortably with modest memory, whereas a more elaborate site using many modules, search tools, image processing or other demanding services can need considerably more.

18. Is CPU important for Drupal?

Yes, particularly when the site has to generate many pages dynamically or deal with several users and background tasks at once. A faster processor can help, but extra CPU will not solve every problem. A slow query or badly designed application can still hold a site back.

19. Is SSD storage important?

It is especially useful for modern CMS workloads. Drupal and its database perform many small read and write operations, and faster storage can reduce the delays involved. SSD and NVMe storage are generally a better fit than traditional spinning disks.

20. How much bandwidth does a Drupal website need?

It depends mostly on how many visitors you receive and what those visitors are downloading. A text-heavy site can use relatively little bandwidth, while one serving large images or other media can use a great deal. Actual traffic patterns are a much better guide than an impressive number printed on a hosting plan.

21. Is unlimited bandwidth really unlimited?

Usually, you should not read the word literally. “Unlimited” hosting can still be subject to fair-use policies, resource ceilings, traffic restrictions or other conditions. The provider's terms tell you much more than the headline on the package page.

22. Should I choose cPanel for Drupal?

cPanel can make everyday hosting tasks easier, but Drupal does not depend on it. Look instead at whether the hosting account gives you the PHP settings, database access, cron, file controls and backup facilities the site actually needs.

23. Is a one-click installer suitable for Drupal?

It can be a convenient way to get a basic installation running without dealing with every setup step yourself. For a production project, however, it is worth finding out exactly what it installs, how updates are managed, and whether the resulting setup fits a Composer-based development and deployment process.

24. Should I choose a managed server or unmanaged one?

It is really a question of who will handle the server. With managed hosting, the provider takes care of more of the administration. With unmanaged infrastructure, you have greater freedom, but configuration, patching, security, monitoring and troubleshooting become your responsibility.

25. Is cheap Drupal hosting a bad idea?

Not by itself. An inexpensive account may be perfectly adequate for a small website. The concern is what you have given up to achieve the low price: perhaps limited resources, old software, overloaded infrastructure, weak support, poor backups or restrictions that make routine maintenance awkward.

26. Does a high price mean the provider is better?

No. A higher price can reflect better infrastructure or more hands-on management, but it can also reflect branding and packaging. Compare the actual service rather than treating the price tag as proof of technical quality.

27. Should I choose monthly or yearly billing?

Annual billing may lower the effective cost, while monthly billing is useful when you want the freedom to leave after a short trial. For an important website, though, the hosting service itself matters far more than whether you pay every month or once a year.

28. Does Drupal benefit from a content delivery network?

Often, yes. A CDN can serve static resources from locations closer to visitors and reduce some of the traffic reaching the origin server. It will not necessarily fix slow dynamic pages, though, because those may still be waiting on PHP or database work.

29. Is Redis useful for Drupal?

It can be, particularly when fast in-memory storage can take pressure off other parts of the system. Redis may improve caching or other workloads, but the result depends on the site's traffic, configuration and where its current bottlenecks are.

30. Does Drupal need Elasticsearch or Solr?

No. A small or straightforward website can use Drupal's normal search capabilities without adding another search service. Larger projects with a lot of content or more advanced search requirements may benefit from Apache Solr, Elasticsearch or another supported solution.

Back to FAQ menu

3. Server and Software Requirements

31. Which PHP versions does Drupal 11 support?

Drupal 11 currently supports PHP 8.3, 8.4 and 8.5. PHP 8.1 and 8.2 are outside Drupal 11's supported range. There is another wrinkle with contributed modules: they can impose compatibility requirements of their own.

32. Can I run Drupal 11 on PHP 8.2?

No. Drupal 11 does not support PHP 8.2. When a hosting provider cannot offer a supported PHP release, that is a genuine compatibility issue and not something that should normally be worked around by bypassing the requirements.

33. Is PHP 8.5 a good choice for Drupal 11?

It can be. PHP 8.5 is listed as supported for Drupal 11.3 and 11.4, but the rest of the project needs to be ready for it too. A third-party module or dependency can have a narrower compatibility range than Drupal core.

34. Which database is best for Drupal?

There is no database that wins for every project. MySQL and MariaDB are common, PostgreSQL is a well-supported alternative, and SQLite can suit certain smaller installations. In many cases, the most practical choice is the database your team understands and can maintain confidently.

35. Which MySQL version does Drupal 11 require?

The current requirements call for MySQL 8.0 or newer. Drupal also expects InnoDB to be available as the primary storage engine, along with the required PDO database support.

36. Which MariaDB version is required?

Drupal 11 requires MariaDB 10.6 or later. The database setup also needs InnoDB and the appropriate PHP database support.

37. Can Drupal 11 use PostgreSQL?

Yes. The current requirements specify PostgreSQL 16 or newer, with the pg_trgm extension enabled. That extension is easy to overlook, so it is worth confirming its availability with the hosting provider before committing to PostgreSQL.

38. Can Drupal use SQLite?

Yes. Drupal 11 currently requires SQLite 3.45 or newer. It can be a useful option for certain small and uncomplicated sites, although larger production systems often have practical reasons to use a separate database server.

39. Does Drupal require a particular web server?

No. Apache and Nginx are both suitable, and other web servers can also work when they provide the functions and configuration Drupal expects. The server name matters less than how the environment is put together.

40. Does Apache need special configuration?

It may. Drupal relies on correct handling of URLs, rewrites, PHP execution, permissions and other server settings. Simply being able to execute PHP does not automatically mean the Apache setup is ready for a production Drupal site.

41. Does Nginx work well with Drupal?

Yes. Nginx is a common choice and can handle Drupal very effectively. The important part is getting its PHP handling, URL rules, static and private files, and protection of sensitive paths right.

42. What PHP extensions does Drupal need?

Drupal core depends on a range of PHP extensions, including PDO, XML, GD, OpenSSL, JSON, cURL, Mbstring and zlib. A contributed module may add requirements of its own, so a complicated project can need more than the basic core list suggests.

43. Does Drupal need Composer?

Modern Drupal projects commonly rely on Composer for managing core and contributed package dependencies. It gives you a consistent way to install compatible components, record the chosen versions and keep the project reproducible.

44. Can I install Drupal without Composer?

There are setups where you do not have to manage Composer yourself, especially when a hosting company handles that part. Even so, a Composer-based workflow is generally the more maintainable approach for a modern production project.

45. What is the recommended web root in modern Drupal?

In a modern Drupal project, the public document root is normally a directory such as web. That structure keeps files intended for internal use outside the area exposed to visitors, which is both cleaner and safer.

Back to FAQ menu

4. Installation and Site Setup

46. How do I install Drupal on a hosting account?

Begin by checking the PHP, database and server requirements. You then create the database, put the project files in place, configure the document root and complete the Drupal installation. With a Composer-managed project, make sure the web server points to the web directory rather than the project root.

47. Can my provider install Drupal for me?

Many hosting companies offer either automatic installation or some form of setup assistance. That is convenient, but it is still worth checking the Drupal version being installed and understanding how the provider expects you to handle later updates.

48. What database information do I need during installation?

Normally you will need the database name, username, password, server hostname and database type. Some hosting arrangements also require a port or other connection detail, especially when the database is hosted separately from the website.

49. Should the database be on the same server?

Not necessarily. Keeping the database alongside the website is simple and often sensible for a small installation. Larger systems may separate the two for scaling, security, isolation or administrative reasons.

50. What is the document root?

It is the directory the web server treats as the public face of the site. In the recommended modern Drupal project structure, that directory is normally web, not the top-level project directory.

51. Why is the document root important?

Choosing the right directory prevents internal project files from being exposed directly through a browser. Pointing the web server at the wrong location can therefore cause more than a simple configuration problem; it can create a security issue as well.

52. Can I install Drupal in a subdirectory?

Yes. Drupal can run from a path such as example.com/site. It requires a little more care with URL handling and web-server rules than an installation at the domain root, but it is entirely possible.

53. Can I install several Drupal sites on one server?

Yes. Each site can be maintained separately, or you can make use of Drupal's multisite functionality. The best arrangement depends on how independent the sites need to be and how you want to handle code, configuration and updates.

54. What is Drupal multisite?

Multisite lets several websites use the same Drupal codebase while keeping their own configuration, databases and files. That can reduce duplication, but the shared codebase also creates a common point of failure: a problem in the shared code can affect more than one site.

55. Is multisite a good idea for unrelated customers?

It can work, but it deserves careful consideration. Sharing code reduces some maintenance work, yet it also ties the sites together operationally. When the customers have little in common, keeping their installations separate can make security, troubleshooting and updates easier.

56. Can I install Drupal with Softaculous?

If the hosting account provides Softaculous or a similar installer, it may offer Drupal that way. Whether it is a good long-term choice depends on how the installer handles Drupal core, contributed modules, Composer dependencies and future upgrades.

57. What permissions should Drupal files have?

There is no single set of numeric permissions that fits every server. The safer principle is to grant the web process only the write access Drupal actually requires and avoid making the entire project writable simply because it is convenient.

58. Why should settings.php be protected?

The file contains important configuration details, including database information. Leaving it unnecessarily writable can create a security risk, so once required changes have been made, its permissions should be tightened according to the server setup.

59. What is the installation profile?

An installation profile provides a predefined starting point for a Drupal site. It can select modules, configuration and initial settings for you, which is useful when the project follows a particular type of setup rather than beginning from a completely blank installation.

60. Can a hosting provider restrict Drupal installation?

Yes. Hosting companies can limit things such as PHP versions, memory, execution time, cron, database access, permissions or command-line tools. An account may therefore be capable of running basic PHP while still lacking something Drupal needs.

Back to FAQ menu

5. PHP, Databases and Server Configuration

61. Why does PHP memory limit matter?

Different Drupal operations can require substantial memory, including rendering pages, processing forms, generating images and applying updates. That limit applies to the PHP process, so the site can hit it even when the server as a whole still has plenty of physical RAM available.

62. Is 128 MB of PHP memory enough?

It can be enough for a small installation, but there is no universal answer. An administrative task on a more complicated site may require considerably more memory than an ordinary page request. What matters is the workload the site actually puts on PHP.

63. Why can Composer need more memory than the website?

Composer does more than serve a page. It examines dependency information and works out which package versions can coexist, which can consume a surprising amount of memory. That is why a site can run normally while a Composer update fails.

64. Why is the PHP CLI version important?

The PHP used from the command line is not necessarily the same PHP used by the web server. Composer, Drush and maintenance commands may therefore be running under a different version. A mismatch can make the command-line environment fail even while the website itself appears perfectly fine.

65. What is OPcache?

OPcache keeps compiled PHP code in memory so the server does not have to compile the same scripts again and again. That removes repeated work and is one of the standard performance optimizations for PHP applications.

66. Should OPcache be enabled?

For a production Drupal site, it generally should be. Reusing compiled PHP code can reduce processing overhead and improve response times. The actual configuration still needs to fit the server and the way deployments are handled.

67. Why does the database matter so much?

A large portion of what Drupal knows about the site lives in the database: content, configuration, users, fields and much more. Slow queries, inadequate indexing or a database server under pressure can therefore have a noticeable effect on the whole website.

68. What is the InnoDB storage engine?

InnoDB is the main MySQL/MariaDB storage engine required by Drupal's current database requirements. It provides transactional and other database capabilities that Drupal depends on.

69. Why does Drupal require PDO?

PDO is the PHP database interface Drupal uses to work with supported database systems. Without the required PDO functionality, Drupal cannot establish the database connections it needs.

70. Can a database server be overloaded even when CPU usage looks low?

Absolutely. High CPU is only one possible bottleneck. Disk latency, locking, memory pressure, connection limits and inefficient queries can all make a database struggle without producing unusually high overall CPU usage.

71. What is a cron job in Drupal?

Cron handles work that needs to happen periodically without someone manually starting it. Drupal can use scheduled tasks for queue processing, maintenance and other background operations that should not depend on an administrator opening the site.

72. Should Drupal cron run automatically?

For a production site, yes. Scheduled tasks should have a reliable mechanism behind them. Depending on someone to remember to trigger cron manually can leave maintenance work, queues or other background tasks sitting idle.

73. Can the hosting control panel run cron?

Usually it can. Most major control panels provide a way to schedule commands or web requests at regular intervals. The exact command depends on the site's setup and whether you are using Drush or another method of triggering Drupal cron.

74. Why is command-line access useful?

It becomes especially valuable as a Drupal project grows. Tasks such as Composer updates, Drush operations, cache rebuilding and database maintenance are much easier to repeat and automate from a shell than by clicking through an administration interface every time.

75. Do I need Drush?

No, Drupal can run without it. For many serious projects, though, Drush is one of the most useful tools available because it simplifies cache management, updates, configuration work, user administration and other routine tasks.

Back to FAQ menu

6. Performance and Caching

76. Why can a Drupal website become slow?

There is rarely just one possible reason. Limited server resources, inefficient database queries, custom code, heavy modules, missing caching, oversized images or slow third-party services can all contribute. The useful question is not “what is wrong with Drupal?” but “which part is actually taking the time?”

77. Is Drupal inherently slow?

No. A properly configured Drupal site can be very fast. More sophisticated websites naturally do more work than simple ones, but slow performance is not an unavoidable characteristic of the platform.

78. What is Drupal caching?

Caching means keeping reusable information so Drupal does not have to recreate the same result every time it is requested. Drupal has several caching mechanisms, and additional layers can come from reverse proxies, CDNs and other services in front of the application.

79. Why is caching so important?

When something can be served from cache, Drupal may not need to repeat database lookups, rendering or other application work. That can reduce load on the server and make repeated requests much quicker.

80. What is the cache rebuild process?

When important parts of a site change, Drupal can rebuild its caches so previously generated information is replaced with data that matches the new state. In other words, it refreshes the stored results the system relies on for faster operation.

81. Why does clearing the cache sometimes fix a strange problem?

A configuration or code change does not always make every previously generated piece of information disappear immediately. Rebuilding the caches removes that old data and allows Drupal to regenerate it from the current configuration and code.

82. Can clearing caches too often hurt performance?

Yes. Once a cache has been emptied, Drupal has to build it again. Doing that repeatedly on a live site can create unnecessary work and traffic, so cache clearing should be used when there is a reason to rebuild rather than as a general-purpose fix for every slowdown.

83. What is a reverse proxy?

It is a server placed in front of the application server. Depending on the setup, it can cache responses, compress content, filter requests or distribute traffic, allowing less work to reach Drupal itself.

84. Can Varnish be used with Drupal?

Yes. Varnish can sit in front of Drupal and keep cacheable responses ready to serve. This can be particularly effective for high-traffic sites where many visitors request the same pages.

85. Is a CDN enough to make Drupal fast?

No. A CDN can greatly help with static files and some cacheable responses, but it cannot make a slow application or database magically fast. If the origin server takes too long to produce dynamic pages, that underlying problem still needs to be addressed.

86. Can image sizes slow down a Drupal site?

Very easily. An oversized image takes longer to transfer and may also require more storage and processing. Keeping image dimensions sensible and using appropriate formats, compression and responsive delivery can make a noticeable difference.

87. Does enabling CSS and JavaScript aggregation help?

It can. Combining assets may reduce the number of requests and, depending on the setup, the amount of data the browser needs to retrieve. The improvement is not identical on every site, so measuring the actual effect is more useful than assuming it will always be substantial.

88. Can too many modules slow the site down?

They can, but simply counting modules is not a useful performance test. One well-written extension may have almost no noticeable effect, while a single inefficient module can add expensive database queries or other processing.

89. Can a slow third-party service affect Drupal?

Yes. If Drupal waits for an external API, payment service, analytics platform or other dependency before completing a request, that service can become part of the page's response time. The server itself may be functioning normally while an outside service holds everything up.

90. How do I find the real cause of a slow Drupal site?

Start measuring the different pieces instead of making random changes. Check response times, PHP activity, database queries, cache behavior, external requests, memory, CPU, storage and logs. Once you know where the delay occurs, the appropriate fix is usually much easier to identify.

Back to FAQ menu

7. Security, Backups and Updates

91. Is Drupal secure?

Drupal has a serious security process, but that does not make a neglected installation safe. Core, modules and themes all need maintenance, and the server itself needs sensible permissions, protected credentials, proper configuration and ongoing monitoring.

92. Why are Drupal updates important?

Updates do more than add features. They can remove security vulnerabilities, correct bugs and resolve compatibility issues. Leaving known security problems unpatched simply gives them more time to become a problem.

93. Should I update Drupal immediately when a new release appears?

Security updates deserve prompt attention, but “prompt” does not have to mean careless. For an important site, take a current backup, test significant changes where practical and make sure contributed or custom code will work with the update before deploying it.

94. Can I update Drupal from the administration area?

Some update tasks can be initiated through the Drupal interface, but that is not the whole maintenance story for a modern Composer-managed project. In those cases, dependency management and deployment are generally better handled through Composer and a controlled workflow.

95. Why is Composer important for updates?

A Drupal project is normally more than just core. It can contain contributed modules and other packages that have their own dependencies. Composer keeps track of that relationship and lets the project update compatible versions in a controlled way.

96. What is a security advisory?

It is an official notice about a security vulnerability and the action needed to address it. Drupal publishes security advisories for affected core and contributed software, so site owners should pay attention to notices relevant to the components they actually use.

97. Do contributed modules need updates too?

Yes. Keeping Drupal core current does not protect a site from a vulnerability in an outdated module or theme. Security maintenance has to cover the entire application, not just the core package.

98. Are old Drupal versions safe to keep running?

Only while they remain supported and their surrounding software is still maintained. Once a Drupal release stops receiving security fixes, keeping it online becomes progressively harder to justify from a security standpoint.

99. Should I make backups before updates?

Yes. A recent backup gives you an escape route when an update introduces an unexpected problem. Just as important, make sure the backup can actually be restored. A successful-looking backup job is not much use if the files cannot be recovered when needed.

100. What should a Drupal backup contain?

You normally need both the database and the site's files. That can include uploaded media, private files, configuration, custom code and any other components required to recreate the working installation.

101. Is a backup stored on the same server enough?

No. A server failure, compromise or serious storage problem could take out both the live site and the backup. Important backups should be kept somewhere separate and protected against unauthorized modification.

102. How often should backups run?

The right frequency depends on how quickly the site changes and how much data you could afford to lose. A busy business site may need daily or even more frequent backups, while a mostly static site can sometimes tolerate longer intervals.

103. Should backups be encrypted?

They should be protected according to the sensitivity of the information they contain. Since a Drupal backup can include user data, databases and secrets from configuration files, encryption and strong access controls can provide an important additional layer of protection.

104. What is least-privilege security?

It means nobody and nothing gets more access than necessary. A person who needs to edit content should not automatically have unrestricted server privileges, and a background service should not be given broad permissions simply because a narrower set was inconvenient to configure.

105. Can cheap hosting compromise Drupal security?

It can, but price is not the real issue. Problems arise when a low-cost environment comes with outdated software, poor isolation, weak account security, inadequate backups or other practices that leave the site exposed.

Back to FAQ menu

8. DNS, Email, SSL and Migration

106. Does Drupal need a domain name?

A public website normally needs a domain name or another hostname so visitors have somewhere to connect. During development, though, Drupal can run locally or on a temporary environment without a public domain.

107. Can I change hosting without changing the domain?

Yes. Your domain registration can stay exactly where it is. You simply change the DNS records that determine which server receives the website traffic.

108. Do I have to move DNS when moving hosting?

No. DNS and web hosting do not have to come from the same company. You can leave DNS where it is and update the records needed to point the domain toward the new hosting account.

109. What DNS record usually points the website to a server?

An A record normally points a hostname to an IPv4 address, while an AAAA record does the same for IPv6. In some situations, a CNAME is used instead to point one hostname to another.

110. Can Drupal use Cloudflare?

Yes. Cloudflare can handle DNS and can also provide CDN, caching and security features in front of Drupal. The configuration needs to be sensible, particularly around administrative pages, dynamic requests and anything that should not be cached.

111. Does Drupal need an SSL certificate?

For a public production site, HTTPS should be regarded as standard. It protects information moving between the visitor and the server and is especially important when users log in, submit forms or provide personal information.

112. Can I use Let's Encrypt?

Yes. Let's Encrypt certificates work perfectly well with Drupal. Many hosting providers can issue and renew them automatically, which removes much of the routine certificate management.

113. Why does Drupal show a mixed-content warning?

That warning normally means the main page is loaded securely over HTTPS while one or more resources are still being requested through HTTP. An old hard-coded URL, configuration value, theme, module or external resource can be responsible.

114. Does Drupal send email itself?

Drupal can generate messages and use the server's mail system or an external service to send them. For a production website, authenticated SMTP or a transactional email provider is often a more dependable choice than relying entirely on the server's local mail setup.

115. Why do Drupal emails sometimes go to spam?

Email providers judge messages using many different signals. Sender reputation, authentication, domain alignment and sending behavior all matter. Proper SPF, DKIM and DMARC records can help, as can a reputable mail service, but there is no configuration that guarantees every message reaches the inbox.

116. How do I move a Drupal site to another host?

A typical migration involves moving the files and database, recreating the required server environment, testing the site and then changing DNS. For a Composer-managed project, keep the dependency information intact so the new server can reproduce the intended software stack.

117. Can I migrate without taking the old site offline?

Often you can. The new environment can be built and tested while the existing site continues serving visitors. Near the end, synchronize the latest database changes and switch traffic during a brief final migration window.

118. Why can a migration work on the new server but fail after DNS changes?

The public hostname can expose problems that a temporary test address did not. DNS, SSL coverage, trusted-host settings, virtual-host rules and caching may all behave differently once the real domain begins reaching the new server.

119. What is trusted host configuration?

It tells Drupal which hostnames should be considered legitimate. Properly configured, it helps stop arbitrary host headers from being accepted and makes sure the application only responds to hostnames you actually intend to use.

120. Can I stage a Drupal site before switching DNS?

Yes. You can use a protected subdomain, temporary hostname, hosts-file entry or another staging method. Keep that environment away from normal visitors and search engines until the site is ready to become public.

Back to FAQ menu

9. Development, Modules and Advanced Use

121. What is a Drupal module?

A module adds functionality. Some modules are part of Drupal core, while others are contributed or written specifically for a project. They can provide everything from forms and search to integrations, workflows, APIs and specialized content features.

122. What is a Drupal theme?

The theme is responsible for much of the presentation layer. It controls templates, markup, styles and other visual behavior, allowing the appearance of the site to change without changing the underlying content itself.

123. Can I install unlimited modules?

There is no meaningful “unlimited” point here. You can add many modules, but every one introduces code, dependencies and something else that needs to be maintained. A better rule is to keep extensions that have a clear purpose and are reliable and compatible.

124. Can a module cause a server error?

Yes. A module can introduce a bug, clash with another extension, require an incompatible dependency or run into a server limitation. When a problem appears immediately after installing or updating something, that timing is worth taking seriously.

125. Should I test module updates before production?

For an important website, that is a very good practice. Testing on a staging copy gives you a chance to catch compatibility issues while they are still harmless. The more contributed and custom code the site contains, the more useful this becomes.

126. What is a staging environment?

It is a separate version of the site used to try changes before they reach production. Ideally it resembles the live environment closely enough to expose problems without exposing those unfinished changes to visitors.

127. Should staging use the same PHP version as production?

Ideally, yes. Staging is supposed to reveal problems before they reach the live site, so it needs to behave like production as closely as practical. A different PHP version can allow a change to pass testing and then fail after deployment.

128. What is configuration management in Drupal?

Configuration management lets you move site configuration between environments in a controlled way. Drupal supports this through its configuration tools, and command-line workflows such as Drush can make the process easier to repeat.

129. What is Drush used for during development?

Drush puts many Drupal maintenance tasks at the command line. Developers can use it for cache rebuilding, configuration imports, database updates, user management, system inspection and other work that would otherwise require repeated administrative steps.

130. Can Drupal run in containers?

Yes. Containers are commonly used to make development and deployment environments more consistent. They do not, however, make the difficult parts disappear. Databases, persistent files, networking, backups and security still need to be designed properly.

131. Can Drupal use Docker?

Yes. Docker can package the different pieces of a Drupal environment so they can be reproduced more consistently from one machine to another. That is especially useful when a team wants PHP, the database, the web server and supporting services to behave in a predictable way.

132. Is Composer useful for a custom Drupal theme?

Composer is mainly concerned with package and PHP dependencies rather than the visual design itself. A custom theme can still live comfortably inside a Composer-managed Drupal project, with its own source and assets maintained as part of that project.

133. Can I use Git with Drupal?

Yes, and it is a sensible choice for serious development. Git gives you a record of code changes, makes collaboration easier and provides a way to review or roll back mistakes. Databases and uploaded files are generally managed separately from ordinary source-code commits.

134. Should uploaded files be stored in Git?

Usually not. Images and documents uploaded by users can grow large and change regularly, which makes Git a poor fit for them. Persistent site files are normally handled separately from the source code.

135. Can Drupal support multiple languages?

Yes. Multilingual support is one of Drupal's established strengths. Depending on the site's setup, you can translate content, interface text, configuration and other parts of the experience for different languages.

Back to FAQ menu

10. Troubleshooting and Practical Questions

136. Why is my Drupal site showing a blank page?

A blank page is often the visible result of a server-side failure. A PHP fatal error, exhausted memory, incompatible module or problem in the theme can all cause it. Check the error logs before repeatedly clearing caches, because the logs usually point much closer to the real cause.

137. Why am I getting a 500 Internal Server Error?

The server could not complete the request successfully. PHP errors, broken rewrite rules, permissions, incompatible extensions, resource limits and application bugs are all possible causes. The server and Drupal logs are the best place to narrow it down.

138. Why does the administration area feel slow?

The admin interface can demand considerably more from the server than a cached public page. Heavy modules, slow database work, limited memory or CPU and third-party services can all contribute. A fast front end does not necessarily mean the administration side is equally healthy.

139. Why is Drupal using so much memory?

Memory consumption rises with the amount of work being done. Large configuration sets, numerous modules, image processing, search operations, imports, updates and administrative requests can all use much more memory than an ordinary page view.

140. Why does a page fail only when I save content?

Saving content can trigger work that a normal page request never performs. Drupal may validate data, write to the database, process files, update indexes, rebuild caches or call other modules. A memory limit, timeout or extension problem may therefore appear only during the save operation.

141. Why does a Drupal update fail with a Composer error?

“Composer error” is only the label for where the problem was reported. The underlying issue might be incompatible package requirements, a PHP-version mismatch, an unresolved dependency or another project constraint. The exact Composer message usually tells you much more.

142. Why does Drupal work in the browser but Drush fail?

The command-line environment may not be the same as the web environment. It can use another PHP binary or version, a different user account, different environment variables or different filesystem permissions. Comparing the two environments is a good first troubleshooting step.

143. Why do changes to my theme not appear?

Drupal may still be serving previously generated templates, render data, CSS or JavaScript. Rebuilding the relevant caches can make the new version appear, but if it keeps happening, also check that the correct theme files were deployed and that the change is actually being loaded.

144. Why does the site work on one hostname but not another?

The second hostname may be missing from trusted-host settings, pointing to the wrong server through DNS, absent from the web-server configuration or not covered by the SSL certificate. Any of those can make two apparently similar hostnames behave differently.

145. Why does Drupal keep redirecting me to the wrong URL?

Start by checking HTTPS handling, trusted hosts, reverse-proxy settings and any redirects configured by the web server or Drupal. A proxy or load balancer can also make Drupal interpret the incoming request differently from the way the visitor actually reached the site.

146. Why can't Drupal connect to the database?

Check the connection details first: hostname, database name, username, password and port. Then look at the database service itself, network access, PHP database extensions and permissions. Connection limits or authentication rules on the database server can also be responsible.

147. Why are uploaded files not working?

There are several possibilities. The files directory may have the wrong permissions, the configured path may be incorrect, the web server may be blocking access, or storage may simply be full. After a migration, it is also worth confirming that the actual files were copied to the location Drupal expects.

148. Why is cron failing?

The scheduler may be calling the wrong command or URL, or the CLI environment may be using an incompatible PHP version. Permissions can also interfere, and the Drupal task itself may be failing. Running the scheduled command manually often reveals an error that the scheduler hides.

149. What should I check before moving Drupal to a new provider?

Make a comparison checklist based on the existing site: PHP and database versions, required extensions, Composer support, cron, SSH or CLI access, permissions, memory limits, backups, SSL, DNS control and staging. The new environment should be capable of reproducing the current installation before you redirect live traffic.

150. What makes a good Drupal hosting environment?

A good environment is one that works with the real needs of the website instead of simply offering the longest feature list. It should provide supported software, sufficient resources, dependable storage and networking, sensible security, usable backups, reliable cron and a practical way to maintain and update the site without unnecessary restrictions.

Back to FAQ menu