Put your Drupal site into maintenance mode from the admin toolbar: go to Configuration > Development > Maintenance mode (/admin/config/development/maintenance), check Put site into maintenance mode, optionally edit the message shown to visitors, and save. Logged-in users with the "access site in maintenance mode" permission (administrators, by default) can still browse normally. Everyone else sees the maintenance message with a 503 response.
If the admin UI itself is unreachable, you can flip the same flag with Drush over SSH:
drush state:set system.maintenance_mode 1 drush state:set system.maintenance_mode 0
The first command turns maintenance mode on, the second turns it back off. Drush ships with most Composer-based Drupal installs, so if your site was built that way, it's already available wherever you can reach a shell.
Why the 503 matters
Drupal serves maintenance mode as an HTTP 503, not a 200. That's correct behavior: it tells search engines and monitoring tools "temporarily unavailable, check back later" instead of letting them index or alert on a half-broken page. Leave it in place only as long as you need to. Search engines that see repeated 503s over a long period can start to deprioritize crawling the site, so treat maintenance mode as a short window for updates, not a long-term parking state.
What happens to caching while you're in maintenance mode
On Flashcloud, every WordPress install gets an aggressive cache stack out of the box, but Drupal isn't WordPress, so the automatic LiteSpeed integration and pre-installed cache plugin described in the cache stack we ship with every WordPress install doesn't apply here. Drupal runs on the same LiteSpeed Web Server underneath (see how we make your site fast for the general server and edge architecture), but that's server-level infrastructure rather than something we pre-wire for Drupal the way we do for WordPress.
Practically, this means when you flip on maintenance mode, Drupal's own page cache stops serving cached pages to anonymous visitors (Drupal is aware of its own maintenance state and won't serve stale cached markup instead of the maintenance message). If you're running Cloudflare in proxy mode on the domain, static assets at the edge stay cached, but the HTML response itself will reflect the 503 correctly since Drupal generates it fresh. If you've set up page-level caching through a module, purge or bypass it before relying on maintenance mode for something sensitive like a database update, since a stale cached page can occasionally outlive the flag if the module's cache lifetime is long and it wasn't cleared.
Typical uses
- Core or module updates: run
drush updbor apply Composer updates with the site in maintenance mode so no visitor hits half-migrated database schema. - Theme or config changes: hide work-in-progress layout changes from the public while you finish them.
- Database restores: keep writes from happening mid-restore if you're rolling back from a backup.
Server stack for Drupal on Flashcloud
Drupal isn't one of the one-click installers wired into our WordPress-specific tooling, but it runs cleanly on the same shared hosting stack: LiteSpeed Web Server, NVMe storage, and MySQL/MariaDB with phpMyAdmin for the database side. PHP version is set per domain from the portal's PHP Version tile (7.4 through 8.3, system default 8.2), which covers Drupal's supported PHP range depending on which Drupal version you're running. If a module needs a specific PHP extension, enable it in cPanel under Software > Select PHP Version, while limits like upload_max_filesize are configured in Software > MultiPHP INI Editor, not the portal's PHP Version tile, which only switches the version. For general file and database access while setting up Drupal, see accessing cPanel.
SSH access is available for Drush and Composer workflows if you'd rather manage Drupal from the command line than through cPanel.
When to contact support
If maintenance mode won't turn off or a failed update has left the site in a broken state, open a ticket from Support in the portal. It's a real person on the other end, not a bot, and they can look at the account directly if a Drush command or database migration needs to be rolled back from a backup.