How do you deploy Drupal to production?
Deploy Drupal by building each release from git in a new directory, installing vendors with composer, linking the files folder and settings that must persist, running drush deploy against the production database and then switching traffic to the new directory in one step. Exporting configuration in development and importing it in production is what makes this repeatable: the code and the config travel together through git, and the database keeps only content.
On a DeployManage zero downtime site the panel clones the commit into releases/<timestamp>, sets DM_SITE_DIR and DM_RELEASE_DIR and runs your script inside the release. A typical script for a project built on drupal/recommended-project looks like this:
composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
mkdir -p "$DM_SITE_DIR/shared/files" "$DM_SITE_DIR/shared/private"
ln -sfn "$DM_SITE_DIR/shared/files" web/sites/default/files
ln -sfn "$DM_SITE_DIR/shared/settings.local.php" web/sites/default/settings.local.php
vendor/bin/drush deploy
The settings.local.php file holds the database credentials, the hash salt and the trusted host patterns, and it never enters git; uncomment the include of settings.local.php at the end of the stock settings.php once and commit that. Put the private files path outside the web directory (the shared/private folder above) and set file_private_path to it. When the script exits with code 0, the panel moves the current symlink, Nginx keeps serving web/ from current, and PHP-FPM picks up the new code on the next request.
What does drush deploy do?
drush deploy runs the standard post deploy sequence in the right order: database updates (updatedb), a cache rebuild, configuration import (config:import), another cache rebuild and finally any deploy hooks your modules define. It replaced the four or five separate drush commands that older deploy scripts chained together, and it fails loudly if any step fails, which is exactly what you want inside a release that has not gone live yet.
Because drush deploy writes to the shared production database, schema updates take effect a few seconds before the symlink moves. For ordinary releases that is harmless. For a release with a heavy update hook (a field type change on a table with millions of rows, for example), put the site in maintenance mode for that one deploy with drush state:set system.maintenance_mode 1 before updatedb and set it back to 0 after the switch. Most weekly releases never need it.
Can you deploy Drupal with zero downtime?
Yes, for code. A symlink release lets visitors keep getting the old code until the new release is fully built, so composer, file links and cache warmup never run under live traffic. The only part that is not atomic is the database: updatedb and config:import change the shared database before the switch, so a release has to stay compatible with the schema for those few seconds. Writing update hooks that add before they remove (add a new field, deploy, migrate data, remove the old field in a later release) keeps that window safe.
On DeployManage, zero downtime releases and quick deploy on push are part of Growth and Business. Starter deploys in place, which suits a staging server but not a client's production site. Laravel Forge also offers zero downtime deploys, limited to one server per site, so a Drupal site behind a load balancer on two servers needs Envoyer on top of Forge.
How much does Drupal hosting cost?
Drupal hosting costs about $24 a month for one small site on a $12 DigitalOcean server with Forge, $55 a month on Pantheon Basic, and from roughly $115 to $225 a month for ten client sites on servers you own, against $550 for the same ten sites on Pantheon Basic. The worked bills below use the vendors' own October 2026 prices: DigitalOcean Basic Droplets at $12 (2 GB), $48 (8 GB) and $96 (16 GB), Pantheon monthly site plans, and the panel fee for Forge and DeployManage Growth.
| Setup | Pantheon | Servers + Laravel Forge | Servers + DeployManage Growth |
|---|
| 1 site, about 20K visits a month, one 2 GB server | $55 (Basic, or $41.67 a month paid yearly) | $12 + $12 = $24 | $12 + $129 = $141 |
| 10 client sites under 25K visits each, two 8 GB servers | 10 x $55 = $550, or $1,050 with the Gold workspace for Multidev and 24/7 support | $96 + $19 = $115 | $96 + $129 = $225 |
| 4 busy sites at about 50K visits each, three 8 GB servers (2 app, 1 database) | 4 x $350 = $1,400 (Performance Medium) | $144 + $19 = $163 | $144 + $129 = $273 |
Two things the table does not price. First, labor: Pantheon patches the platform and answers chat, and on your own servers your team owns OS patches, PHP upgrades and the alerts, even with a panel doing the provisioning and deploys. Second, traffic overages: Pantheon's published rate is $40 per 10,000 unique visits above the plan, and its docs say the automated overage program is paused for now. Our full breakdown of the plans is in Pantheon pricing and the real cost of Drupal hosting.
Which PHP version does Drupal 11 need?
Drupal 11 needs PHP 8.3 or newer, and Drupal 10 needs PHP 8.1 or newer with 8.1.6 recommended. Drupal.org lists Drupal 10's end of life as December 2026, so any client site still on 10 needs a move to 11 this year, and that upgrade usually goes together with a PHP upgrade on the server.
DeployManage installs PHP-FPM 8.1, 8.2, 8.3 or 8.4 per server and sets the version per site, so you can run a Drupal 10 site on 8.2 and a Drupal 11 site on 8.4 on the same machine while you upgrade clients one at a time. Pair it with MySQL 8, MariaDB or PostgreSQL 16, all three of which Drupal 11 supports.
When Pantheon or Acquia is the better choice
Be honest about the trade. If you run one or two Drupal sites, have no one on the team who wants to read a server alert, and value Multidev branches for every feature, Pantheon is a good product and $55 a month is a fair price for a small site. If a large organization needs a contractual SLA, Acquia's enterprise features and a vendor to sign a security questionnaire, a quote from Acquia is the normal route and nothing here replaces it.
The math changes for agencies. Per site plans multiply: ten small client sites cost ten Basic plans, and a client that grows past 25,000 visits moves up to a $200 tier. On your own servers the bill grows with RAM, not with the number of sites, and an agency that already runs Laravel or Symfony apps can manage its Drupal sites from the same panel. If you also host Craft or Statamic sites, the same release flow is described on Craft CMS deployment and Statamic hosting.
Ready to stop managing servers by hand? DeployManage provisions, deploys and monitors your fleet from one dashboard.
Get started
