How to Deploy Drupal Hosting Without Bloat

Drupal is not a lightweight brochure-site tool pretending to be a CMS. It is a serious application with a database, a cache layer, scheduled jobs, file permissions, and enough moving parts to punish sloppy hosting. To deploy Drupal hosting cheaply, you do not need a premium logo on the control panel. You need compatible PHP, a real database, SSL, cron access, and enough room to manage the site properly.

That is the standard. Everything else is packaging.

What Drupal actually needs from hosting

A small Drupal site can run comfortably on shared hosting, provided the host is not cutting corners on the basics. Drupal needs a supported PHP version with common extensions enabled, MariaDB or MySQL, and a web server configuration that can route requests through Drupal’s front controller. Apache with rewrite support handles this well. Nginx can do it too, but it needs the right configuration.

You also need a place to run Composer. This does not always mean Composer must run on the production server. Many developers build the codebase locally or in CI, then upload the finished application. But Drupal projects depend on Composer-managed code, so a hosting plan that treats your site as a pile of random FTP files will become annoying fast.

Disk space matters more than people think. Drupal core, contributed modules, themes, uploaded media, database exports, and backup archives all consume space. A 6GB plan is plenty for many small business sites, docs portals, community projects, and modest stores. It is not a free pass to keep years of uncompressed backups and original 4K video files on the same account.

Bandwidth is usually less of a concern until traffic or downloads grow. For a normal content site, 300GB is substantial. For a media-heavy site or a busy download mirror, it may not be. Cheap hosting is good when the workload fits. Pretending every project fits is how people end up angry later.

Deploy Drupal hosting in the right order

Start with the domain and document root. Create the domain in your control panel, point its DNS records to the hosting account, and confirm that the web root is ready. A Composer-based Drupal project should expose its web directory, not the project root. If your provider lets you choose a document root, point it at that directory.

This one detail prevents a common mistake: exposing files such as composer.json, private configuration, or development artifacts to the public web. Drupal’s public entry point belongs in web/index.php. Keep the rest of the project above the web-accessible directory when your account structure allows it.

Build the codebase with Composer

For a new project, create the Drupal codebase using a Composer template that supports a separate web root. Add modules and themes through Composer rather than downloading random archives into module folders. Composer records what your site uses and makes updates repeatable.

If you have SSH access, you can run Composer in the hosting account. If you do not, build locally, test locally, and upload the resulting project files. Either approach works. Running Composer on a small shared account can be slow, especially when memory limits are tight. Building elsewhere is often cleaner.

Do not upload your local .git directory, test fixtures, node modules, or editor junk. They waste space and create more ways to expose something you did not mean to publish.

Create a database and use a separate user

Create a new MariaDB database and a database user with a unique, long password. Assign that user only to the database Drupal will use. Write down the database name, username, password, and host value before opening the Drupal installer.

A separate user per site is not corporate theater. It limits accidental damage when you host more than one project. It also makes migrations and cleanup less confusing six months from now, when you no longer remember which database belongs to which domain.

Run the Drupal installer through the domain over HTTPS once SSL is active. Enter the database details, select the installation profile that fits the site, and create an administrator account with a password that is not reused anywhere else. The first account has broad control. Treat it accordingly.

Set PHP before chasing errors

Drupal compatibility depends on the Drupal version and the modules you install. Set the domain to a PHP version supported by your Drupal release, then verify it in the hosting control panel. Multiple PHP-FPM versions are useful because they let an older site stay on a compatible version while a newer site moves forward.

Do not blindly select the newest PHP release because it sounds safer. An unsupported module can break the site just as effectively as an old PHP version can create security risk. Check Drupal’s requirements, check the module ecosystem, and choose the newest version your full stack supports.

Memory limits are another practical issue. A simple site may run fine with modest memory, while Composer operations, module updates, image processing, or large imports need more. If an operation fails once, read the error before changing five settings. A fatal memory error, a file-permission problem, and a missing PHP extension are different problems.

Make files, private data, and configuration boring

Drupal must be able to write to its public files directory. During installation, that is commonly web/sites/default/files. Follow Drupal’s current permission guidance rather than using 777 as a panic button. World-writable permissions are not a fix. They are a shortcut to a worse problem.

If the site handles private downloads, store private files outside the public web root and configure Drupal’s private file path in settings.php. Public files are meant to be served directly. Private files should go through Drupal’s access checks.

Keep settings.php protected. Use it for environment-specific values such as database credentials, hash salt, trusted host patterns, and private file paths. For a project you expect to move between local development, staging, and production, keep configuration in version control and use Drupal’s configuration export and import workflow. That takes discipline, but it beats clicking settings into existence on one server and hoping you can recreate them later.

Cron, caching, and SSL are not optional chores

Drupal has scheduled work to do: indexing, queue processing, update-related tasks, cleanup, and module-specific jobs. Set a real cron job in the control panel. The exact command depends on your Drupal version and deployment setup, but the principle does not change: run it on a schedule from the server.

Do not rely on someone visiting a page to trigger background work. That behavior is unreliable, and low-traffic sites are exactly where it fails. A cron job every 15 to 30 minutes is reasonable for many small sites. Sites with active queues may need a different schedule.

Enable the free SSL certificate, redirect HTTP traffic to HTTPS, and confirm that Drupal recognizes the secure URL. Then configure caching. Drupal’s internal caches should stay on in production. Aggregate CSS and JavaScript after you have finished active theme development. If you add a CDN later, understand what it caches and how cache invalidation works before blaming Drupal for stale pages.

Caching has a trade-off. Aggressive caching reduces server work, but personalized pages, commerce carts, and frequently changing content need careful cache rules. There is no magic switch that makes every page both instant and always fresh.

Backups are part of deployment

A Drupal backup has at least two pieces: the database and the files. Back up both. Your code should also be recoverable from Git or a known build artifact, but a database dump and the uploaded files are what save the actual site content.

Keep backups somewhere other than the same hosting account. An account-level failure, mistaken deletion, or compromised login can take local backup archives with it. Test a restore before you need one. A backup that has never been restored is an assumption, not a plan.

Before core or module updates, take a fresh database backup, put the site in maintenance mode if the change warrants it, deploy the updated Composer dependencies, run database updates, import configuration when applicable, clear caches, and test the public site. Small sites can often do this manually. Larger or more valuable sites should use a repeatable deployment process.

When shared Drupal hosting is the wrong tool

Shared hosting is a good fit for projects with ordinary traffic, predictable resource use, and an owner who can read logs and follow instructions. It is not a good fit for a giant multisite network, constant imports, search clusters, high-volume commerce, or workloads that need custom server daemons and root access.

Be honest about the operating model too. A low-cost, self-service host is cheaper because it is not selling a team to debug every contributed module conflict at midnight. Ular.Host is built for people who want open source hosting capacity and control, not a concierge layer. If you need someone else to own deployment, security patches, performance work, and incident response, pay for managed Drupal hosting and get what you paid for.

For everyone else, keep the deployment plain: Composer-managed code, one database per site, supported PHP, scheduled cron, HTTPS, caching, and off-account backups. Drupal does not need theater. It needs a host that covers the basics and an owner who does not skip them.